ROS2 IMUs - the good, the bad and the ugly

[Sergei Grichine]

About a month ago, I fell into a rabbit hole. While trying to find a ROS 2 driver for a cheap ICM20948 IMU, I made the mistake of looking at the driver code. Well… it looked back at me.

Naturally, I then decided to look at other IMU drivers. Oh boy.

After weeks of polite AI chats, bug chasing, and endless testing, I now have a pretty good idea of what these sensors really are, how to deal with them, and how to make even the most stubborn ones purr like kittens (okay, that last part might be just shameless bragging).

I’ll share my findings later, but in the meantime, if you’re interested, take a look at these short AI-generated essays I requested along the way:

https://chatgpt.com/s/t_696582d5e9dc8191a60202516bb5c9eb
https://chatgpt.com/s/t_6965833c504c81918d34ae2e7c24c77d

Spoiler: if you want no trouble, use BNO085 and my fork of the driver

Best Regards,

-- Sergei

[Michael Wimble]

Gotta love your writing style. “ The ICM-20948 hands it to you… and then sets it on fire. “

On Jan 12, 2026, at 4:32 PM, Sergei Grichine <vital...@gmail.com> wrote:



--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CA%2BKVXVNa1u6-g-rj-n9mvkO0ASKrAStqMAmM6YoVbxxPP%2BEitQ%40mail.gmail.com.

[Sergei Grichine]

"...The ICM-20948 hands it to you… and then sets it on fire...“

Well, Michael, strictly speaking - we are here for entertainment, not engineering. I am trying, but that's AI who really delivers.

The interesting part is that those essays were generated in the same continuous dialogue which I used for testing and debugging all those mentioned drivers. So, the accumulated prompt was, probably, huge - considering that this is a paid account. And, honestly, I was pleasantly surprised how specific and (mostly) accurate the Iron Brain's hallucinations came out to be. Better than mine for sure. And yes, the ICM20948 was a pain - as the AI eloquently stated for both of us.

Best Regards, 
-- Sergei
   

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/E2288F68-92A5-4630-920F-65B6CB40B48C%40gmail.com.

[Stephen Williams]

Nice.

At CES, I visited the Bosch booth.  They were suggesting these new IMUs:

BMI088 - "High stability and low temperature drifts.  Vibration robustness.  Closed-loop gyroscope."
BMI423 - "Extended measurement range (32g and 4000dps). Integrated feature set for activity tracking, head movement, and UI applications."
BMI563 - "Extended measurement range (32g and 4000dps). Vibration robustness.  Low noise."

Smart sensor: BHI360 - "Integrated sensor fusion software.  Open programmable platform. Low power MCU."

https://www.bosch-sensortec.com/products/smart-sensor-systems/bhi360/

$5.56 for one, $4.22 @ for 100.  Oddly, this one does not support i3c.

"The BHI360 belongs to the BHI family of highly integrated, ultra-low power programmable smart sensor systems. The
BHI360 integrates the Fuser2 processor, which is based on the 32-Bit ARC™ EM4™ floating point RISC processor, an in-
tegrated Inertial Measurement Unit (6DoF IMU) and a powerful Event-Driven Software Framework specifically designed
for signal data processing and comes with pre-installed sensor fusion and other sensor data processing algorithms.
The BHI360 offers two secondary high speed master interfaces with I2C and/or SPI capability, and up to 8 GPIOs which
can be configured in a flexible way (e.g. Chip Select or Interrupt lines). In this way, the BHI360 can be used as a “Sensor
Hub” connected to external sensors and devices, such as magnetic field sensors, pressure sensors and many more.
All sensor data from both integrated MEMS IMU and external sensors can be efficiently integrated, synchronized and
processed by the integrated Fuser2.
The BHI360 is mainly intended to be used as coprocessor, offloading the main CPU from any sensor data processing
related tasks, like sensor fusion, data batching, position tracking, activity recognition and gesture detection with high
precision and low latency while significantly reducing the overall system power consumption. When used as a copro-
cessor, the BHI360 supports a wide variety of host CPU devices, ranging from a small MCU up to multicore application
processors. The BHI360 communicates with the Host CPU through its primary high speed I2C or SPI interface."

Magnetometer: BMM350 - "Unique field shock recovery feature.  High accuracy and ultra-low noise.  Low power consumption."

The thing I am really excited about are the pressure sensors.  More about those later.

One thing that is interesting about these is that they support several communication methods, including I2C, I3C, and SPI.  They can be used with 4 wire daisy chain or even simple trees without termination at high speed supported by newer MCUs.  I3C is the new method:

