View Full Version : [Question(s)] Estimating accelerometer bias

07-27-2012, 01:23 AM

I want to estimate the bias of the x, y, and z acceleration data from my IMU. I would appreciate help guiding me toward this goal. I'd like to take this one step at a time since the process is more involved that one would have thought.

First, here are steps I've take so far in my test software:
1) I read the IMU accel data and attitude (pitch, yaw, and roll) at approx 10hz.
If I don't watch the waveforms using a graphing tool I developed using Qt
open source library then I can sample as high as 500hz.
2) I convert from gravities to m/s^2
3) After transforming accel vector in sensor frame to local tangent plane navitgation frame, I add gravity vector (0,0,9.81m/s^s) to cancel out gravity.

As seen from the attached screen shot, I'm left with accel in navigation frame and each component has a bias.
Red, Green, Blue lines correspond with x, y, and z. Dashed lines correspond to resultant accel and solid lines correspond to accel after using a low pass butterworth 2 pole filter.

IMU is sitting stationary on a level counter. Yaw some heading but pitch and roll are <1deg.

Ultimately, I'd like some guidance on best way to estimate and remove the bias, but at this point it makes sense to get some feedback. I would appreciate your constructive comments.



07-27-2012, 05:36 AM
The static gravity is just another form of bias.

Is this for a single system? If so, I'd average out those measurements over some time, and simply subtract those out as static (constant) bias. If you move the system to somewhere else, you might want a "calibration" mode where it does that automatically.

Another option is to use a slow integrator for the bias -- a very slow low-pass filter on the signal, and subtract the output of that low-pass filter. This will auto-calibrate within some amount of time, no matter what your situation is. This ends up measuring high-pass filtered data on the other end. If you expect to be going up hills for a minute at a time, then this mechanism will end up under-reporting the slope, and once you're up the hill, it will report a slope when there isn't one. Changing the low-pass filter to a Kalman filter will slightly improve this behavior, but it's an inherent danger in "adaptive" systems -- they adapt :-)

07-27-2012, 09:38 AM
It's a "single system". According to IMU's datasheet (3space TSS-EM, USB I/F), the IMU's already scaled, so I assume the bias introduced by gravity is 9.81 and the rest is bias from other causes. But you've helped me realize that once I'm in the navigation frame and "level", bias removal with or without gravity included is the same.

Now I want to understand "slow". for a low pass filter the parameters to know are sampling rate and cutoff freq. Upon reviewing the code, I notice that I'm configuring the BW filter for 40Hz and 2Hz cutoff. In order to "slow" LP filter, what do you suggest?

I'm not sure how to best characterize this so that you have all the information you need to understand my situation. I'm sampling at ~10hz, as seen in the screen shot. But, after looking at graph at higher sampling rate I realize that at lower rate I'm not extracting all the noise component. Does this undermine my ability to estimate bias? I think the obvious answer is YES, but maybe not in the scheme of things.

BTW, unfortunately this IMU does not have a broadcast mode, where it continually provides updates at a set rate, like say the CH Robotic's Chr-UM6 IMU (with TTL serial) that I've been using and may want to go back to. So, I have to poll it.
Once I've worked this out it has to work in real-time to be useful for me. But I'm considering reimplementing my test code to buffer up samples at a reliable rate, for a given period of time, and then performing my analysis on the bias.

I look forward to your next reply, Thanks