The core terms that are used in TurtleBot navigation are as follows:

Odometry: Data gathered from moving sensors is used to estimate the change in a robot's position over time. This data is used to estimate the current position of the robot relative to its starting location.

Map: For TurtleBot, a map is a 2D representation of an environment encoded with occupancy data.

Occupancy Grid Map (OGM): An OGM is a map generated from the 3D sensor measurement data and the known pose of the robot. The environment is divided into an evenly-spaced grid in which the presence of obstacles is identified as a probabilistic value in each cell on the grid.

Localization: Localization determines the present position of the robot with respect to a known map. The robot uses features in the map to determine where its current position is on the map.

The following steps are fairly complex and will require the use of four or five terminal windows. Be conscious of which commands are on TurtleBot (requiring ssh from the remote computer) and those that are on the remote computer (not requiring ssh). In each terminal window, enter the commands following the $ prompt:

At this point, the operator should use keyboard commands to navigate TurtleBot completely around the environment. A representation of the map is built and can be viewed in rviz as TurtleBot's 3D sensor detects objects within its range.

The following screenshot shows a map of our lab that TurtleBot produced on rviz:

TurtleBot mapping a room

Notice that light gray areas are clear, unoccupied space, dark gray areas are unexplored areas, black indicates a solid border, such as a wall, and colored spots are obstacles in the room. The area of the brightest color is TurtleBot's local map (the area the sensor is currently detecting).

When a complete map of the environment appears on rviz, the map should be saved. Without killing any of the prior processes, open another terminal window and type the following commands:

$ ssh <username>@<Turtlbot's IP Address>
$ rosrun map_server map_saver -f  /home/<TurtleBot's username>/my_map

If you do not know the TurtleBot's username, after ssh'ing to TurtleBot, use the pwd command to find it.

The process creates two files: my_map.yaml and my_map.pgm and places them in your TurtleBot netbook home directory. The path and filename can be changed as you desire, but files should be saved on the TurtleBot.

The .yaml file contains configuration information of the map and the path and name of the .pgm image file. The .pgm file is in portable gray map format and contains the image of the OGM.

The map configuration information includes the following:

In the next section, we will examine TurtleBot's mapping process from a more in-depth ROS perspective.

TurtleBot builds maps using the ROS gmapping package. The gmapping package is based on OpenSlam's Gmapping (http://openslam.org/gmapping.html), which is a highly efficient Rao-Blackwellized particle filter algorithm. This approach is based on a laser scan-based SLAM implementation. Although a laser scanner would work the best for SLAM, the Kinect will provide a simulated laser scan for the TurtleBot. The ROS gmapping package contains the slam_gmapping node that takes the incoming laser scan stream and transforms it to the odometry tf reference frame.

The gmapping process is implemented by a set of parameters within the gmapping_demo.launch file in the turtlebot_navigation package. This launch file initiates the 3dsensor.launch file from the turtlebot_bringup package to handle the processing of the 3D sensor. Some of the sensor processing modules are turned off to minimize processing for this task.

The slam_gmapping node subscribes to the sensor_msgs/LaserScan messages from the camera_nodelet_manager node and the tf/tfMessage messages containing the odometry frames. The following diagram from rqt_graph shows the /tf and /tf_static topics (with tf/tfMessage messages) and the /scan topic (with sensor_msgs/LaserScan messages) being subscribed to by the slam_gmapping node. The slam_gmapping node combines this data to create an OGM of the environment. As the robot is driven around the room, the slam_gmapping node publishes the /map topic to update the OGM with an estimate of TurtleBot's location and the surrounding environment based on data from the laser scan.

slam_gmapping node

When the operator issues the command to save the map, the map_saver node of the map_server package gets activated. The map_saver node provides a ROS service to take the OGM data and saves it to a pair of files (the .pgm and .yaml files described in the previous section). Each cell of the OGM records its occupancy state as a color for the corresponding pixel. Free space is identified as white with a value of 0 and occupied space is identified as black with a value of 100. A special value of -1 is used for unknown (unmapped) space. The threshold values within the .yaml file make the pixel values between 0 and 100 categorized as occupied, free, or in-between.

The following are the core terms used for autonomous navigation with TurtleBot:

Amcl: The amcl algorithm works to figure out where the robot would need to be on the map in order for its laser scans to make sense. Each possible location is represented by a particle. Particles with laser scans that do not match well are removed, resulting in a group of particles representing the location of the robot in the map. The amcl node uses the particle positions to compute and publish the transform from map to base_link.

Global navigation: These processes perform path planning for a robot to reach a goal on the map.

Local navigation: These processes perform path planning for a robot to create paths to nearby locations on a map and avoid obstacles.

Global costmap: This costmap keeps information for global navigation. Global costmap parameters control the global navigation behavior. These parameters are stored in global_costmap_params.yaml. Parameters common to global and local costmaps are stored in costmap_common_params.yaml.