"I3C (Improved Inter-Integrated Circuit) is a high-speed, low-power, two-wire serial communication interface from the MIPI Alliance for connecting computer chips, acting as a successor to I²C, offering better performance, efficiency, and features like dynamic addressing, while maintaining backward compatibility for legacy I²C devices. It's used in mobile, IoT, and embedded systems for sensor integration and control, combining benefits of I²C and SPI interfaces for simpler, more flexible designs with faster data rates (up to 12.5 MHz SDR) and reduced pin counts. "

I will be looking for MCUs with i3c support from now on.  Many sensors with 2 wires (plus power), simpler wiring, no addressing headaches, at high speed and high frequency sampling.

sdw

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CA%2BKVXVMnXXU_LBzs4yx-TNR2G_8XonGKx4yrU0KqiaXOejQYQg%40mail.gmail.com.

--

Stephen D. Williams Founder: VolksDroid, Blue Scholar Foundation 650-450-8649 | fax:703-995-0407 | s...@lg.net | https://VolksDroid.org | https://BlueScholar.org | https://sdw.st/in

[James H Phelan]

Team,

Remarkable literary skill on the part of GPT!

A colleague here in Houston was researching using a building's variable magnetic field as a map.

I've often wondered how sensors, particularly magnetometers/compasses handled the magnetic fields of nearby motors.  But I never hear talk or complaints about it.  Are the motors well shielded?  Perhaps the metal ones, but surely not the cheap plastic jobs?

This weekend I laser cut, drilled and tapped a new IMU mount for Stormy the Stingray.  It sits smack at the origin right between the motors.  Now I can try my BNO085.

Is there an app to observe what happens to the magnetic field while the robot runs?

James

James H Phelan
"Nihil est sine ratione cur potius sit quam non sit"
Leibniz

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CA%2BKVXVMnXXU_LBzs4yx-TNR2G_8XonGKx4yrU0KqiaXOejQYQg%40mail.gmail.com.

[Sergei Grichine]

James,

Rviz2 shows magnetometer vector, you just click on the checkbox to enable it if using my dev branch. Rqt shows values in Teslas. Works in sim too.

For some drivers mag publishing is optional, enabled by a parameter.

Best Regards, 
-- Sergei
   

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/c3cefab5-3cf7-41e9-90d7-34b58e5baddc%40hal-pc.org.

[Michael Wimble]

Don’t forget that ‘ros2 bag’ is available for recording and playing back data. When I run my robot, I frequently record nearly every topic then later playback the data into rviz2 or foxglove and get various visualizations. I also write software to do analysis on the sensor data. This is a great way to work on tuning or adding new features or answering questions like, “I wonder how that works”.

[Pito Salas]

Have you (or anyone) used the Waveshare General Driver For Robots? It has a AK09918C 3-axis electronic compass and QMI8658 6-axis motion sensor. Where does that fit in your rogues gallery of IMUs? 

From time to time, in Rviz, with Odom as global frame, I see the robot spin slowly (even though it is stationary.) I've more or less isolated it to the imu (by turning it off ekf.yaml config). I am wondering if the IMU on the board (QMI8658) might be the culprit.

Also do you know whether IMUs like this one require a "calibration" procedure to compute various biases? What I've seen is that it "self calibrates" but I dont know what that means.

Thanks

Pito

[Karim Virani]

The Waveshare general driver board packs a lot of punch for its pricetag, but I'd be careful about depending on its IMU. This is the same board that drives their ROARM product. So my notes on the robot arm has details. Search within the page for imu and you'll find my specific notes. Note the imu is 6 DOF,  and there's a separate compass module for magnetometer axes, so the issue may be the firware's sensor fusion. TLDR: yaw is not reliable out of the box. You could try to roll your own sensor fusion.

--

You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/73ccd06e-02e7-4ae8-af2e-89fa80266415n%40googlegroups.com.

[Pito Salas]

Thank you. Any idea why yaw is not reliable, that is just the one I am having trouble with! And suggestions on how to overcome that?

Best,

Pito

Boston Robot Hackers &&
Comp. Sci Faculty, Brandeis University (Emeritus)

> To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CAKtnkiwZAqyi3JSKH4A3HTP3SyYmHGqFp_dDyyRheF2pznXgEw%40mail.gmail.com.

[Chris Albertson]

Use more than one IMU, one at each end of the robot to counter the spinning. Separate them by as much distance as you can and orient them differently. Yes, both gyros will still drift, but the EKF will never find a fit where the robot itself spins. With two IMUs, if one falsely reports a spin, then the other would then be moving in an arc. The idea is to mount them in such a way that their errors will not be statistically correlated.

