Summary:
This guide walks you through how to add an IMU to your robot in order to improve the accuracy of your /odom to /base_link transform.
There are many different IMUs you can choose from. The most popular being from Bosch like the BNO055 imu, or from Xsens, or often their are IMU's built into sensors like the Intel RealSense D435i or the SwiftNav Piksi. If your just getting started we recommend trying out either a USB stick or the Adafruit development board for the Bosch 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
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.
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 check! 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 set 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.
