Bad bias Instability and Speed-dependent optical sensor errors

[uecken]

Hi, I would like to use this module for a pen plotter robot with 1mm positioning accuracy.

However, current firmware has 2 issues.

1. Even when stationary, it rotates about 0.01° every 2 seconds (=18°/h). This instability is very bad compared to the other IMU module BNO085

2.The faster the moving speed, the larger the distance error.

While I was following this issue, I checked the following article. I will try this if possible.
https://github.com/sparkfun/SparkFun_Optical_Tracking_Odometry_Sensor/tree/main/Firmware/Lookup_Table_Calibration

Is there any way to solve issue 1?
It seems that the IMU does not have a temperature compensation function, but even so, what needs to be fixed to cause poor bias stability immediately after calibration?
I suppose it is unavoidable if the bias stability of the LSM6DSO is originally poor, but I feel that it is too bad.

According to below document, higher-end model LSM6DSR's bias instability is 5 degree/hr.
LSM6DSO's bias instabiity is not written.

Here are some points I think could be improved. If you have any advice, I would be grateful.
・Large angular velocity range ±2000 dps (degrees per second)
・Calibration with short-time samples (64 samples)
・No temperature calibration function

[sfe-SparkFro]

Hi there, thanks for your feedback and data!

1. Even when stationary, it rotates about 0.01° every 2 seconds (=18°/h). This instability is very bad compared to the other IMU module BNO085

I believe this is a limitation of the IMU itself, I don't think there's a way to make it better in firmware. To my knowledge, it does not have any kind of temperature compensation or similar, so higher bias instability is to be expected than higher-end IMUs. This was determined to be acceptable for the first version of this sensor, because the primary application was FIRST Tech Challenge robots that only run autonomously for 30 seconds, so well under 1 degree by the end. However, totally understand that other applications may need more accuracy for longer, so we can definitely consider a better IMU for a future revision, if and when we do that!

・Large angular velocity range ±2000 dps (degrees per second)

Because the primary application is FIRST Tech Challenge robots that can easily have very high rotation rates during collisions, the max velocity range of 2000 dps was chosen as default for the firmware. One possible improvement for future firmware is to make this configurable via the I2C registers.

・Calibration with short-time samples (64 samples)

This would probably also be improved by using a lower angular velocity range, since the noise floor would be lower.

・No temperature calibration function

Again, this would require a different IMU in a future hardware revision (if and when we do that).

2. The faster the moving speed, the larger the distance error.

This one is more difficult to nail down the root cause, as there are a number of possible sources of error.

1. As documented in the Lookup Table Calibration documentation, the calibration in the firmware was created using the foam surface used in FIRST Tech Challenge. My limited testing of other surfaces showed this to be an improvement all around, however you may be able to get better accuracy by performing the calibration on whatever surface you're using.
2. If you look closely at the final accuracy plot, you'll notice "ridges"; some speeds result in slightly higher resolution than nominal, some are slightly lower. It's possible that the exact speed you're running at lands in one of these ridges, so you may get better accuracy by traveling at a slightly different speed (not necessarily faster or slower, just different).
   • 

[STB3]

Changes_OTOS_BMI323_v3.zip

Hi!
There is no need to make a new PCB for using a different IMU. The Bosch BMI323 is 100% pin compatible.
In terms of noise etc. it is superior to the LSM6.
It gives me (using the BMI built in calibration + the SW calibration) approx 0.3 degrees drift in 5 min (3.6°/h). The BMI has 16 bit registers and some other features so the firmware changes are quite big. I'm using the library with the STM32G491.

I attached the files that I modified. It is a bit ugly. Better style would be to create own .c .h files for the BMI.
I did not remove the STM32G491 specific changes. Use a merge tool, then it is easy to spot the mandatory modifications.

STB

[uecken]

Wow, thank you for your advice.
So you say the footprint is same.

BMI323

LMS6DS0

I have no experience replacing small surface mounted ICs. Can I remove the LMS6DS0 using a heat gun and then solder the BM323 again with the heat gun?

Then, upload this Changes_OTOS_BMI323.zip files to STM32C0?

[STB3]

Yes, the footprint is identical, I'm using both IMUs on the identical PCB.

