Take a look at this graph – it shows the path taken during a flight test this morning. Forward movement is to the right, leftward is upwards on the graph. The flight starts at 0,0.
Phoebe takes off and hovers for quite a while, drifting small amounts around the takeoff point of 0,0 before suddenly heading backwards and slightly to the right. The 90° turn towards the end is actually some yaw, so in fact she was still heading backwards, but the yaw meant her y-axis was picking it up instead of the x-axis. All good and matching what I saw perfectly – except for the scale.
The units in the plot are meters, suggesting she only drifted back by 12cm whereas in real life, it was more like 2.5 meters – out by a factor of 20!
In comparison, have a look at the vertical equivalent plot against time:
Take-off to hover about 20cm off the ground, followed by ascent to 1m, hover and then descent. And the plot matches reality almost exactly. So the vertical scale is correct.
I’m at a loss where the factor of 20 between the horizontal and vertical axes comes from.
The MPU6050 does not allow configuration of different scales between axes, and in fact the difference in possible scales is only a factor of 8 (±2g → ±16g) so that’s not the explanation for the scale factor of 20.
My code processes all 3 accelerometer axes identically, so there’s no obvious there why horizontal is a factor of 20 out.
Now it shouldn’t really be a problem with the flight control because the horizontal and vertical PID use different gains, but I really don’t like it when I can’t explain a problem like this – it shakes my confidence in the horizontal accelerometer readings, and hence drift tracking, angle measurement and corresponding drift compensation.
P.S. This is a near repeat of a previous post because the problem hasn’t gone away, and is now the main factor likely to be causing drift.