While I was never convinced that Dave’s life was better for having an IMU, for several years he had a DI BNO055 IMU he stole from Carl. This was/is a very popular IMU because it had/has an onchip processor to fuse the mag data with the gyro and accelerometer data to reduce gyro drift, and to filter the individual sensor noise to (supposedly) produce cleaner, more accurate numbers with minimal drift.
My 2020 pre-ROS tests on Carl produced results about as accurate as the encoder-alone computed pose, and fusing the IMU with encoders using an EKF (Extended Kalman Filter) proved beyond my understanding.
Eventually, my DI_IMU failed and at $30 to replace, I started looking at the $14 MPU9250 as a possible replacement. Well that one died as well, and Humble Dave has been mapping, localizing, and navigating with only the 2D LIDAR and encoder odometry.
I bought another MPU9250, and installed the PyPi imusensor (MPU9250 specific) package only to find that the PyPi package is missing three years of updates in the corresponding Github repo. Interestingly, the developer forgot to change the version number all these years so they both claim version 1.0.1. I wasn’t very thrilled with the “Rotate Dave In The Air Six Ways To Sunday” calibration procedure and even less thrilled when the only number that seemed good was roll which Dave only does when I’m holding him in the air trying for calibration.
Not to be discouraged by reality, I found a ROS 2 MPU9250 node and managed to figure out how to build and launch it. It was emitting 190 /imu topics per second which nothing running on the Raspberry Pi could possibly utilize that frequent data. Only problem with lowering the frequency param was a bug in the code that didn’t use the frequency parameter…
Fixed the code, lowered the parameter to 10 Hz, and fired up to see what kind of data it was generating. Looking at the x,y,z,w orientation it just didn’t seem like it was changing when I moved the robot. I noticed the header said frame_id: base_link and thought why would the IMU data be relative to the robot base? That would explain the x,y,z,w not changing since the IMU is fixed to the robot.
I looked to see what the usual frame_id for an IMU is and Google suggests base_link is the most common, but it could be imu_link and then the TF2 could publish the transform from the IMU to the base_link.
All this is just too complicated for me to grasp, which is why I keep wishing some smart folks built all the basic ROS code and all I would need to do is use the high level services and servers like /wall_follow, /dock, /undock, and /drive_to {x,y}. Maybe that much simplicity would be boring?