With two IMUs, we can now use accelerations to determine rotations, so we have another independent way to measure rotation. EKF will do much better after the more independent ways it has to calculate each degree of freedom.

Also, the usual algorithm self-calibrates. What it does is wait for a time when it knows 100% that the robot is stationary, then reads the rates on all 6 axes. It then uses these rates as bias and removes them. This is not 100% perfect but can be good. I read a paper where someone was able to capture near-perfect foot motion with just one IMU mounted to a shoe because he observed that when the foot is in contact with the ground and supporting weight, it is motionless and the only acceleration is 1G of gravity. So they switched from collecting motion data to collecting calibration data every time they detected ground contact. With robots, when the encoders say “zero,” we know there is no motion. I think you apply some filter to the calibration because the data is so noisy. You cannot simply calibrate once in the lab, it has to be a continuous process

[James H Phelan]

Sergei & Others,

Has anybody successfully used the BNO085 in the OAK-D depthcamera in a robot?

James

James H Phelan
"Nihil est sine ratione cur potius sit quam non sit"
Leibniz

--
You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CA%2BKVXVNa1u6-g-rj-n9mvkO0ASKrAStqMAmM6YoVbxxPP%2BEitQ%40mail.gmail.com.

[Sergei Grichine]

James,

My Kickstarter OAK-D Lite doesn’t have an IMU, so—sorry—no personal experience there. Also, if you mount the camera without a movable joint, there’s no real need to use its IMU: your robot’s main IMU, together with the appropriate xacro TFs, already tells you exactly where the camera is pointing.

Using a camera IMU (or any exotic IMU, for that matter) as the primary IMU for your robot is just asking for trouble—don’t ask me how I know. 😄 Use a known, well-supported device like the  BNO085 , and the gravitational, gyroscopic, and magnetic forces will be with you. ;-)

https://github.com/slgrobotics/robots_bringup/blob/main/Docs/Sensors/OAK-D_Lite.md  - my notes on the OAK-D just in case.

Best Regards,

-- Sergei

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/cf6ff020-9814-4024-8b4f-038b2b33dbb4%40hal-pc.org.

[Michael Wimble]

What is the characteristic of the unreliability?

IMUs have yaw drift because of a couple of things. One, heading can’t be observed from gravity, so the accelerometers don’t help. Accelerometers are pretty good for using the gravity vector for static roll and pitch. Two, there is a built-in drift from the semiconductor technology used in rate gyros.

The IMUs I’ve used mostly suck with the magnetometer readings. The magnetic vector is kind of weak, easily influenced by nearly everything around it, including People’s magazine choice of the sexiest man, as far as I can tell, and the magnetic vector comes in nearly vertically where I live so it seems a bit of an ask to get a reliable reading. As with GPS systems, it’s pretty good if you are actually moving, and a lot like asking your mum’s sister about where North is when you’re just standing still.

The gyros, or rate gyroscopes as are used on IMUs, really measure rate of turn, not absolute turn. They come up with a psychic’s-worth of yaw estimation by integrating those turns. If you turn too slowly, you're integrating noise. If you stand still, the rate gyros have a bias built into them. In my limited measuring, the bias is not even or constant. It’s affected by temperature and it seemed to me to be more pink noise than white noise. For the BNO055, I’ve seen reports that the bias will show a drift of something like 3 degrees per minute.

What I tried doing in the past was something similar to what Chris was suggesting. When turning, the gyro is a bang-on good estimate of the actual turn. The detector for turning overwhelms noise and bias. When I did the maze solver, I ignored the gyro until I wanted to turn, then I read the current yaw, however fictitious that value was, started turning, and did a constant reading of the current heading, and then stopped when I achieved the delta turn I wanted. That worked a treat. Another trick I tried was to use the heading, but every time the robot stopped and the localization service finished doing its loop-closure-solving-thingy, I would capture the localization’s notion of heading and the gyro’s notion, and when moving again, I would correct the gyro’s heading from that captured difference.

Sergei seems to believe that his IMUs work well outdoors. We have yet, however, to bet any significant money on his robots being able to turn accurately on the basis of IMU alone, so until money crosses my palm, I take that with the same value as I take his mother’s opinion of his good looks.

In my house, the magnetometer is much, much worse than using a random number generator. But the Kalman filter is pretty amazing at listening to a small room full of liars and sussing out a pretty good truth. I did try Chris’s suggestion of using multiple IMUs so that the yaw drift canceled out, but it ended up making my localization much worse. It was probably operator error on my part, and I’ll probably revisit that someday, but with AMCL tuning, I get pretty good localization with one LIDAR and one IMU into a Kalman filter.

