The accelerometers are renowned for the noisy output they generate caused by factors such as spinning motors, to the extent that meaningful information gets swamped by this noise.
There are three sets of filters present in the quadcopter to suppress the noise while letting the good stuff through:
- the physical filters are rubber buffers / feet between the Raspberry Pi and the frame, and between the Breadboard and the Raspberry Pi – these are low-pass filters, allowing though data about movement of the quadcopter while filtering out noise generated by the quad’s motors.
- the digital filter is also low-pass provided by the MPU6050 – this can be set to frequencies of 5Hz up to 200Hz
- the complementary filter uses an averaging system, feeding in only a percentage of the accelerometer data per processing cycle, such that over several cycles noise gets averaged out – again a low pass filter.
These filters need to work together to allow as much meaningful information through while filtering as much noise out.
I’m satisfied the physical filters are fine – genuine movement in the quad will make it through – if the quad tilts, so does the sensor.
The DLPF from the MPU6050 is currently set to 5Hz to filter out as much noise as possible – this was based upon the use of the accelerometer primarily as the vertical acceleration measure where only very low frequency value changes were expected.
The Complementary filter is currently set with τ (tau) set to 0.05s. Since the code is reading the sensors roughly every 0.006ms, there’s a rolling average of ~10 cycles of accelerometer data feeding the angle measurement. The frequency of this filter is therefore roughtly 20Hz – the point at which the gyro and accelerator sensors each provide 50% of the information.
But the data the complementary filter is averaging has already been filtered at 5Hz by the MPU6050, meaning that the complementary filter isn’t really being told the whole truth by the sensor, meaning it’s output has been softened too much.
I have a nasty feeling that this is the cause of my drift. The recent change to prime the complementary filter’s initial settings was “a good thing”TM but the complementary filter did still level out the hover in under a second without that addition despite the non-horizontal takeoff. But what it couldn’t do is react to critical detailed data that had already been filtered out by the MPU6050, resulting in false angle calculations which would take much longer to fix since only a fraction of that information was making it past the MPU6050 DLPF – hence the drift.
So it seems to me that the best approach is to set the MPU6050 DLFP frequency to be double 1/τ. My only concern with that is the effect it has on the stability of the vertical take-off speed stability, but I suspect I’ll get away with that since the vertical velocity is an integral of the z-axis accelerometer.
So that’s my next area for testing.
P.S. Credit to Federico who tried to direct me to use a higher DLPF, the purpose of which I couldn’t see until just now.