To run, execute:
roslaunch where_am_i world.launch
roslaunch where_am_i amcl.launchYou can also use keyboard teleop to control the bot manually:
rosrun teleop_twist_keyboard teleop_twist_keyboard.pyBuilding requires ROS Kinetic; you can try executing ./run_nvidia.sh to drop into an X11 aware
Docker container with NVIDIA GPU support.
The simulation environment is this building:
Here's a visualization in RViz showing the individual planning elements:
- The global cost map is shown in false color, where pink corresponds to solid obstacles and cyan represents an "inflation zone" around it, used to provide a safety buffer defined by the bot's dimensions.
- The white rectangle represents the local map, in which white is safe space and black represents an obstacle.
- The orange lines are formed by a LiDAR point cloud as measured by the black sensor on top of the robot base, displayed here in red.
- The white arrows, lastly, represent particles of the Adaptive Monte-Carlo Localization (AMCL) node.
After setting a navigation goal in RViz, we can observe the bot executing some plan. As soon as the bot rotates, localization improves drastically:
On the other hand, here's a video of the bot being controlled via teleop through the legs of the table in the left center of the map:
Note that in the current setup, the applied torque will result in the bot doing a wheelie when accelerating, as well as a stoppie when braking. This results in the LiDAR temporarily scanning the ceiling or the floor. The cost maps are set up to ignore short-term interferences of this kind and will recover from this behavior immediately, so it's not much of an issue regarding the project.
One of the biggest issues in control that's still unsolved is the disagreement of the local planner with the global planner. In the following video, the local costmap was never populated, resulting in the bot heading straight for the wall.
Eventually, only removing both the devel and build directories,
building from scratch and restarting the Docker container helped me there -
but still, the bot goes straight until the local cost map shows a clear obstacle.
The ROS navigation stack is powerful for mobile robots to calculate their position and orientation so they can navigate reliably between obstacles to a goal position. Tuning the navigation stack on a real robot in the real world can be costly and dangerous. This paper presents two different robot models using the Gazebo physics simulator to tune and test the performance of the robots navigation stack.
This paper comes to the conclusion that using a diff-corrected model for
non-omnidirectional robots results in the lowest localization errors due to
reduced slip compared to omni-like models (e.g. skid-steer control).
Note: This does not really work, as CLion will be unable to find generated headers. It's still a bit better than doing everything the hard way.
The full requirements for setting up CLion are given in the sunsided/robond-ros-docker repository. In short, run SSHD in Docker, configure a Remote Host build to connect to it, then configure the your build settings for ROS. For this repo and the included Dockerfile, this configuration will do:
CMake options:
-DCATKIN_DEVEL_PREFIX:PATH=/workspace/devel -DCMAKE_PREFIX_PATH=/workspace/devel;/opt/ros/kinetic;/opt/ros/kinetic/share
Environment:
ROS_ROOT=/opt/ros/kinetic/share/ros;ROS_PACKAGE_PATH=/workspace/src:/opt/ros/kinetic/share;ROS_MASTER_URI=http://localhost:11311;ROS_PYTHON_VERSION=2;ROS_VERSION=1;ROSLISP_PACKAGE_DIRECTORIES=/workspace/devel/share/common-lisp;ROS_DISTRO=kinetic;ROS_ETC_DIR=/opt/ros/kinetic/etc/ros;PYTHONPATH=/opt/ros/kinetic/lib/python2.7/dist-packages;PKG_CONFIG_PATH=/workspace/devel/lib/pkgconfig:/opt/ros/kinetic/lib/pkgconfig:/opt/ros/kinetic/lib/x86_64-linux-gnu/pkgconfig;LD_LIBRARY_PATH=/workspace/devel/lib:/opt/ros/kinetic/lib:/opt/ros/kinetic/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH;PATH=/opt/ros/kinetic/bin:$PATH