This week you are going to practice building a map and learn how to use ROS Navigation Stack to move your robot around in a "patrolling"-style behaviour.

MAP OF THE REAL WORLD: A zip of the map files is available here - make sure you unzip it in the right place.

Task 1: Setup and map building

1. Create a package called minitask4. You'll need a folder called maps in this package for later, and a patrol.py file.
2. Open a terminal, and launch the house environment in Gazebo: roslaunch turtlebot3_gazebo turtlebot3_house.launch
3. In another terminal, start SLAM to create your map: roslaunch turtlebot3_slam turtlebot3_slam.launch slam_methods:=gmapping. This will automatically run rviz and add the map visualisation.
4. You will manually create your map by running the teleoperation node (new terminal again...!): roslaunch turtlebot3_teleop turtlebot3_teleop_key.launch
5. When you are satisfied you have explored the whole area, save the map by running: rosrun map_server map_saver -f mymap

This command saves the map in the current folder. Although you can put the map in your home folder, it is good practice to store the maps in a maps directory - which is why we created one inside minitask4 earlier. Put the resulting map files there (*.yaml and *.pgm).

You might be wondering what the different overlays are in the map visualisation inside RViz. Part of this is the costmap, which provides important navigation information. The TurtleBot packages contain a fully-configured costmap, which is what you're seeing in the overlay, and configuring a costmap is beyond the scope of this course. However, if you'd like to learn more, you can start with Resource 1.

Task 2: Learn to use the ROS navigation stack to move to goal positions

First, shut down gmapping and teleop (do not shut down not Gazebo), and launch the navigation file using roslaunch turtlebot3_navigation turtlebot3_navigation.launch map_file:=`rospack find minitask4`/maps/mymap.yaml. If you're having trouble using rospack to find your map, you can replace the whole parameter with a hard path to your map for now.

In the RViz window, perform the initial pose estimation so that your robot has a good idea of where it's starting from. We will do this manually first by pressing the 2D Pose Estimate button in the menu bar (although you can also set the initial pose programmatically). A green arrow will appear. Move your mouse on the map, where your robot should be and while holding down the left mouse button, drag the green arrow to the direction where the robot’s front is facing. You can do this multiple times and it doesn't have to be perfect, as the localisation will improve once the robot starts moving (you may try localisation first with the turtlebot3_teleop_keyboard node, if you wish).

Note: this may take you a few tries! The RViz interface is a little bit clunky when it comes to clicking and holding/dragging.

Open a terminal and echo the topic /move_base/goal before you do the next part. Leave that terminal running...

Now, we'll send a navigation goal to your Waffle using the RViz interface. This is done by pressing the 2D Nav Goal button in the RViz menu. This time a large pink arrow appears, which can be used in a similar fashion to mark the desired destination for the robot. The root of the arrow is the x and y position of the robot, and the orientation pointed by the arrow is the theta direction of the robot. Click (and hold!) this arrow at the position where the robot will move, and drag it to set the orientation.

This will create a plan to reach the goal and will start driving your Waffle. The navigation planner is part of the ROS move_base navigation stack (Resource 2). If you're interested in developing your own planner, you can use Resource 3 (but this is beyond the scope of what we cover in this course). In the case a valid plan cannot be created, the goal position will fail. There is some extra information in Resources 4 and 5 about tuning the navigation stack, if you're interested.

Go back to the terminal where you echoed /move_base/goal. What is the message type published to this topic? What components does that message have?

A note about /move_base/goal

/move_base/goal doesn't work in quite the same way as other topics we've got used to in ROS. Everything we've used before has either been a publisher or a subscriber - sending or receiving information without caring about who's listening or who's sending. Instead of fitting into this publisher/subscriber structure, move_base implements another important concept in ROS - an action. With an action, we're able to keep track of the response to our request for an action to be completed (we call this a "request/reply" structure).

In the context of /move_base/goal, we're able to ask the action interface for information on whether or not we've reached our goal position. Resource 6, in particular section 1.1.2, gives you more information on how to query the action interface. If you want more detailed information on how actions are implemented in ROS, Resource 7 talks about actionlib. In Resource 9, you can find a tutorial on how you can send goals to the navigation stack.

Task 3: Program your robot to automatically move in between set waypoints

Your main task in this workshop is to program your robot to move in between set waypoints using move_base. You will demonstrate this patrolling behaviour by putting a waypoint in each room and making your robot automatically move between at least 6 different waypoints.

Hints for implementation:

• Read the above note about /move_base/goal :)
• You can use RViz, while echoing /move_base/goal, to find the (x, y) coordinates of different points on the map
• You can publish goal positions to /move_base/goal. Goals are PoseStamped messages. However, a better way is to use the actionlib Resource7 to send goals programmatically. This allows you to preemp goals. Have a look at this tutorial in Resource 9.
• You will need to know when you've reached a waypoint before moving to the next one, so you'll need to make use of actions (Resources 6 and 7) to get feedback on your goal completion

Finally, how would you implement this waypoint behaviour into your existing behaviour structure? How would that help if you had an unreliable or out-of-date map?

Submission

Push your code to gitlab, tagging your final version as minitask4. Please remember to push and tag all of your final submissions for all the minitasks :)

Resources

Resource 1: Costmaps

Resource 2: ROS navigation stack

Resource 3: Writing a planner plugin

Resource 4: Basic Navigation Tuning Guide (ROS Wiki)

Resource 5: ROS Navigation Tuning Guide by Kaiyu Zheng

Resource 6: move_base

Resource 7: actionlib

Resource 8: TurtleBot3 navigation stack

Resource 9: Sending Goals to the Navigation Stack