Back to dynamic calibration

I test flighted my beer fridge calibration, and frankly the results were rubbish verging on scary.  Turns out that was nothing to do with the calibration, and everything to do with a bug in the code. Having reviewed the calibration math(s), there was a flaw:

G * sin θ = gain * (sensor1 + offset)

The correct version was something along the lines of

G = sensorx * sin θ + sensorz * cos θ

At the same time, I lost confidence I could calculate offsets at anything other than 90° (the math(s) just didn’t feel right), so I ordered a small perspex cube from e-bay to allow me to calibrate all axes at ±90°.

And with that on order, I had time to kill, so I went back to reviewing the dynamic calibration code.  And I found 2 bugs: one related to take-off timings, and the other related to correct handling of gravity when integrating accelerometers to determine speed.

Long story short, dynamic calibration is back at the top of the my priorities, the perspex cube is probably redundant, and the beer fridge is passing the “Ronseal TestTM” and that alone.

3 thoughts on “Back to dynamic calibration

  1. Don’t dispair!… Perhaps you should unit test your code ( for python, have a look at nose)… This would greatly reduce the number of bugs and potential bugs

    😉

    • UT would be great, and I do it as much as possible in the ‘test lab’, but there comes a point where only real world behaviour can show a bug. After any change I always do a passive flight indoors, and often check the diagnostics to make sure there’s nothing drastically wrong with my changes – that the nearest thing to UT, but only a real flight can reveal the change of behaviour a code change makes.

      Talking of which, I found another bug this morning which accounts for why Phoebe wasn’t keen to get off the ground with ascent mode – only by reviewing real-flight behaviour compared to diagnostics produced does it become apparent what area is wrong.

      The problem was translating earth frame velocity targets to quadframe using the rotation matrix produces the wrong results for the vertical climb, and instead the earth z axis target needs dividing by cos (tilt angle).

      I’m half way through writing a post on this, but now can’t be bothered, as I’d rather just get her out to check the changes in flight!

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.