2D Navigation of a Mobile Robot in ROS

Navigation can be 2D or 3D. For a ground mobile robot, the navigation is typically 2D since the mobile robot does not have a degree of freedom in the vertical direction. Even for other types of mobile robots such as unmanned aerial vehicles (UAVs), the navigation can be simplified to 2D. This is performed by decoupling the motion control into 2D horizontal motion and 1D vertical motion (i.e. altitude control). See the following example of 2D navigation applied to a UAV: https://www.wilselby.com/research/ros-integration/2d-mapping-navigation/

There are five things required to navigate a mobile robot:

1. Map
2. Robot localization
3. Sensing the environment
4. Motion planning
5. User Interface
6. Motion control

The first four things above are handled by a navigation package, whereas the last thing (i.e. the motion control) should be handled by the robot controller.

Here we are going to create a 2D navigation package for a mobile robot. The package has a structure like this:

my_navigation_package:
|--launch
  |--amcl.launch.xml
  |--my_navigation_launch.launch
|--maps
  |--my_map.pgm
  |--my_map.yaml
|--param
  |--move_base_params.yaml
  |--dwa_planner_params.yaml
  |--costmap_common_params.yaml
  |--global_costmap_params.yaml
  |--local_costmap_params.yaml
|--rviz
  |--my_navigation_rviz.rviz
|--src
  |--my_navigation_client.cpp
|--script
  |--my_navigation_client.py
|--package.xml
|--CMakeLists.txt

All the launch files described below should be combined into a single launch file called “my_navigation_launch.launch” as shown in the file structure above. This is the launch file which should be launched to load the navigation configuration, after the robot (or the robot simulator) is launched. This launch file performs several tasks including:

• running the map_server and loading the map
• running AMCL node (used to localize the robot)
• running move_base node (used to navigate the robot from the current pose to the goal pose).

A similar navigation package can be found here: https://github.com/ROBOTIS-GIT/turtlebot3/tree/master/turtlebot3_navigation

Map

There are two cases in the navigation of a mobile robot with regard to map:

• The map is available
• The map is not available

The availability of map represents an apriori knowledge about the environment. A map can be drawn manually if the environment is know in advance. If the map is not available, simultaneous localization and mapping (SLAM) is typically performed to create the map while the robot is exploring the environment. A simple way to perform SLAM is by teleoperating the robot and observing the obstacles by using the robot exteroceptive sensors while creating the map using a SLAM algorithm. Similar to navigation, a map can be either a 2D map or a 3D map.

In ROS, a map should be represented by two files: a pgm file and a YAML file. The pgm file is the visual representation of the environment, which can be presented as an occupancy grid map with gray scale ranging from 0 (black) to 255 (white), but typically to be classified into binary scale: either occupied (black) or free (white). The YAML file contains some information about the map. A YAML file called “my_map.yaml” corresponding to a map called “my_map.pgm” looks like this:

image: my_map.pgm
resolution: 0.050000
origin: [-10.000000, -10.000000, 0.000000]
negate: 0
occupied_thresh: 0.65
free_thresh: 0.196

The resolution is given in meters per pixel. In the example above, it means that 1 pixel equals 0.05 meters. In other words, 100 pixel equals 5 meters, i.e. 1 pixel equals 5/100 meters = 5 cm. The origin described above means that the lower left of the map is at x = -10 meters, y = -10 meters. Negate means whether black and white colors are inverted. If negate is 0, it means black remains black and white remains white. The threshold to consider a grayscale occupied is 0.65 whereas the threshold to consider a grayscale free is 0.196. This threshold is in the range of 0 to 1.

To load a map, run the “map_server” node and load the map. It can be performed by using a launch file like this:

Robot localization

There are several methods to localize the robot, including:

• Kalman Filter (KF), including EKF and UKF.
• Particle Filter (PF).

A well-known PF-based localization algorithm is Monte Carlo Localization (MCL). The improved version of MCL is the Adaptive Monte Carlo Localization (AMCL). The AMCL node can be easily launched by including it in a launch file like this:

where the “amcl.launch.xml” looks like this:

Please notice that the AMCL node requires the determination of the initial pose of the robot.

Another ROS package commonly used for robot localization is robot_localization. This package is capable to fuse data from several sensors such as odometry, IMU, and GPS to improve the localization. The pose estimation is performed by using EKF and UKF.

The robot pose is published by the “robot_state_publisher” node. Hence, it is necessary to run the “robot_state_publisher” node if it is not running yet. This can be done by using a launch file like this:

Motion planning

A very common ROS package used to navigate a mobile robot in ROS is move_base. It consists of a global planner and a local planner. The global planner is based on the global costmap, whereas the local planner is based on the local costmap. Both the costmaps are presented as occupancy grid map in grayscale, ranging from 0 to 255:

• 000: Free area where robot can move freely
• 001~127: Areas of low collision probability
• 128~252: Areas of high collision probability
• 253~254: Collision area
• 255: Occupied area where robot can not move

The global costmap is indicated by grayscale representation around the obstacles on the loaded map, whereas the local costmap is indicated by grayscale representation around the robot body.

The “move_base” node can be conveniently launched by using a launch file like this:

As seen above, there are some YAML files for the “move_base” node which should be written:

• move_base_params.yaml
• dwa_local_planner_params.yaml
• costmap_common_params.yaml
• global_costmap_params.yaml
• local_costmap_params.yaml

The “move_base_params.yaml” looks like this:

The “dwa_local_planner_params.yaml” looks like this:

The “costmap_common_params.yaml” looks like this:

The “global_costmap_params.yaml” looks like this:

The “local_costmap_params.yaml” looks like this:

User Interface

A user can provide inputs for navigation in two ways:

• Using RViz where a user can initialize the pose of the robot for the AMCL node and determine a goal pose of the robot for the move_base node.
• Using client node. This can be written in C++ or Python. By using such a client node, one can programmatically determine a goal pose of the robot. Below we can see simple client nodes written in C++ and Python to move the robot 2 meters forward.

A client node written in C++ looks like this:

If the robot is intended to move 2 meters forward with respect to the robot’s frame, let’s say base_link frame, you just need to change the reference frame of the motion:

A client node written in Python looks like this:

If the robot is intended to move 2 meters forward with respect to the robot’s frame, let’s say base_link frame, you just need to change the reference frame of the motion:

Motion control

Motion control of the mobile robot is handled by the robot controller, such as ros_control and friends. Since the “move_base” node publishes the velocity command (/cmd_vel topic) which is a geometry_msgs/Twists message (containing the linear and angular velocities), this velocity command is fed to the robot controller, such as the “diff_drive_controller” which is one of the controller in ros_controller.

Official documentation

• http://wiki.ros.org/navigation/Tutorials
• http://wiki.ros.org/navigation/Tutorials/RobotSetup