To date I have been unsuccessful at using the DI IMU to accurately maintain a true heading for either of my robots - Carl using Raspbian For Robots, or Dave using ROS2 over Ubuntu.
This is quite frustrating given the pervasive use of IMUs in watches, phones, and everybody else’s robots!
I recently bought a Quest 2 virtual reality headset to play virtual table tennis. The Quest 2 has two hand controllers that presumably each have an IMU, and I am guessing another IMU is contained in the headset. To enhance the realism, I have locked my right controller into a “Paddle Adapter” so that I can use the “pen-hold” grip I learned to play with (50 years ago).
Unlike the “shake-hand grip” which uses both sides of the paddle, the pen-hold grip player (usually) only uses one side of the paddle for both forehand and backhand shots, and usually plays with the “Red Side Rubber”.
The reason this is relevant: When executing the wind up for a fast forehand shot with the red side of the paddle adapter, the controller ring is briefly out of visual line of sight to the headset blocked by the player’s shoulder and arm. The paddle will sometimes vanish or become virtually displaced from the controller causing a missed point.
It seems the headset is using the controller IMU output, and the visual of the controller ring to correct or verify the IMU orientation and position data. Using the blue/black side of the paddle keeps the controller ring more visible resulting in no tracking errors.
I thought the GoPiGo3 encoders would serve this function for the DI BNO055 IMU, but I have not the smarts to configure the EKF (Extended Kalman Filter).
Perhaps Dave needs to enter the metaverse (use 3D vision with the IMU).
I wonder if that’s what the Turtlebot 4 does (at least in part). The OAK-D can do a lot of the processing locally, relieving some of the burden on the Raspberry Pi.
We had a table tennis table in the garage when I was a kid. My dad liked the pencil grip, but I preferred traditional handshake.
/K
At the point in time that I returned my TurtleBot4, it did not make any use of the stereo 3D data it was publishing.
Odometry was generated by the Create3 platform using a fusion of wide wheel-base encoders, IMU, and the very precise downward facing visual flow sensor.
The wide wheel-base is very good for a robot, but the large size of the bot was actually one of my detractors to the Turtlebot4, offset by the positive self docking feature.
To have a ping pong table, a garage, and a dad … sounds fun.
One thought is the age of the technology used by the DI IMU.
I would suspect that current IMU technology is considerably more accurate than the relatively ancient technology used then.[1]
Maybe if I could find a pin-compatible modern IMU chip, we could experiment with it? (I could perform experiments and send the data to you for analysis.)
[1] The new chip would have to physically replace the older chip - and hope that they’re command compatible too.
I haven’t found any better spec’d IMU for the price. The BNO055 is well respected and is still among the top three IMUs chosen for robots.
There are many experiments possible - first and foremost would be to try the driver package available via apt, to compare with the DI driver and my “safe/hardened” adaptation of the DI driver.
But I think the problems are more rooted in the complexity of the concepts and the need for understanding the math. How I passed all my advanced math classes (differential calculus, fluid and gas dynamics, boundary layer analytics, even applied statistics) is a mystery, as I never understood the concepts or the why, only the how to answer a particular problem. I was never able to generalize with a math toolset. Thus when the problem includes “create the covariance matrix with expected error”, I know I am in way over my head.
