Accelerometer drift proof and solutions

These are readings direct from the 3 accelerometers with virtually zero code tinkering – specifically no subtraction of gravity; the only code modifying the sensor data values is fixed calibration values, fixed unit conversion and averaging. None of these three should cause the decline in the Z-axis (yellow) line against the right-hand axis.

Z-axis drift

Z-axis drift

So I need to do something about this, in particular the Z axis which is the cause of my ever climbing flights.  3 approaches:

  1. give in and add an altimeter – but I’m waiting for the next revision of the DroTek board that has the pin spacing I needs – however this wouldn’t be ideal for indoor flights due to air pressure changes as people open doors etc
  2. give in and add ultrasonic range finders – again not perfect for a variety of reasons – firstly it’s I2C is only 100kHz rather than the 400kHz for the MPU6050 so could slow things down without some very careful coding;  secondly it’s tracking distance to ground where as the accelerometer is tracking from takeoff point – so in a lecture theatre, takeoff from a table would give horizontal flight from the accelerometer, but a rapid descent as the quad passes over the edge of the table, also possible causing two of the arms to clip the table; third and finally, I’m not sure how well a URF will perform on grassy rather than hard surfaces.
  3. filter the accelerometer output to smooth the acceleration (the spike at one second in the graph above) but trace the steady drift downwards; simplest would be yet another complementary filter, merging in fractions of latest accelerometer readings into the initial value in the earth axis; better though would probably be a Kalman filter where the prediction it provides may well be able to remove the spikes completely – it’s also easier as there’s just a single source of the data being filtered, unlike the current complementary filters which are used to merge angles from gyro and accelerometer.

So option 3 it is, though as always, I’ll chicken out on the Kalman unless the complementary doesn’t work well!

11 thoughts on “Accelerometer drift proof and solutions

  1. something to keep in mind: the Kalman filter has two steps – update (with measurements) and also predict / propagate. The latter step does require you to know the linear state space dynamics, which can be obtained from system identification or derived. The derived versions aren’t very accurate though, eg, with small changes to mass and tons of nonlinear math… System ID though requires an indoor motion capture system or some accurate way to measure low-airspeeds and position (sub-centimeter), also challenging topics. Have you looked at how Arducopter or other projects do their state estimation, since they don’t have one platform that they specifically support?

      • I’ve already coded and tested the CF for accelerometer sensor drift, and the results are looking very promising. Just some tau tuning to do.

        Just FYI, at the same time I’ve upped the dlpf to 2 (94Hz, 3ms lag) with no problems – I’ve also upped the motion processing frequency from 43Hz to 71Hz because the code is now fast enough to handle it.

        • good to hear it’s promising! are you implementing the CF according to the link above (olliw.eu)? it’s not too different from the CF you have on the gyro right?

          • No, I’ve not had the chance to look at olliw.eu – I’ve been using complementary filters for long enough for merging angles that it only took a couple of minutes to code the variant for gravity to cut out the spikes.

    • Thanks for the details about Kalman tuning – I’ve never quite got to grips with how it works, so this really helps fill in some of the blanks.

      I haven’t looked at how the Artducopter does state estimation – I’m trying to make this completely a self-taught project so I understand every line of what the code does and how it all fits together – I prefer to learn through experimentation / testing rather than be taught. Hence why it’s taken 2 years and a lot of crashes to go from utter ignorance to something close to fully functional!

      • I have a strong hunch that Kalman filtering cannot be done without system ID really. that’s my suspicion as to why most OS quad projects still stick with other general filters since their platforms are so spread out so system ID for each one is not a viable solution.

  2. I wouldn’t recommend option 2. Getting the ultrasonic distance sensor to give you good, accurate readings is tricky. It’s also useless a) close to the ground and b) the further you get from the surface you’re taking readings from.

    • Hi Mike, thanks, I agree – range of the ones I have is 15cm to 5m. 5m isn’t a problem – I’m only looking at being able to do demos but I’d need code to ignore the URF at < 20cm, and I'd also need code to cope with readings when the quad is at a tilt (not hard, but more faff), and that still wouldn't help with grass / tables etc.

      It's the desire to do indoor demos that rules out option 1 and the fact I don't have the barometer, and their isn't space on the Beret (HAT). A suitable breakout should be available in spring from DroTek but I can't wait that long.

      So I'm pretty much forced to use my preferred option 3 as long as it works!

      Hopefully see you at the party at the end of Feb. If (and it's a very big if) I can get Phoebe safe by say the middle of February, could I bring her along for another show and tell?

      • Probably best if you _didn’t_ try and get it ready for the Birthday Weekend. I’m not sure we’ll have access to an outside area for a flight and probably won’t know until the day. (It’s a different venue, so who know what doors will be locked!) However, for the next CamJam, if it’s flying by then, we’d love to have you back!!!

        • No problem – actually that takes some pressure off, so I can concentrate on the Cotswold Jam at the end of the month – she definitely won’t be going there – very little chance she’ll be ready in time.

Leave a Reply

Your email address will not be published. Required fields are marked *

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