Consistently inaccurate acceleration values
Closed this issue · 5 comments
Hi, I have the filter implemented running at an update rate of 50Hz, and I'm having a weird issue where at startup and while sitting flat on a table, the magnitude of the linear and earth acceleration will drift to around 0.1g over the course of around 5 seconds. Once it reaches 0.1g it stays pretty constant, with a bit of random noise.
I compared the magnitude of the raw acceleration readings from my sensor with the magnitude of the Earth frame readings without gravity removed (obtained by using rotation matrix and raw data), and the two were basically identical, so clearly there isnt any weird scaling going on.
My guess is that the calculated quaternion is just a bit off from the true value, so the gravity vector gets subtracted at the wrong angle, which I think could cause the magnitude of the resultant xyz acceleration to go up? I just want to make sure its not something simple to fix before I keep messing with it.
I was also testing it by measuring acceleration of a car on flat ground, and the magnitude of the acceleration would go up pretty accurately, but it wouldnt go back down once acceleration stopped until it hit what seemed like the 5 second acceleration rejection timeout. This one is a little confusing to me though, since I don't see how the quaternion should be changing if the sensor keeps the same (mostly) orientation, which is what I would imagine is making the linear acceleration "stick" at a different reading.
Maybe there are some settings I could adjust to get this to work better? I don't know a ton about the different ahrs filters so it may be that I chose one that isn't good for big acceleration changes.
The acceleration rejection feature was specifically developed to increase accuracy in the kind of scenario you have described - a car accelerating and breaking. If this is your application then I would like to better understand the issue and the limitations that may be affecting your system.
You described undesirable behaviour at startup. Algorithm initialisation is described in the README. Your system should monitor the flags and regard the algorithm output as unreliable during the initialisation period.
50 Hz is a low sample rate. You should consider that, even if the frequency content of interest is low frequency, the motion you are measuring may contain significantly higher frequencies that must be accurately measured to achieve overall reliable tracking. For example, the motion of a car is typically low frequency, but if the car goes over a pothole then there will be a high frequency spike in angular velocity and acceleration measurements. In practise, this may be observed as reliable tracking on smooth roads and then a large step change in the error appearing with the pothole. I suggest you increase your sample rate during development, and reduce it as an optimisation to be investigated once reliable performance in your application has been established.
Please can you share a plot demonstrating the issue you are reporting. I suggest you use the Python examples for this.
I have actually tried 100Hz and had the same issue. The accelerometer takes 0.01s to sample, so the actual frequency is a little less than 100Hz because of the time the filter takes to execute. The attached was recorded at 100Hz sitting flat on a table without any motion. I don't have any stuff from in a car since I didn't record the raw data for that one. Will have to get back to you on that.
From just looking at the raw data, my accelerometer has some bad values on startup and takes a few seconds to get some correct data. I tried waiting to start the filter after 5 seconds of just polling the accelerometer, but that didn't seem to make a difference in terms of where it converges to. Both results are attached, where after around 5 seconds, they have converged to the issue I was talking about in the first post.
I also saw on some other site people talking about running the filter at a frequency at least 10 times faster than the sampling rate to get good results. (towards the bottom on here https://pypi.org/project/imusensor/). Im not sure where they're getting this from since it doesn't look like any of the python examples or other implementations of the madgwick filter I've seen even do this, plus it doesn't really make sense why you would want to process the same data multiple times if you aren't using some kind of iterative process which I dont think the madgwick filter is?
I just used the default plotting stuff in the advanced_example.py example, so let me know if I should upload different plots/data instead of that.
You are correct that it does not make sense to run the algorithm ten times faster. I expect that suggestion referred to original code published in 2011. The algorithm has evolved allot since then, benefiting from more than a decade of experience developing IMU products and providing consulting services to a wide range of applications.
In your plots, the Acceleration error climbs from 0 to 5 degrees after algorithm initialisation, while the device is stationary. This suggests that your gyroscope measurements have significant offset errors. The gyroscope should measure 0 degrees/s when it is stationary. I suggest you perform some basic gyroscope calibration to fix this.
If you wish to share further plots then please can you be clearer how the plot demonstrates the issue you are reporting. You may wish to annotate the plot, or adjust what and how data is being plotted.
Good call on the gyro readings, I went back and looked at the recorded data, and the readings from the gyro are trash. Super noisy. I have two of the same board and I tested it on both, one of them fluctuates between +/- 5 deg/s on most of the axes, the other fluctuates between +/- 19 deg/s!! on the z axis which is really bad. I just averaged the angular rate (deg/s) with it sitting stationary for a while and then just hardcoded that value in as an offset to the readings for each gyro axis, and that actually seemed to help a good amount. Still not perfect, but the magnitude of acceleration without gravity has dropped to about half at maximum which I can live with. Im really surprised that both of my IMUs have so much noise, and the readings from them are weird too, I never get anything past 2 digits of precision from them (excluding floating point errors), which makes me think there's something weird going on getting the incoming data. The readings are generally correct though, just from experimentally rotating it 90 degrees and tracking the deg/s*dt, the measurements mostly line up with the actual rotation.
I also applied the same type of calibration to the accelerometer, except just scaling all of the x,y,z readings by the average magnitude of the acceleration the accelerometer read just sitting still for a while. That ended up being around 1/1.032 so not a huge difference, and Im also not sure how valid doing something like that is, since you would really have different errors for each axis. The accelerometer and magnetometer data already gets run through a low pass filter before going into the madgwick filter, so I may try some type of filtering on the gyro data as well.
All of that being said, is there a way to decrease the weight of the gyro readings in the filter?
Attached are two plots, one with no offset error corrections applied (same data as my second plot from last post), and the second one with the offset error correction applied.
no offset correction (same data as my second plot from last post)
offset error correction applied
The graph below shows the stationary gyroscope output for the Bosch BMI088, configured for an output data rate of 50 Hz. The peak-to-peak noise is two orders of magnitude less than you have reported (±0.2°/s vs ±19°/s). The BMI088 is a modern MEMS IMUs, priced at <4 USD. There is clearly something very wrong with your hardware/configuration and you need address this before any other signal processing development.
I warn you against any low-pass filtering other than the anti-aliasing built into the sensors. The gain in the algorithm settings allows you to adjust the influence of the gyroscope relative to other sensors. However, I suggest that you do not adjust this and instead fix the source of the problem - the poor quality sensor data.