Integrating an IMU


Integrating an IMU

Summary:

This document walks you through the initial setup and tuning of an IMU onboard a Rover.


This walk through assumes you are using the Starter Kit and are able to drive the robot around with the controller.

 

We recommend using either a USB stick or the Adafruit development board if this is your first time using the BNO055

 

Step 1 - Plug in bosch imu device and verify new ttyUSB*

 

This can be done by running the command ls /dev/ttyUSB* to list ttyUSB devices. There should be two ttyUSB devices listed, one is the rover, the other is the Bosch BNo055 IMU. Unplugged and replug the IMU to determine the ttyUSB number or

Step 2 - Start bosch_imu_node with rosparam port=/dev/ttyUSB* and verify data is spitting out

Below is the node setup in a launch file. Replace the * in ttyUSB* with the BNO’s.


   <!-- Bosch BNO055 Driver -->

   <node pkg="rr_bosch_bno055_imu" type="bosch_imu_node.py" name="bosch_imu_node" >

       <param name="port" value="/dev/ttyUSB*" />

       <param name="frequency" value="30" />

   </node>


If the node throws an error trying to open the port, then your probably trying to open the Rover’s ttyUSB. If the node it runs and you can echo a topic and are get data, excellent! Time to setup a UDEV rule so you never have to worry about enumeration issues on ttyUSB devices causing incredible headache in the future.

Step 3 - Setup udev rule

Do the following command to create the udev rule file. It may already be created and if it is, just move on to the next step.

sudo touch /etc/udev/rules.d/89-roverrobotics.rules


Run the command below to find out the serial number of the ttyUSB device. Again, one of the ttyUSB devices will be for the Rover, the other is the bosch.


udevadm info --attribute-walk --name=/dev/ttyUSB0 | grep serial


Next, copy the ARRTS{serial} output from the previous command and replace the existing ATTRS{serial} in the line below.


KERNEL=="ttyUSB[0-9]", SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{idProduct}=="6001", ATTRS{idVendor}=="0403", ATTRS{serial}=="FT9P9S9I", GROUP="dialout", SYMLINK+="imu"

Finally, add the line above to the 89-roverrobotics.rules file created initially. Then reload the file using the following command…


sudo udevadm control --reload-rules && sudo udevadm trigger


This creates a symlink for the imu so the imu appears as /dev/imu keeping you from needing  to chase down its ttyUSB* everytime the robot is power cycled. Without this symlink, ubuntu will randomly switch the ttyUSB’s of devices causing incredible headache down the line. Finally run the following command to refresh the UDEV rules and if everything was setup properly, you should see /dev/imu when you ls /dev as shown below.




Step 4 - Verify in RVIZ IMU fixed transform is correct

Start up the imu node and rviz and start rolling it around to make sure the fixed transform from your imu_link to base_link is correct. Tweak the transform as necessary. My rviz gets angry trying to display IMU info so I find it easier just to pipe the imu data through an ekf node and then turn and move the robot to verify the transforms. The launch file for an ekf setup for just the imu is below. Make sure to change the imu0 param to the topic your imu is publishing to. Continue to step 5 if you are checking the IMU transforms with the ekf, otherwise, you are ready to move on to Rover Robotics Tutorial 3 - Fusing IMU + Wheel Odometry.

Step 5 - Another Box Test

If you have the ekf integrating the IMU data, do another box test as a sanity! Note, integrating just IMU data will result in a drifting orientation however if the EKF node is setup properly, the robot position shouldn’t drift. If it is, this could be due to an incorrectly rosparam, most likely imu0_remove_gravitational_acceleration. Below is an example of a good enough box test in RVIZ. If this is about what you see, then your ready to move on to Rover Robotics Tutorial 3 - Fusing IMU + Wheel Odometry.

 

Sources and Documents

Rover Robotics Docs Page

rr_openrover_basic ROS Wiki