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

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:

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 you issue 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:

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). At this point, all terminal windows should be closed. Then, open a window as indicated and 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:

The giant green arrow helps you align the direction of TurtleBot's orientation. An example is 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 to modify 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 about the location of 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.

To determine TurtleBot's initial pose on the map, type the following:

$ rostopic echo /initialpose

This will display the initial pose after using the 2D Pose Estimate in rviz to identify the initial position and orientation of TurtleBot in the room.

Our result for the initial pose was as follows:

header:
  seq: 1
  stamp:
    secs: 1500506112
    nsecs: 896815961
  frame_id: map
pose: 
  pose: 
    position: 
      x: 0.172010675073
      y: 0.0527899339795
      z: 0.0
    orientation:
      x: 0.0
      y: 0.0
      z: -0.0139684328787
      w: 0.999902436682
  covariance: [0.25, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.25, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.06853891945200942]
---

For the map we created, TurtleBot's position is roughly in the middle of the map representing the middle of our laboratory.

Using the Publish Point icon, select several points on the map and record the x and y coordinates of each point. The position of the cursor at any point will be displayed in a panel at the lower left of the screen. Alternatively, echo the topic /clicked_point with the following command line:

$ rostopic echo /clicked_point

Our results for two points were as follows:

header:
  seq: 6
  stamp:
    secs: 1500506877
    nsecs: 337500725
  frame_id: map
point:
  x: 3.00541186333
  y: -0.0026988487225
  z: -0.0013427734375
---
header:
  seq: 7
  stamp:
    secs: 1500506893
    nsecs: 543592195
  frame_id: map
point:
  x: 3.03029751778
  y: 3.57522583008
  z: 0.00247192382812

Our map overlays a 10 by 10 grid of squares 1 meter on a side with the origin in the center. Your map, however, may be rotated with respect to the grid, so use the Publish Point method to determine the values on your map so that they can be related to real positions in the room.

Using our map, we chose the following points from the map that indicate locations in our laboratory: (3.0, 0.0, 0.0) for the first goal point and (3.0, 3.6, 0.0) for the final position. The first point is near the wall on the right in the map and the second is near the door to the lab at the upper right corner of the map. At initialization and at the first waypoint, the orientation of TurtleBot will be chosen to be straight ahead as defined by the quaternion (0, 0, 0, 1) along the x axis. At the second waypoint, TurtleBot will be aligned with the y axis of the map with quaternion (0, 0, 0.707, 0.707) indicating approximately a 90 degree change in orientation. The following modified screenshot shows these locations:

Goal locations chosen in rviz

You should choose goal points that relate to your map and replace the items in the list GoalPoints in the following Python script. Execute our Python script by typing in a new terminal:

$ python MoveTBtoGoalPoints.py	

The following Python script named MoveTBtoGoalPoints.py moves TurtleBot to the various goal positions:

#!/usr/bin/env python

import rospy
import actionlib      # Use the actionlib package for client and server

from move_base_msgs.msg import MoveBaseAction, MoveBaseGoal

# Define Goal Points and orientations for TurtleBot in a list
GoalPoints = [ [(3.0, 0.0, 0.0), (0.0, 0.0, 0.0, 1.0)] ,
               [(3.0, 3.6, 0.0), (0.0, 0.0, 0.707, 0.707)]]

# The function assign_goal initializes goal_pose variable as a MoveBaseGoal action type.
def assign_goal(pose):
    goal_pose = MoveBaseGoal()
    goal_pose.target_pose.header.frame_id = 'map'
    goal_pose.target_pose.pose.position.x = pose[0][0]
    goal_pose.target_pose.pose.position.y = pose[0][1]
    goal_pose.target_pose.pose.position.z = pose[0][2]
    goal_pose.target_pose.pose.orientation.x = pose[1][0]
    goal_pose.target_pose.pose.orientation.y = pose[1][1]
    goal_pose.target_pose.pose.orientation.z = pose[1][2]
    goal_pose.target_pose.pose.orientation.w = pose[1][3]
	
    return goal_pose

