The goal of this lab is
to get you started writing software that controls a (simulated) robot using ROS.
to create your own control strategy for a mobile robot.
to test your code in simulator and on a real robot.
ROS2 variant here!
Before you start this lab, you should know the concepts in ROS tutorials.
ROS-VM extra package install steps (not needed on the lab PC-s):
sudo apt-key adv --keyserver 'hkp://keyserver.ubuntu.com:80' --recv-key C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654
sudo apt-get update
sudo rm /var/lib/dpkg/lock-frontend
sudo rm /var/lib/dpkg/lock
sudo apt-get install ros-melodic-stage*
sudo apt-get install ros-melodic-teleop-twist-keyboard
If the VM moves slowly, you can install the extension pack for VB.
Starting the simulator/teleop
If you have not run, you should run in the terminal(s): source /opt/ros/noetic/setup.bash
Stage is the robot simulator that we're going to use for this lab. You can use to start directly the Stage:
rosrun stage_ros stageros $(rospack find stage_ros)/world/willow-erratic.world
Start the teleop keyboard with:
rosrun teleop_twist_keyboard teleop_twist_keyboard.py
to move the robot around. Here you can download teleop, if it is not in your workspace. Do not forget to run roscore!
Creating a new package for your own teleop
Make a new ROS package called wander (in the catkin_ws/src) with the appropriate dependencies(roscpp, geometry_msgs, and sensor_msgs). Make sure that the package is in your ROS_PACKAGE_PATH and that ROS can see it (i.e. do not forget to run the source command to overlay the variables, i.e. source ./devel.setup.bash is launched from the catkin_ws).
Fill in the information in the manifest file. You don't need to do this to make your code work, but it's good practice, and it will help us when we get round to grading your code, since we'll know who to give the points to.
Write a node that drives your robot forward. Here's some C++ to get you started. Make sure that the node works, by running it and watching the robot in the simulator. Play around with the command structure, and see what you can get the robot to do. Do not forget to update the CMakeLists.txt in order to include your code in the build process and to build(catkin_make) the project! Do not forget to stop teleop_keyboard before you send commands from your node!
run your compiled node (i.e. run catkin_make first, than rosrun pgk_name node_name). Do not forget to stop the teleop_keyboard node first!
Adding reactive behavior for your node
See what topics are available using rostopic list. Use rostopic echo -n 1 to look at an instance of the data on some of them. Figure out which one is the data from the laser scanner on your simulated robot. Figure out which one is the odometry (the position and orientation of your robot).
Modify your node to get the robot to stop at 50cm away from an obstacle. Use the data from the laser range-finder to do this. Check out this C++ code. Make sure to include sensor_msgs and geometry_msgs in the dependencies(package.xml). Also do not forget to have a look at the structure of the laser messages.
Extra credit: Extend your algorithm in order to avoid your to get stucked.
You can use either C++ or python for this lab.
A quick way to make sure your package directory is in the ROS_PACKAGE_PATH is to try roscd . If you end up in the right place, it's in the path. If not, then you're not.
When you fill in the dependencies in the manifest, you should only put in the ones that you absolutely need. Putting in more won't (generally) break your code, but it will slow down compiling (if you're using C++) . It's also bad practice, since it tells the system (and anyone looking at your code) that you're using packages that you're not.
Do not forget to update your CMakeLists.txt.
e.g: add:
add_executable(${PROJECT_NAME}_node src/forwardmove.cpp)
target_link_libraries(${PROJECT_NAME}_node
${catkin_LIBRARIES}
)
If you use roslaunch, you do not have to run roscore manually.
To get the python code to run, you'll need to set the execute privs on it. To get the C++ code to run, you'll have to edit the CMakeLists.txt file and compile the code. Watch out for the dependencies in the manifest file.
Don't send commands to the robot too quickly, without using a rate-limiting sleep. It will flood the communications channels, especially when you're using a real robot over a wireless link. About 10Hz is fine for the robot you'll be using.
This lab, as with all of the future labs, has stuff that's open to interpretation in it. You need to decide what "within 50cm of an obstacle" means. Does it mean 50cm from the front of the robot? 50cm from any part of the robot? 50cm from the sensor? There's no particularly "right" answer, so use your judgment and try to implement something that would be sensible on a real robot.
Want to test on a real robot? Here are some useful hints!