This page is an explanation of how to get a standalone sensor, the CH Robotics UM7 IMU, working with ROS. If all goes well, this should be an example of one of the advantages of ROS: you don't really have to know much about how to talk to the device because the ROS driver is already written for you and available from the ROS community.
What you will need:
- NOTE: The UM7 should be setup (firmware U71C and calibrated) using the Windows software before you start. (ME4823 students: this is already done for you!)
See UM7 Setup for instructions.
- A functional ROS environment on a PC. These instructions were written based on using Ubuntu 14.04 with ROS Indigo.
- A sensor, the CHR-UM7 orientation sensor, which is available from Pololo. We are using the UM7 version which comes in an enclosure with flying leads. You could also use the UM7-LT version which is just the sensor.
- A USB to serial converter that operates at TTL voltage levels. For this example I used the Sparkfun FTDI Basic Breakout 5V (Note: this can be a tricky bit, see the comments below on the serial interface for more details)
If the directions below work without issue, then you may not need the additional information. However, CH Robotics has a nice page on background/theory-of-operations for orientation sensors: http://www.chrobotics.com/library They also provide a datasheet that specifies the serial communication, a Windows serial program for calibrating the magnetometer and some example MATLAB code: https://www.chrobotics.com/shop/um7-orientation-sensor
Install ROS Driver
The UM7 driver is simple to install and documented on the wiki here: http://wiki.ros.org/um7#Software_Installation:
Making Electrical Connection
The two photos illustrate how to make the electrical connection. For an initial test I simply tinned the wires (apply a little solder so the wires don't fray) and inserted them in the connector on the FTDI board. This is a fragile connection for testing. Once we have everything figured out, you should make a connector.
Since the FTDI board has a 5 V supply we can use that to power the sensor (5V and GND). Then we need to connect the RS232 (TX, RX and GND). Note that the orange wire (the 3.3 supply from the sensor) is not connected.
To illustrate the operation of the device we'll need to run three programs in three terminals.
Terminal 1: We have to have a ROS master node
Terminal 2: Start the driver. See the Serial Ports in Linux page for instructions on how to determine what device (e.g., /dev/ttyUSB0) is connected to the sensor. When you start the driver you should see the red LED on the FTDI board light up briefly (transmitting to the IMU) and then the green LED blinking rapidly (receiving data).
Terminal 3: Use the QT topic viewer to inspect the data from the sensor.
Now, if all goes well you should see data coming in on the rqt_topic window like so...
Note that I've expanded the /imu/rpy topic to display the roll, pitch and yaw in radians. All of the ROS message contents appear to be will documented on the driver's wiki: http://wiki.ros.org/um7
Another handy investigation tool is rqt_plot. You can look at the roll, pitch and yaw like this...
The UM7 documentation indicates that the serial communications with the device is at TTL level of 0-3.3 V. This is problematic when trying to connect to a PC because PC serial ports work at RS232 levels https://en.wikipedia.org/wiki/RS-232#Voltage_levels.
One solution is to use a standalone "level shifter" that will bridge the two voltage levels. There are chips that do this (see MAX232 or MAX3232) and you can buy breakout boards to interface with those chips. Examples are:
For this example I used the Sparkfun FTDI Basic Breakout 5V (DEV-09716). Functionally this single device is both a level shifter (5 V TTL to RS232 levels) and a RS232 to USB converter. The device also has a 5 V output (powered by the USB port) so that you can supply power to the IMU. If you are paying attention you might note that the UM7 communicates at 3.3 V while the FTDI board is at 5 V levels. I was pleasantly surprised that this seemed to be compatible and was able to verify that both RX and TX were functional.