Turtlebots

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

The robots automatically connect to the unsw_robotics network. If you are on the same network, or the CSE-Wired network, you can use ssh to connect to a robot: ssh z<studentid>@<robot>

An old simple recipe for running the robots is found here: TurtleBot Usage .

Care and Feeding

The robots are kept in three cupboards on the northern side of the lab (next to the field, closest to the entrance).

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 .

Setup

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.

We have created a roslaunch file to help you gets the robots up and running. To use it you need to:

1. SSH to the robot
2. Source ROS & configure environment variables ROS_IP and ROS_MASTER_URI .
3. ROSLaunch turtlebot software: roslaunch comp3431 turtlebot.launch

To startup the ROS Turtlebot software:

ssh z<student-id>@<robot>
source /opt/ros/comp3431/setup.bash
export ROS_IP=<robot-ip>
export ROS_MASTER_URI=http://<your-machine-ip>:11311
roslaunch comp3431 turtlebot.launch

Notes

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.

Odometry

The robot base ( /turtlebot_node ) publishes Odometry messages on /odom . The Twist component of these contains the differential odometry.

Sensing

There are two sensors on the robot: a gyro and a kinect.

Gyro

The gyro information is published on /imu/data .

Kinect

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 read_points method.

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 rgb8 and bgr8 amongst others.