# Iterative dynamic accelerometer calibration

Currently, my accelerometer calibration of offset / gains against temperature requires two days of action, reading the sensors at various angles across a broad range of temperatures to put into Excel to produce trend lines allowing calculation of offset and gain at the current temperature for the X, Y and Z accelerometers.  If you think that sounds difficult and tedious, multiply by two and you’re getting there.  It works but I don’t like it for several reasons:

• off-the-shelf quad manufacturers / DIYers don’t do this
• it’s tuned to a specific sensor – replace a broken sensor with a new one and the calibration needs to be redone
• the calibration can only really be done on a sunny day in winter to be able to get termperature ranges from 10°C (Phoebe sleeps in the garage overnight) to 25°C (Phoebe moves indoors, and as her temperature rises, many samples are taken).

So I’ve been considering how to calibrate the accelerometer in flight.  It goes a bit like this: Prior to take-off

• read the accelerometer many times and take the average while she sits quiet and stable in the ground – these readings are a gravity vector in the quadcopter’s frame (QFGV) and will be flawed due to offset and gain errors.
• Using the QFGV, calculate her angles wrt earth using Euler – again the angles will be incorrect, but testing shows the error isn’t far from the truth
• Use the quadcopter to Earth matrix to convert the QFGV to earth coordinates – the Earth frame gravity vector (EFGV) – in the perfect world, it should read 0, 0, 1 – the perfect world earth frame gravity vector (PWEFGV) but doesn’t in reality
• Subtract the PWEFGV from the EFGV to come up with earth-frame error vector (EFEV)
• Convert that EFEV back from the Earth frame to the quad frame to produce the quad-frame error vector (QFEV).

Now set Phoebe running:

• read the raw accelerometer values every loop, integrating them over the time between each read
• Periodically (roughly 40Hz compared to her spin rate of roughly 440Hz) process the readings by dividing by the elapsed time since last processing to come up with averaged accelerometer readings.
• Subtract the QFEV from the readings to produce a ‘better’ set of quad-frame averaged accelerometer results
• Use this better set of accelerometer results to come up with better angles via Euler
• Use the better angles to convert the original fixed QFGV to a new, more accurate EFGV
• Again subtract the perfect world PWEFGV from the new EFGV to come up with a new EFEV.
• Convert the EFEV back to a QFEV

This should produce an ever improving set of offsets by taking the initial fixed QFGV and constantly refining the quadcopter accelerometer readings with the QFEV.  In doing so, there should be convergence on an accurate value for the QFEV – i.e. the accelerometer is calibrated on-the-fly. Initial testing suggests this might just work, but Phoebe is not getting her @R\$£ off the ground fast enough, so tilting to stop drift is causing the props to clip the ground. More testing later with a more energetic take-off rate will hopefully be more conclusive.

P.S.  All the above is based on the assumption that calculation of Euler angles from raw accelerometer readings is more accurate than the raw sensor readings themselves.  Currently I’m working on gut-feel, but I need to spend the time producing a mathematical proof.

P.P.S.  On the other hand, it’s easy to prove in real-world testing – if not true, then Phoebe will progressively go mad instead of settling into a stable state of affairs.

## 5 thoughts on “Iterative dynamic accelerometer calibration”

1. I’ve been looking at the spec sheet for the MPU-6000/6050 again, Document Number: PS-MPU-6000A-00, Revision: 3.4, Release Date: 08/19/2013. On page 13 is a table of specifications for the Accelerometers. I noticed that the Sensitivity Change vs. Temperature is quoted as 0.02 % / degree C, and nonlinearity is quoted as 0.5% against a best fit straight line.
I would say that this indicates a way of simplifying the calibration, just need to calibrate at a temperature and then take a small number of readings at another temperature or two to determine the gradient of the sensitivity v temperature relationship.
I would also suggest that calibration can be done with the sensor in a rig to control the orientation, inside an insulated box. Could then change the temperature by adding ice in the bottom of the box, for instance. Could also make quite a good temperature controlled environment by using the Peltier heat pump from a cold box (or purchased from CPC / Farnell, CPC search: http://cpc.farnell.com/jsp/search/browse.jsp?N=411&Ns=P_PRICE_FARNELL_CPC|0&Ntk=gensearch&Ntt=peltier&Ntx=mode+matchallpartial&suppressRedirect=true&originalQueryURL=%2Fjsp%2Fsearch%2Fbrowse.jsp%3FN%3D411%26Ntk%3Dgensearch%26Ntt%3Dpeltier%26Ntx%3Dmode%2Bmatchallpartial%26suggestions%3Dfalse%26ref%3Dglobalsearch%26_requestid%3D139318%26No%3D0%26getResults%3Dtrue%26appliedparametrics%3Dtrue%26locale%3Den_CC%26divisionLocale%3Den_CC%26catalogId%3D%26skipManufacturer%3Dfalse%26skipParametricAttributeId%3D%26prevNValues%3D411).
Peltier heat pumps are really handy since the heat transfer effect is controlled by the current of the applied voltage.

• I’ve done that kind of calibration already (http://blog.pistuffing.co.uk/?p=3067 and the next article). It worked well, but took time.

Thanks for the Peltier cooling idea, that does at least overcome the ability to only calibrate in winter – I’ve been looking for an excuse to buy this Peltier beer fridge: http://www.amazon.co.uk/gp/product/B00K9QGL0S/ref=ox_sc_sfl_title_2?ie=UTF8&psc=1&smid=A3PQTXM5JEQT7F

It seems I now have justification!

Ideally though, I’d still prefer to avoid this calibration at all and instead work out the sensor calibration errors by comparison against gravity – it’s not quite working as well as I’d hoped yet 🙁

• If you do decide to use the fridge, remember to take the beer out first. The alcohol might have unexpected side effects on the readings 🙂
Out of interest, do you know how close your accelerometer array is to the centres of rotation about each of the three axies? I seem to think, although at the moment I can’t justify it, that an offset would add to the error. Still tossing ideas around in my head at the moment though.

• At the moment, the sensor is at the level of the props. With the battery slung possibly 10cm lower, I suspect the CoG is probably 5cm below the props. It’s also perhaps a cm out from the Z-axis

I don’t think it affects rotation readings, but it does mean that when she rotates, there is lateral acceleration as well detected by the sensors.

It doesn’t seem to cause a significant problem, and I can’t get the sensor much lower in the current build, but I do have a plan to use an A+ and a custom PCB when available to lower the sensors and the weight, and improve the rigidity of the build.

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