I have two LIDARs and two IMUs on my robot but the two LIDARs do two different things. Otherwise it would be like trying to figure out the time from two watches. I might incorporate a fallback action of using the other sensor when one fails, but that’s down around item 200 in my prioritized list of things worth doing next.

[Karim Virani]

I "overcame" the problem by switching to a different IMU. Not all IMUs are equal. The BNO055 has been my goto for years now. And I use it in IMU mode with the magnetometers turned off. The DPRG folks have heard me mutter "magnetometers are evil" so many times it's starting to lose its funny.  Magnetometers at ground level, particularly indoors or unknown environments, are flakey and unreliable. Yes they can get much better after calibration and with great on-device kahlman, you can get a drift resistant signal. But the cost is the calibration process. Almost all of the calibration effort and time is around handling hard and soft iron deflections - the magnetometers. But my requirement is to power on the robot and have it operational without calibration time. 

This is where a magnetometer free mode comes in handy. So the BNO055 comes out of the box that way and the yaw signal on it is remarkably stable. Once you start moving, the yaw will drift, and that drift rate will be temperature dependent, so I have other sources of yaw correction available. But the drift is slow and the signal is accurate over minutes of operation. It's a great short term relative heading reference. This is entirely unlike the yaw signal coming from the General Driver Board. It's simply unstable and jumps around a lot. There is no reason for why it should be worse than the BNO055 unless the MEMs components are just lower quality. The pitch and roll are usable - they are clearly being fused with the paired accelerometers which have the stabilizing gravity vector to rely on. But the yaw implementation is just bad. I went a few rounds with Waveshare support on trying to get an explanation or work-around, and this is the one time they failed to come up with anything useful. Some imus are just junk. 

BTW, Waveshare has a sister to the GDR called the ROS Driver for Robots. It's a very similar but slightly better (4 quadrature inputs) all-around board. This is the board they use for their higher end rovers.  Last time I checked they didn't sell it on the website, but it can be purchased if you contact sales by email. It has a different IMU / magnetometer combo. I have one but never got around to measuring the yaw output on it. Remember that both of these boards were designed right around pandemic chip shortages. 

Note the BNO055 is the precursor to the 085 and the 086 which have different firmware (optimized for other use cases), but the same MEMs components. The Bosch line is my gold-standard for consumer grade IMUs. 

To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/2A601C04-AC2A-4196-B270-DA9CC9C149CC%40gmail.com.

[Pito Salas]

Thanks everyone. I learned a small thing that I was not clear on that might explain things. I might have been innocently handling the robot at the moment I power it up. Just pick it off the bench, turn it on and put it on the floor. From what I gather this IMU and others do a self-cali during the first few seconds after power off.

Now I consciously put the robot on the floor and then turn it on (from a few experiments.) I look at the rotation (yaw) coming out of the IMU, and it is totally still, I see a constant zero yaw interspersed every so often (3-5 seconds) by a very short pulse reading of rotation and then back to zero. Not sure yet whether that’s normal, imagined, spurious or what.

So lesson: make sure the robot is totally still and stays so when you power it on.

Maybe everyone already knows this :)

Best,

Pito

Boston Robot Hackers &&
Comp. Sci Faculty, Brandeis University (Emeritus)

> On Jan 16, 2026, at 6:03 PM, Karim Virani <ponder...@gmail.com> wrote:
>
> I "overcame" the problem by switching to a different IMU. Not all IMUs are equal. The BNO055 has been my goto for years now. And I use it in IMU mode with the magnetometers turned off. The DPRG folks have heard me mutter "magnetometers are evil" so many times it's starting to lose its funny. Magnetometers at ground level, particularly indoors or unknown environments, are flakey and unreliable. Yes they can get much better after calibration and with great on-device kahlman, you can get a drift resistant signal. But the cost is the calibration process. Almost all of the calibration effort and time is around handling hard and soft iron deflections - the magnetometers. But my requirement is to power on the robot and have it operational without calibration time.
>
> This is where a magnetometer free mode comes in handy. So the BNO055 comes out of the box that way and the yaw signal on it is remarkably stable. Once you start moving, the yaw will drift, and that drift rate will be temperature dependent, so I have other sources of yaw correction available. But the drift is slow and the signal is accurate over minutes of operation. It's a great short term relative heading reference. This is entirely unlike the yaw signal coming from the General Driver Board. It's simply unstable and jumps around a lot. There is no reason for why it should be worse than the BNO055 unless the MEMs components are just lower quality. The pitch and roll are usable - they are clearly being fused with the paired accelerometers which have the stabilizing gravity vector to rely on. But the yaw implementation is just bad. I went a few rounds with Waveshare support on trying to get an explanation or work-around, and this is the one time they failed to come up with anything useful. Some imus are just junk.
>

