# Accelerometer axes scaling

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.

Horizontal flight plot

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:

Vertical Flight Plot

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.

Any ideas?

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.

## 4 thoughts on “Accelerometer axes scaling”

1. New thought:
You mentioned that the distances were off by about a factor of 20 in the horizontal but was that factor constant for the full flight?
Was the actual flight path an exact replica of your graph except for the scale?
If it was then I’m not so sure that there is a fundamental noise problem. It could be as simple as a calculation error in converting your horizontal values.

• The flight path did match exactly except for scale – I guessed (actually hoped) it was a code bug, but if it is, I haven’t found it yet 🙁

2. Could the problems have anything to do with the dynamic range of the MPU6050? In the vertical axis you’re subjected to a constant 1g which means that the sensor is operating in a different region than in the horizontal axis where there is 0g. Reorienting the sensor board and adjusting the code accordingly so that the old X axis becomes the new Z axis might show the same behavior; proving that the issue is not a difference between the physical axes on the sensor. Not suggesting that you try that now but it could help eliminate some possibilities :).

Does better isolation of the sensor board improve that behavior?

• Good thought – there’s some 30s tests I can do the check the sensors do all read 1g when reorienting Phoebe to stand on her side. From the MPU6050 specs, the z-axis sensor does have different offsets and temperature range errors.

I will have a look at better board isolation – I’m pretty sure the noise is via the frame rather than the air. I already have foam double-sided sticky take attaching the RPi to the frame, and rubber pillars attaching the board to the RPi.

This site uses Akismet to reduce spam. Learn how your comment data is processed.