OK, don’t bother believing any of what I written below; I added the code to ignore duff vertical accelerometer values, did one test flight and the result was another flipping flip onto her head + reboot. It always seems to happen as the vertical PID target is changed from 0ms-1 to 0.3ms-1, and the flip always seems to be towards the right. Also it happens only when diagnostics are not running, so the code loops at 200Hz (compare to the 133 I get with diagnostics). So for the moment, I’m somewhat flummoxed and need to get my thinking cap on again.
There is some d-gain on the horizontal velocity PID left lying around from some other problem solving. Perhaps I should get rid of it? I’ll try again tomorrow.
Another thought is that the MPU6050 is updating its registers every 3ms; combined with the fact it is always qaz (which is the last register) which gets corrupted, I wonder whether slowing down the update rate to 4ms may be the solution. I think I’ll try this first.
Phoebe has started randomly flipping over onto her head in flight. Here’s why:
The lines show gravity measured on both Phoebe’s and the Earth axes. See the 2 spikes down to near 0g rather than the expected 1g? Depending on the gain on the horizontal velocity PID, these cause terminal crashes.
If the gain on the safe side, I get a safe run, and can gather diagnostics as above.
If the gain is on the wrong side (we’re talking 0.5 vs 0.6 here), these spikes cause the corrective angle calculation to produce a huge target angle (division by 0g fed into atan). As a result, the PWM to the ESCs is huge, to the point they seem to switch to safe off mode, and this caused Phoebe to be flipped by any ESCs not shutdown . At the same time, the power surge drops the voltage from the battery, resulting in a Raspberry Pi reboot.
There is a known bug in the BCM2835 i2c code which might be the cause. For now though all I can do is to ignore spikes like this outside of an arbitrary range (0.6 – 1.4g looks safe from the chart above), and instead use the previous value.