With the latest code, sampling the sensors at 250Hz, and doing motion processing at 50Hz, I’m capturing every sample: in an approximately 10.6 second flight measured by time.time() wrapped around the flight code, I’m seeing 530 motion processing runs and 2650 samples to 0.1% accuracy.
And yet she drifts a couple of meters in that 10 seconds. For a while I thought that was it: an A2 couldn’t capture any more samples, and I had no choice but to break out more sensors, which would also be dependent on the A2.
But then, one of those thoughts occurred to me – yes, once again when I was dozing on the sofa to refresh my brain: the rotation rates from the gyro are a lot more critical now. They are used to approximate the current angle of tilt based upon the previous one. That then is used to rotate accelerometer readings to the earth frame, pass them through the gravity extraction filter, and then rotate the extracted gravity back to the quad frame to calculate better Euler angles.
And here’s the crux: previously I’d been using the MPU9250 digital low pass filters (dlpf) to filter out ‘noise’, but there was a price: the filtering causes a delay as well as a reduction in noise. And that delay means the prediction of the current angle would always be wrong.
The gyros are not ‘noisy’ and they are factory calibrated. So I decided to turn the gyro dlpf to it’s minimum 188Hz with 1.9ms delay; and while I was at it, I thought it worth doing something similar with a accelerometer DLPF.
And sure enough, back to zero drift for the flight.
For anyone using the code I posted to GitHub yesterday, search for
cli_alpf = 3 cli_glpf = 2
and change them to
cli_alpf = 1 cli_glpf = 1
and see what happens!