I have been using the BMO055 for the last few months as a heading sensor in our robot. There is
noticeable drift in the heading reading which seems to happen in a number of scenarios:
These are some of the things I'm going to try
What other steps can I take to mitigate against these problems?
Solved! Go to Solution.
Which working mode you are currently using? NDoF or IMU mode?
Which virtual sensor is used in your application to get the heading result.
Do you have clear image for the magnetic environment for the testing ara?
I think the steps you do are correctly for calibrated the sensor during running. and i will recommend you to stop the robot in periodic interval. Before you do the testing, calibrate the sensor first.
Currently operating in NDoF mode using the Yaw component for heading.
There are two test areas (250km apart):
- An open field (relatively smooth terrain, no metal, no concrete)
- An enclosed shed (Metal everywhere, concrete floor, rough terrain).
I'm seeing similar behavour in both locations (for the same route and distance travelled).
How long do I need to stop the robot for to allow the sensors time to readjust?
Can you provide some data log to check the issue?
this data log should contain the raw accel, gyro and magnetic data.
i will suggest the robot to stop every 1 minute for 2- 3 seconds to see if it helps.
what is the frequency of the motor?
I have been logging data for the last while with heading, calibration parameters and calibration status. I have been testing the sensor on a test bed to apply constant roll or pitch motion for a specifc angle and frequency so that I can change parameters and see results for identical mechanical input. The motor frequency is around 490Hz, the sensor itself is about 35cm away from the motors. I have also put a compass in the area around where the sensor is mounted, I am not seeing any sudden deflections. I have a number of observations, I have included these in the data log too.
I have found that the pauses you recommended do improve the result, 60 seconds is a bit too long, it still drifted.
Pausing every 20s for a duration of 2s is good.
There are about 250seconds of instability after (physical) calibration before it settles.
There are about 55 seconds of "lag" where (manual, software) calibration values are programmed (during setup) before they are visible in the calibration data outputs. Sys reports zero for all that time and then it changes to 3 at which point everything works fine. In another scenario I apply the same calibration at regular intervals during a standard 15min test, it works fine with only one zero value before returning the correct heading.
The lag I suspect is potentially due to my startup routine, I see other users on the forum talking about initialisation sequences for the sensor so I'm currently looking at that.
While the pause approach helps significantly , ideally we don't want to pause the robot as when people are watching it operate it looks like something is wrong when it intermittently stops.