-
Notifications
You must be signed in to change notification settings - Fork 3
Bad bias Instability and Speed-dependent optical sensor errors #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Hi there, thanks for your feedback and data!
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!
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.
This would probably also be improved by using a lower angular velocity range, since the noise floor would be lower.
Again, this would require a different IMU in a future hardware revision (if and when we do that).
This one is more difficult to nail down the root cause, as there are a number of possible sources of error.
|
Hi! 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. STB |
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. |
The surface is wood desk.
Angular and linear sacaler is not set. Sorry, this result was |
Sorry, IMU calibration code on micropython code by M5StickC seems not to be performed well. The XRP kit has just arrived, I tried qwiic_otos_ex1_basic_readings.py, but has error.
Then, I fixed the code and tried.
The code is here. By the way, does a lower sensor height improve accuracy? The exmaple qwiic_otos_ex1_basic_readings.py (Installation is here https://github.com/sparkfun/qwiic_otos_py?tab=readme-ov-file#micropython-installation)
Created other issue. |
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.
Correction: 10mm - 27mm
Thanks, we'll take a look at that. |
Thank you for your kind response. |
Uh oh!
There was an error while loading. Please reload this page.
Hi, I would like to use this module for a pen plotter robot with 1mm positioning accuracy.
However, current firmware has 2 issues.
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
The text was updated successfully, but these errors were encountered: