Design decisions for IMU driver

[rbridges12]

For the ROS IMU driver, I've decided to go with a custom solution involving an intermediate arduino processor as well as custom Arduino code and a custom ROS node. At a surface glance, this may seem like a pretty bad decision, given the other possible options. I thought it would be helpful to write this, so future MRover-ers understand why I made this choice.

Let's look at all of the other options I'm aware of, and why I didn't use any of them:

ros_imu_bno055 package

There is an existing ROS package that seems to do exactly what we want. It has you connect the BNO055 board to a FTDI board for UART to USB conversion, then uses a custom made library to read data from UART, and then publish it to ROS. It even has support for loading calibration profiles, which is something that might be really helpful to us.

why I didn't use it

• the package isn't officially supported on ROS noetic
• the package doesn't seem to be maintained, as it hasn't been changed in several years
• I couldn't get the IMU to work in UART mode over an FTDI chip. this could very well have been my hardware and my lack of experience with FTDI boards, but it was a problem I didn't feel like debugging given the above reasons

rosserial on arduino

The rosserial package allows you to run a pseudo ROS node on a microcontroller connected over serial, and it will automatically publish the serial messages to the ROS network. This would make for cleaner Arduino code and would eliminate the need for a custom IMU driver node.

why I didn't use it

• could not get it working on the Nano Every, since it has native USB support and isn't actually supported by the package
• takes up a huge amount of dynamic memory on the Arduino
• does way more than what we need it to, so basically is a super overweight solution

Adafruit python library for Raspberry Pi

This is a library for reading IMU data when the sensor is wired to a Raspberry Pi over UART.

why I didn't use it

• Honestly I didn't find out about this until I was done with the current solution
• using Raspberry Pi software on non Raspberry Pis is notoriously sketchy, so this may or may not work and it may also take a ton of debugging to get working
• Raspberry Pi for Odrives was not ready yet

This one may actually be a good thing to try out in the future if someone wants to simplify the IMU driver system.

Closing Thoughts

I would argue that the solution I came up with really isn't that bad, since it's a pretty small amount of simple code that really gives us more control over exactly what data we want from the IMU. The arduino does add some complexity and a failure point, but in practice it seems to be very reliable once it is flashed. I think the Raspberry Pi library may be a good solution to try out in the future, since we will have a Raspberry Pi on the rover soon, especially if we decide to put 2 IMUs on the rover (one in NDoF mode and one in compass mode).