For this week's assignment we'll work with the ROS navigation stack to have each TurtleBot visit known locations. This is a prelude to having the TurtleBot search for mine-like objects.
References and Prerequisites
ROS: We will be using a number of new ROS packages to implement, mapping, navigation and path-planning. Below are the main references for those capabilities. You are not expected to work though these tutorials, but a review of the documentation for each package will help you understand how things are connected.
- gmapping - a ROS wrapper for OpenSlam's Gmapping libraries, used for the generating an grid map of the 2D operating environment.
- amcl - Adaptive Monte Carlo Localization (AMCL) for a robot with a known 2D grid map using particle filters. Based on "Monte Carlo Localization: Efficient Position Estimation for Mobile Robots" by Fox, Burgard, Dellaert and Thrun. This is one of the research papers we will be reading.
- move_base - global and local motion planning
Git Repository / ROS Package
Your submission for this assignment will be a Git repository that contains a ROS package. The name of the repository on the github.com server should be
mrc_hw5 and it should be a ROS package (catkin_create_pkg).
Setup Turtlebot to Sync to Time Machine
Follow the instructions Raspberry Pi Sync Time With Time Machine to setup your Turtlebot to automatically synchronize time with the local time server.
Exercise 1: Making a Map via Teleoperation
For this exercise you will use the gmapping package to generate an occupancy grid map based on the laser range finder data.
- [Laptop] Start the following programs - each in their own terminal window/tab
Start ROS nodes on laptop,
This should bring up rviz
Connect gamepad and start ROS joystick teleoperation
- Place the TurtleBot at the origin marked (yellow tape) on the floor - with zero yaw. This will be the origin of your map coordinates.
- Check to make sure that the turtlebot time is similar to the laptop time (see Setup Turtlebot to Sync to Time Machine above).
Start the TurtleBot nodes
- Introspection Images
- Run the
rqt_graphcommand to visualize the active nodes and topics of the system. Save a copy of the graph in your assignment repository as
- Run the
rqt_tf_treecommand to visualize the coordinate transforms of the system. Save a copy of the tf tree in your assignment repository as
- Run the
- Build a Map
- Using the gamepad, explore the lab area - rviz shows how the mapping system accumulates the information into a map.
[Laptop] BEFORE YOU SHUTDOWN THE ROS SYSTEM
Save the map
This will save two files
map.yamlin your home directory
The resulting map should look something like this...
- Make a copy of your map image file in your mrc_hw5 repository as
- Make a copy of your map configuration file in your mrc_hw5 repository as
Exercise 2: Navigation Relative to the Map and Post-Processing
In this exercise we'll use the navigation stack and the move_base package to plan simple paths within the static map we collected in Exercise 1. We'll use the rviz interface to set commands to the system (initialize the pose and sending goal points). To complete the exercise we will start with the TurtleBot in the origin location shown below and then visit the areas of the map marked as A, B, and C - returning to the origin.
[Laptop] Sync the laptop system clock with the local time server. By default, the laptop uses the NTP service to update the time with a server on the NPS network - see Time Synchronisation with NTP
We need the laptop and the turtlebot to have the same time. We will use the local time server to provide that timing.
To manually synchronize the laptop clock with the local time server (on the frl network at 192.168.11.148)...
[Laptop] Execute the following launch file
Which starts a number of ROS nodes including...
robot_state_publisher: Publishes the robot tf frames for visualization
map_server: Part of the navigation stack, provides the occupancy grid map to the rest of the system.
amcl: Adaptive Monte Carlo Localization to provide a particle filter position estimate relative to the map
move_base: Global and local path planning to move to a pose
Time Sync: The ROS navigation stack uses nodes running on both the Laptop and the Turtlebot. For the system to function correctly, the system time on both computers need to be synchronized to be within 1.0 seconds of each other. May sure to follow the directions at Raspberry Pi Sync Time With Time Machine as described above.
- You can check the clock on each system with the
- If there is too much difference between the computer clocks, you will see an error on the Laptop side
If you see either of those errors, manually sync the turtlebot and the laptop with the time server.
- You can check the clock on each system with the
- Make sure your TurtleBot is located at the origin marker in the lab.
Now start the TurtleBot nodes
- Start a ROS bag file to record all of the ROS traffic
- Save the ROS graph as
- [Laptop] RVIZ (Re-)Initializing the Robot Pose via RVIZ
The AMCL package uses particle filters to localize the robot relative the the map. Doing so requires a fairly good initial idea of map-relative location. By default the system will start with an initial pose of x=0, y=0, yaw=0. If you need to change this - or re-initialize the localization if the robot gets 'lost' - you can use the 2D Pose Estimate button in rviz - - to send a message to the
/acmlnode on the
- [Laptop] RVIZ Sending Navigation Goals
The move_base package does the local and global planning for the TurtleBot to navigate within the map. We can send goals - consisting of a X/Y position and a yaw angle - to the system using the rviz interface.
To send a goal:
- Click the "2D Nav Goal" button
Click on the map where you want the TurtleBot to drive and drag in the direction the TurtleBot should be pointing when it arrives at the goal.
Using this interface, send a sequential goal poses to the system to have the TurtleBot visit each of the areas labeled A, B and C in the image above and then send a final goal near the origin.
Once the Turtlebot has visited all the areas, stop the ROS bag file.
Stopping the Turtlebot - Cancel move_base goals
To cancel the goals sent to the move_base ROS node, you can publish ROS topic from the command line to tell the action server to cancel the current goals.
After completing the experiment, generate a MATLAB figure from the bag file to illustrate the results. The figure should include...
- The map image as a background
- The odometry messages from the
/odomtopic (type: nav_msgs/Odometry Message )
- The pose messages from the
/acml_posetopic. (type: geometry_msgs/PoseWithCovarianceStamped )
- The goal pose messages from the
/move_base/goaltopic (type: move_base_msgs/MoveBaseGoal )
Save the MATLAB script used to generate the figure as
Save the resulting figure as
Here are a few snippets to help...
Plotting background map at proper scale
Extract acml pose data
Extract goal pose data
Note: Adjusting Goal Tolerance Parameters
How the move_base system determines when the goal pose is achieved is determined by the local planner. For this example, the move_base node uses the Dynamic Window Approach local planner. The goal tolerance values are set as input parameters to the dwa_local_planner. These values are set in the configuration file
which means the goal will be considered achieved when the distance to the goal is less than 5 cm and the yaw is within 0.17 radians (~10 degrees).
It isn't necessary to change these parameters, but it is important to know how the system works.
Upon completing the assignment your mrc_hw6 repository should look something like this...