10 part2: Navigating
How does the robot get from here to there, iven a map and AMCL localization

  • Continuing from where we left off
  • We have created a map using slam
  • How do we use it for navigation?
  • Simultanuous Localiation and Mapping
  • We will localize the robot on a map that is incomplete
  • When it leaves the map it is able to extend it with the same algorithm

Reconstruct where we left off

NB Be careful with the filenames of the map. You will get strange errors if the file name given to turtlebot3_navigation is incorrect or not resolvable!
# create the simulated environment called stage_4
$ roslaunch turtlebot3_gazebo turtlebot3_stage_4.launch

# launch a simulated turtlebot3 that drives a random pattern
$ roslaunch turtlebot3_gazebo turtlebot3_simulation.launch

# launch the slam algoritm, which will create an in-memory map data structure
$ roslaunch turtlebot3_slam turtlebot3_slam.launch slam_methods:=gmapping

# After the map looks done, save it into a map file for later.
$ cd ~
$ rosrun map_server map_saver -f stage4
# Now, close all the exiting ROS nodes down and next run this. Be careful with the
# file names because the yaml file contains a file name too and it is easy to 
# get things misaligned. 
# <filemname> will be something like /home/youraccount/stage4.yaml but check to make sure.

$ roslaunch turtlebot3_gazebo turtlebot3_stage_4.launch
$ roslaunch turtlebot3_navigation turtlebot3_navigation.launch map_file:=<filename>

  • Give the robot an estimated position
  • Give the robot a navigation goal by clicking the button in rviz
  • Play around and see the robot solve the simple maze navigation including places it can’t ‘see’ from where it is
  • The ROS nav stack is another complex bit of computer science, mathematics, and engineering
  • For now we are going to just scratch the surface
  • Inputs are a map, an estimated current position, scanner inforamtion, and a destination
  • Behavior is to generate a path and steer the robot to it
  • Avoiding obstacles
  • Roughly:
    1. navigation goal is sent to the nav stack. This is done with an action call with a goal of MoveBaseGoal which specifies a target pose and a coordinate frame (called the map frame.)
    2. Nav stack uses a path-planning algorithm in the global plannner to create shortest path route
    3. Local planner drives along that path, while using sensor information to aboid obstacles.
    4. When the robot arrives at the goal pose the action terminates.
  • Lets try it!
  • Uncheck everything except RobotModel, Map and ParticleCloud in rViz.
  • The green arrows are the pose estimates from amcl
  • Tell amcl that the robot is somewhere else, and you see it do its best on guessing the pose
  • Do this with the 2d pose estimate command
  • Turn on the Lasert Scan display
  • Play with the 2d pose estimate command and observe how the map becomes aligned
  • Also with /initialpose topic (which is how, perhaps, we tell AMCL about a fiducial that has been identified.)
Behind the scenes
  • amcl subscribes to a topic geometry_msgs/PoseWith
  • rviz command 2d pose estimate publishes the new proposed pose on that topic
  • When amcl receives that message it resets its collection of candidate poses
Going inside the Nav Stack
  • Global planner: works out best path assuming map is accurate global costmap: How safe or unsafe is each spot on the map
    • Published on /move_base/global_costmap/costmap
    • Planner view shows what the planned path to the nav goal is
  • Local Planner:
    • Adjusts the global plan based on newly detected obstacles
    • Map shows square area around robot with further analysis
    • Color shows safe areas in cold colors (like blue) and dangerous areas in warm colors (like red)
  • Look at patrol.py
  • It is a SimpleActionClient which sends a repeating sequence of two Action Goals to move_base
  • There’s nothing tricky about itself.
  • The challenge might be getting all the other bits set up so that it will work correctly