As I dozed off last night, I realised there is a critical noise period at take-off, which would then account for vertical speed inaccuracy through the rest of the test flight.
While the blades are spinning up, they start at 0 RPM, and this climbs until they are putting out enough power to take-off. Somewhere in the middle of this, the blades will spinning up towards 5RPM. Given the DLPF of the Acclerometer is set to 5Hz, this ‘noise’ from the spinning blades will be sensed by the accelerometer, and integrated as part of the vertical speed – and I suspect this leads to so very faulty readings where the motor noise is the dominant factor.
I suspect that the drone take-off happens at a much higher RPM than 5Hz, meaning that if I don’t start reading the accelerometer until say we’re at > 20Hz, then this initial blade spin-up won’t pollute the overall accelerometer readings with the < ~5Hz noise, and so will have better readings and therefore vertical speed calculations as a result.
So today, I’m doing some live test runs to see…
…and there’s some interesting points:
- the z-axis gyro readings clearly show a peak of noise as the motors spin up – kinda makes sense really – beyond that peak, I’m assuming the DLPF is doing its jobs; good stuff
- the z-axis accel reading require a lot more guess work / vision to read anything about DLPF speeds. The “interesting” point is the yellow spike – that’s where the Accel gave a max positive output (+2g) for absolutely no good reason – so there’s still something occasionally wrong with how MPU6050 / I2C API is (not) working.