> BTW, Waveshare has a sister to the GDR called the ROS Driver for Robots [ponderbotics.com]. It's a very similar but slightly better (4 quadrature inputs) all-around board. This is the board they use for their higher end rovers. Last time I checked they didn't sell it on the website, but it can be purchased if you contact sales by email. It has a different IMU / magnetometer combo. I have one but never got around to measuring the yaw output on it. Remember that both of these boards were designed right around pandemic chip shortages.

>
> Note the BNO055 is the precursor to the 085 and the 086 which have different firmware (optimized for other use cases), but the same MEMs components. The Bosch line is my gold-standard for consumer grade IMUs.
>
> On Fri, Jan 16, 2026 at 1:58 PM Pito Salas <pito...@gmail.com> wrote:
> Thank you. Any idea why yaw is not reliable, that is just the one I am having trouble with! And suggestions on how to overcome that?
>
> Best,
>
> Pito
>
> Boston Robot Hackers &&
> Comp. Sci Faculty, Brandeis University (Emeritus)
>
>
> > On Jan 16, 2026, at 2:12 PM, Karim Virani <ponder...@gmail.com> wrote:
> >
> > The Waveshare general driver board packs a lot of punch for its pricetag, but I'd be careful about depending on its IMU. This is the same board that drives their ROARM product. So my notes on the robot arm has details. Search within the page for imu and you'll find my specific notes. Note the imu is 6 DOF, and there's a separate compass module for magnetometer axes, so the issue may be the firware's sensor fusion. TLDR: yaw is not reliable out of the box. You could try to roll your own sensor fusion.
> >
> > On Fri, Jan 16, 2026 at 6:26 AM Pito Salas <pito...@gmail.com> wrote:
> > Have you (or anyone) used the Waveshare General Driver For Robots? It has a AK09918C 3-axis electronic compass and QMI8658 6-axis motion sensor. Where does that fit in your rogues gallery of IMUs?
> >
> > From time to time, in Rviz, with Odom as global frame, I see the robot spin slowly (even though it is stationary.) I've more or less isolated it to the imu (by turning it off ekf.yaml config). I am wondering if the IMU on the board (QMI8658) might be the culprit.
> >
> > Also do you know whether IMUs like this one require a "calibration" procedure to compute various biases? What I've seen is that it "self calibrates" but I dont know what that means.
> >
> > Thanks
> >
> > Pito
> >
> > On Monday, January 12, 2026 at 7:32:13 PM UTC-5 Sergei Grichine wrote:
> > About a month ago, I fell into a rabbit hole. While trying to find a ROS 2 driver for a cheap ICM20948 IMU, I made the mistake of looking at the driver code. Well… it looked back at me.
> >
> > Naturally, I then decided to look at other IMU drivers. Oh boy.
> >
> > After weeks of polite AI chats, bug chasing, and endless testing, I now have a pretty good idea of what these sensors really are, how to deal with them, and how to make even the most stubborn ones purr like kittens (okay, that last part might be just shameless bragging).
> >
> > I’ll share my findings later, but in the meantime, if you’re interested, take a look at these short AI-generated essays I requested along the way:

> > https://chatgpt.com/s/t_696582d5e9dc8191a60202516bb5c9eb [chatgpt.com]
> > https://chatgpt.com/s/t_6965833c504c81918d34ae2e7c24c77d [chatgpt.com]

> >
> > Spoiler: if you want no trouble, use BNO085 and my fork of the driver
> >
> > Best Regards,
> > -- Sergei
> >
> > --
> > You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

> > To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/73ccd06e-02e7-4ae8-af2e-89fa80266415n%40googlegroups.com [groups.google.com].

> >
> > --
> > You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
> > To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

> > To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CAKtnkiwZAqyi3JSKH4A3HTP3SyYmHGqFp_dDyyRheF2pznXgEw%40mail.gmail.com [groups.google.com].

>
> --
> You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/2A601C04-AC2A-4196-B270-DA9CC9C149CC%40gmail.com [groups.google.com].

>
> --
> You received this message because you are subscribed to the Google Groups "HomeBrew Robotics Club" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hbrobotics+...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/hbrobotics/CAKtnkixHLMoYYOBF%2Bwukm2nyrYUxCG69r3dox0ZGwTpLtnOHug%40mail.gmail.com [groups.google.com].