# Iterative dynamic accelerometer calibration

OK, strike the iterative part of accelerometer calibration for the moment. At the start, the quad-frame error vectors (QFEV) look fit-for-purpose, and the intention was that during the course of a flight they would converge towards increasingly better error vectors.  But rather than converging to the ‘right’ value over time, they are diverging rapidly.  For the moment, I’ll have a go just using the initial values and see what happens.

The divergence does seem rather OTT, suggesting a possible bug in the code, so the hunt is on.

## 4 thoughts on “Iterative dynamic accelerometer calibration”

1. What method do you use to calculate the bias/scale from the raw accelerometer data?

• See here: http://blog.pistuffing.co.uk/?p=3701

This does rely on only gravity being present; Phoebe’s flight plans are all based on constant velocity so long term, that’s true, but short term, as her constant velocity targets are preriodically changed (ascent to hover for example) then the real acceleration required to enact these changes will skew the error offsets / gains.

I think I need to kick my Muse out of bed and see what she thinks!

• Also, in-flight you’re introducing some linear acceleration in the EFGV essentially creating a feedback-loop I think. Also, you’re treating any difference between the measured gravity vector and the real one as bias while in reality it could be a combination of bias+scale.
There is a way to compute dynamically the compass offsets but it relies on the fast that scale is 1 and the measured vector is of constant length in time: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCEQFjAA&url=http%3A%2F%2Fwww.ignss.org%2FLinkClick.aspx%3Ffileticket%3D7oH5%2FnHXZyY%253D&ei=AKbcU5GQLNDb4QTCnYHwDg&usg=AFQjCNE5V_YqjleZqKP9muZ_l5NL4u8vIg&sig2=YIoXrj3g45yCSu3eCCvKAg
I’m not sure if it could be adapted to an accelerometer. Not in flight at least.
Another method was to slowly rotate the quad along all axes to obtain a spheroid of measurement points. From this, bias and scale are simple to extract – but the method is not really diy friendly.

I was curious about your previous calibration method – the 2 day one. I assume you were gathering data at 2 temperature points and computing 2 sets of bias/scale from this data, right? What method did you use to compute bias/offset?

• My next post will cover bias / offsets – I don’t have a compass, and I don’t think bias is a necessity, only the bias * offsets – bias * accurate value will just affect the scale of acceleration (error order 2%) but critically 0 acceleration = 0 accelerion because of the offsets.

Regarding the 2 day calibration, the test platform is placed at a fixed known angle. Phoebe is placed on the platform and sensors and temperature read. She’s rotate by 90 degrees and the same happens, repeat until you have a full 360 degree set.

Repeat as the temperature warms up until you get bored or the temperature stops rising.

Knowing (say) the pitch angle of the test frame, but measured both nose and tail down, you can get offset and gain. But because the temperature rises quickly, actually you end up interpolating values at all temperature, assuming linearity between the gaps. Hence a right fiddle. Eventually from the data about gains and offsets are each temperature, it’s then possible to come up with a linear trend line equation the calculate offset / gain at any temperature. Those equations are added to the code.

It works well, but doing it’s a faff, and change your sensor and it needs doing all over again.

This site uses Akismet to reduce spam. Learn how your comment data is processed.