This page holds links useful for the COMP3431/9431 use of the TurtleBot robots.
- We are using the ROS system for controlling our robots.
- TurtleBots have a web page, but that mostly describes the hardware. There is also a page in the ROS wiki for TurtleBot software, tutorials and some simulations.
- Our robots are using the i heart engineering parts. This might be relevant as different suppliers use different gyroscopes.
The turtlebots are called: Splinter, Leonardo, Donatello, Raphael, Michelangelo
You can use ssh to connect to a robot:
As the Pioneer robots also use ROS, until TurtleBot specific pages are generated it might be useful to look at their notes.
I have put a simple recipe up on TurtleBot Usage.
Care and Feeding
The laptops on the robots can be plugged in as expected. Power on the iRobot Create base is a little more tricky. The robots will only charge when in 'Passive' mode. You can put the robot in Passive mode either with the TurtleBot Dashboard, or by making sure the robot is switched off when you plug it it. Note: Simply looking at the LEDs on the robot is not enough to tell if it is switched off.
When the robot is off, all LEDs are off. (Remember, the opposite is not true: all LEDs being off does not mean the robot is off.) When you turn it on, the main power LED will light up green. If you plug in the serial conneciton, its centre LED will light. If you then start the turtlebot software, the robot's LED will go out, and the two arrow LEDs on the white serial connector will light up as well as its centre LED. You can now use the robot.
To shut things down you need to:
- unplug the serial cable, and
- turn the robot off with its power button.
Note that if you simply unplug the serial cable, the robot will still be switched on even though no LEDs are lit. To actively verify the robot is switched off you need to switch it on and then switch it off.
The iRobot Create base will charge when plugged in (when off/in Passive mode). When charging the LED on the base will pulse orange. When finished charging the LED will sit green. If the robot base has any power drain then it will charge, the LED will switch to green and then the battery will discharge. The base will not switch back to charging until unplugged and re-connected to the power. This is an easy way to have a flat battery when you go to use the robot.
If the robot is out of power then it will beep and turn itself off.
See also the ROS Wiki Care and Feeding page.
You should already have ROS set up.
We do not have anything starting by default on the robots. If anything robot related is running when you log in, that will cause problems. The robots are set up to list everyone running a process on the robot when you log in. If anyone apart from you is listed, then you probably want to reboot the robot's laptop.
You can bring up the basic turtlebot software with the command
roslaunch turtlebot_bringup minimal.launch. Most of the ROS wiki instructions assume you have already done this (the standard setup has this happening automatically on boot, but we're not doing that).
Moving the Robot
The robot moves by receiving
Twist messages on the
/cmd_vel topic. These twist messages specify a velocity. The robot doesn't go very fast, so if you send it a speed of 1 m/s it will not actually move that fast. The robot will stop a short time after it receives its last message. If you want it to keep moving, you need to keep sending it messages.
The robot base (
Odometry messages on
Twist component of these contains the differential odometry.
There are two sensors on the robot: a gyro and a kinect.
The gyro information is published on
A depth-map with colour information is published as a
PointCloud2 on the
/camera/rgb/points topic (once the kinect is running). This works better than trying to get images and depth maps and merge them yourself. Accessing a PointCould2 from Python is messy. There is some code to help. Look at the
Note that some elements of some of the fields can be NaN (Not a Number - the result of a division by 0). The read_points code can filter these points out for you if you pass in the correct arguments.
The colour in a PointCloud2 is sometimes encoded strangely. In particular, the header says that the
rgb field is a float. Really you should interpret it as 4 bytes, one byte for each of red, green and blue. The fourth byte is generally 0. One way to get this data out is to modify the
_get_struct_fmt() function in the
point_cloud2.py code above so that it gets three bytes for the rgb field rather than one float.
I have also come across yellow and blue appearing swapped in the point cloud colours. This appears to be because the red and green channels are swapped. I couldn't see a way of detecting this from the PointCloud2 structure, but I will note that the ROS
Image type has an
encoding field that can take values of
bgr8 amongst others.