Local costmap: This costmap keeps information for local navigation. Local costmap parameters control the local navigation behavior and are stored in local_costmap_params.yaml.

To navigate the environment, TurtleBot needs a map, a localization module, and a path planning module. TurtleBot can safely and autonomously navigate the environment if the map completely and accurately defines the environment.

Before we begin with the steps for autonomous navigation, check the location of your .yaml and .pgm map files created in the previous section.

As in the previous section, be conscious of which commands are on TurtleBot (requiring ssh from the remote computer) and those that are on the remote computer (not requiring ssh). In each terminal window, enter the commands following the $ prompt:

When amcl_demo loads the map of the environment, TurtleBot does not know its current location on the map. It needs a little help. Locate TurtleBot's position in the rviz environment and let TurtleBot know this location by performing the following steps:

A giant green arrow will appear to help you align the direction of TurtleBot's orientation, as shown in the following screenshot:

TurtleBot 2D Pose Estimate

When the mouse button is released, a collection of small arrows will appear around TurtleBot to show the direction. If the location and/or orientation are not correct, these steps can be repeated.

The previous steps seed TurtleBot's localization, so it has some idea where it is on the environment map. To improve the accuracy of the localization, it is best to drive TurtleBot around a bit so that the estimate of its current position converges when comparing data from the map with TurtleBot's current sensor streams. Use one of the teleoperation methods previously discussed. Be careful driving around the environment because there is no obstacle avoidance software running at this point. TurtleBot can be driven into obstacles even though they appear on its map.

Next, we can command TurtleBot to a new location and orientation in the room by identifying a goal:

The following screenshot shows setting the navigation goal for our TurtleBot:

TurtleBot 2D Nav Goal

The following screenshot shows our TurtleBot accomplishing the goal:

TurtleBot reaches its goal

TurtleBot can also perform obstacle avoidance during autonomous navigation. While TurtleBot is on its way to a goal, step in front of it (at least 0.5 meters (1.6 feet) in front of the Kinect) and see that TurtleBot will move around you. Objects can be moved around or doors can be opened or closed to alter the environment. TurtleBot can also respond to the teleoperation control during this autonomous navigation.

In the next section, we will examine TurtleBot's autonomous navigation process from a more in-depth ROS perspective.

At the highest level of processing, ROS navigation acquires odometry data from the robot base, 3D sensor data, and a goal robot pose. To accomplish the autonomous navigation task, safe velocity commands are sent to the robot to move it to the goal location.

TurtleBot's navigation package, turtlebot_navigation, contains a collection of launch and YAML configuration files to launch nodes with the flexibility of modifying process parameters on-the-fly. The following diagram shows an overview of the navigation process:

The ROS navigation process

When the amcl node is launched, it begins providing localization information on the robot based on the current 3D sensor scans (sensor_msgs/LaserScan), tf transforms (tf/tfMessage), and the OGM (nav_msgs/OccupancyGrid). When a 2D Pose Estimate is input by the operator, an initialpose message (geometry_msgs/PoseWithCovaianceStamped) resets the localization parameter and reinitializes the amcl particle filter. As laser scans are read, amcl resolves the data to the odometry frame. The amcl node provides TurtleBot's estimated position in the map (geometry_msgs/PoseWithCovarianceStamped), a particle cloud (geometry_msgs/PoseArray), and the tf transforms for odom (tf/tfMessage).

The main component of the TurtleBot navigation is the move_base node. This node performs the task of commanding the TurtleBot to make an attempt to reach the goal location. This task is set as a preemptable action based on its implementation as a ROS action and TurtleBot's progress toward the goal is provided as feedback. The move_base node uses a global and a local planner to accomplish the task. Two costmaps, global_costmap and local_costmap, are also maintained for the planners by the move_base node.

The behavior of the move_base node relies on the following YAML files:

The global planner and costmap are used to create long-term plans over the entire environment, such as path planning for the robot to get to its goal. The local planner and costmap are primarily used for interim goals and obstacle avoidance.

The move_base node receives the goal information as a pose with position and orientation of the robot in relation to its reference frame. A move_base_msg/MoveBaseActionGoal message is used to specify the goal. The global planner will calculate a route from the robot's starting location to the goal taking into account data from the map. The 3D sensor will publish sensor_msgs/LaserScan with information on obstacles in the world to be avoided. The local planner will send navigation commands for TurtleBot to steer around objects even if they are not on the map. Navigation velocity commands are generated by the move_base node as geometry_msgs/Twist messages. TurtleBot's base will use the cmd_vel.linear.x, cmd_vel.linear.y, and cmd_vel.angular.z velocities for the base motors.

Goal tolerance is a parameter set by the user to specify the acceptable limit for achieving the goal pose. The move_base node will attempt certain recovery behaviors if TurtleBot is stuck and cannot proceed. These recovery behaviors include clearing out the supplied map and using sensor data by rotating in place.