Removing with a heat gun at approx. 360°C should work. Soldering the new one can be tricky. I'd dispense low temperature solder paste (Sn42/Bi58 from Chipquik) and use the heat gun at 250°C to solder it. Higher temperatures often destroy the LGA packages when doing it at home.

Concerning the SW, it is not enough to simply replace the files you need to understand the changes because there is some code in I used for the G491. I'd recommend checking the code first and if it compiles without errors you can modify the HW.

[sfe-SparkFro]

Good to know about the BMI323, thanks for sharing @STB3!

@uecken I forgot to ask, what surface was used when you acquired this data? And how high was the sensor positioned above the surface?

[uecken]

@sfe-SparkFro

The surface is wood desk.
The sensor height is almost 1cm.
Will upload the photo.

https://photos.google.com/share/AF1QipP5YnHrYbnPP3WSc-DmbEN-X_fp6kc8H916-n2LqNGDcZCMMkvIFrMhvj1UumTEsg?key=WHpjYWVua3hna1NrM3lqZG9vcXI2b2xYSFdmRjZB
Now using microPython on M5StickC.

Angular and linear sacaler is not set.

Sorry, this result was

[uecken]

Sorry, IMU calibration code on micropython code by M5StickC seems not to be performed well.
(The reason why I tested it with M5StickC first was because the XRP kit had not arrived yet.

The XRP kit has just arrived, I tried qwiic_otos_ex1_basic_readings.py, but has error.

>> %Run -c $EDITOR_CONTENT

MPY: soft reboot

Qwiic OTOS Example 1 - Basic Readings

'id' argument required
error: failed to connect to i2c bus
The device isn't connected to the


 system. Please check your connection

Then, I fixed the code and tried.
The accuracy is good.

Position:
X (Inches): 0.0
Y (Inches): 0.0
Heading (Degrees): -0.005493164

Position:
X (Inches): 0.0
Y (Inches): 0.0
Heading (Degrees): 0.0

Position:
X (Inches): 0.0
Y (Inches): 0.0
Heading (Degrees): -0.005493164

Position:
X (Inches): 0.0
Y (Inches): 0.0
Heading (Degrees): 0.0

Position:
X (Inches): 0.0
Y (Inches): 0.0
Heading (Degrees): 0.0

Position:
X (Inches): 0.0
Y (Inches): 0.0
Heading (Degrees): 0.0

Position:
X (Inches): 0.0
Y (Inches): 0.0
Heading (Degrees): 0.0

The code is here.
qwiic_otos_ex1_basic_readings_2.py.txt

By the way, does a lower sensor height improve accuracy?
I know that a range of 100mm - 270mm is good.

The exmaple qwiic_otos_ex1_basic_readings.py (Installation is here https://github.com/sparkfun/qwiic_otos_py?tab=readme-ov-file#micropython-installation)
"MicroPython v1.25.0 on 2025-04-15; ESP32C6 module with ESP32C6" can works fine.
"MicroPython v1.25.0-preview.beta06 on 2025-02-17; SparkFun XRP Controller (Beta) with RP2040" cannot work well.
"MicroPython v1.25.0 on 2025-04-15; Raspberry Pi Pico with RP2040" cannot import github:sparkfun/qwiic_otos_py. here is logs. cannot find the device.

C:\Users\thefu>py -3 -m mpremote mip install --target "" github:sparkfun/qwiic_otos_py@examples


C:\Users\thefu>py -3 -m mpremote mip install github:sparkfun/qwiic_otos_py

Created other issue.
sparkfun/qwiic_otos_py#2

[sfe-SparkFro]

By the way, does a lower sensor height improve accuracy?

This is not something I've tested much myself. Most of my testing has been at 10mm with the foam surface used in FIRST Tech Challenge. At least on that surface, I do know that changing the mounting height by more than 1mm can start to affect the tracking accuracy, particularly at higher speeds. You could try different mounting heights to see if that makes an improvement for your surface.

I know that a range of 100mm - 270mm is good.

Correction: 10mm - 27mm

Created other issue.
sparkfun/qwiic_otos_py#2

Thanks, we'll take a look at that.

[uecken]

Thank you for your kind response.