if __name__ == '__main__':
    rospy.init_node('MoveTBtoGoalPoints')

    # Create a SimpleActionClient of a move_base action type and wait for server.
    client = actionlib.SimpleActionClient('move_base', MoveBaseAction)
    client.wait_for_server()
    
    # for each goal point in the list, call the action server and move to goal
    for TBpose in GoalPoints:
        TBgoal = assign_goal(TBpose)  # For each goal point assign pose
        client.send_goal(TBgoal)
        client.wait_for_result()
    
    # print the results to the screen
    if(client.get_state() == GoalStatus.SUCCEEDED):
        rospy.loginfo("success")
    else:
        rospy.loginfo("failed")

When the program finishes, the terminal display should show success.

This Python script sends goal poses to TurtleBot one pose at a time to move it to a particular location. This code uses the navigation stack as described in the How does TurtleBot accomplish this navigation task? section. The rospy and actionlib packages and the MoveBaseAction and MovBaseGoal messages are used within the script and are imported at the beginning of the code. The MoveBaseAction message defines the action goal, action result, and action feedback specifically for behaviors regarding TurtleBot's movement. The MoveBaseGoal message is used to define the target pose.

The goal poses for TurtleBot are identified in the list GoalPoints. For the Python script, the goal poses in terms of position x, y, z and the orientation in terms of a quaternion were chosen as:[[(3.0, 0.0, 0.0), (0.0, 0.0, 0.0, 1.0)] and [(3.0, 3.6, 0.0), (0.0, 0.0, 0.707, 0.707)]].

Next in the code is the definition of the assign_goal function. The assign_goal function creates a message of type MoveBaseGoal and assigns the values from the pose item in GoalPoints to target pose in this message.

When the main function of this program runs, it creates the ROS node MoveTBtoGoalPoints. Then it creates an action client for the SimpleActionServer, which is configured to communicate with the move_base server and adhere to the behaviors defined in the MoveBaseAction message. The wait statement indicates that a response from the action server is necessary before proceeding to the next lines of code.

The for loop increments through each of the goal poses in the GoalPoints list and causes each of these poses to be processed by the move_base action server. The first statement in the loop calls the assign_goal function to create a MoveBaseGoal message and assign the values of that message to be the values of the goal pose. The second statement calls the action client send_goal function to send the goal to the action server. The process then waits for the server to return the results of the action and the appropriate message is displayed. When we tested our example, the success message appeared on the screen.

As a result in our laboratory, TurtleBot moved toward the wall on the right of the map and turned approximately 90 degrees left and moved toward the door at the upper right. The script completes with the reply:

[INFO] [1499983063.642908]: success

The following screenshot shows the final location of TurtleBot after the Python script is executed:

TurtleBot's final location in rviz

You can check the robot's final position as it moves on the map by typing:

$ rostopic echo /amcl_pose

Our final pose from topic /amcl_pose was as follows:

header:
  seq: 72
  stamp:
    secs: 1500584344
    nsecs: 824573719
  frame_id: map
pose:
  pose:
    position:
      x: 2.95402869322
      y: 3.30398805405
      z: 0.0
    orientation:
      x: 0.0
      y: 0.0
      z: 0.666663241366
      w: 0.745359056168
  covariance: [0.02732330983433684, -0.001682319824116263, 0.0, 0.0, 0.0, 0.0, -0.001682319824116263, 0.002880105195270488, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.004937415284215015]

The indicated position and orientation is reasonably close to the selected values. The pose only can be viewed by typing:

$ rostopic echo /odom/pose/pose

since the covariance is not relevant in this case.

TurtleBot 3 has SLAM and autonomous navigation applications similar to those described for TurtleBot 2. The sequences and commands will be briefly described in the next two sections.