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:

z-axis vertical acceleration

z-axis vertical acceleration

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.

2 thoughts on “Headstands

  1. Slightly confused. If I understand you correctly, the first bit of the post says to ignore the second bit of the post.
    Anyway, if a large change in speed of a rotor is causing problems, should probably be limiting how much of a change in speed is allowed, and how much difference in rotor speeds.
    Just to clarify, if you change the vertical speed of Phoebe from 0ms-1 to 0.1ms-1, for instance, does she still exhibit the flipping behavior?
    PS: My first attempt at controlling a servo from code very quickly resulted in a burnt out servo because I was telling it to go from zero to full speed in a very short interval and the control circuitry did not limit the current, so having the safe-shutdown may be saving you quite a bit of money.

    • I wrote all the second bit, and meant not to post it before doing a test flight but I did so by accident; I did the test flight and she flipped once more.

      I have got code that uses 0.5s with a sinusoidal increase to soften the change from 0.0m/s to 0.3m/s – that’s been there for a while and has been working well. I am considering upp[ing that to 1 or 2s to see if there’s an effect.

      This flipping only started happening very recently – probably relating to some code I added to not update the PWM / ESCs every code cycle, but instead do it roughly every 4 cycles. That lets me integrate out the accelerometer noise so give me much cleaner “horizontal PID output to absolute angle PID target”. Whats frustrating is it only happens when stats are turned off – turning them only slows the loop speed to ~133Hz from the normal ~200Hz and there are no flips. So it seems timing related, but I can’t see why.

      The other down side is I’ve broken 3 props in the last 2 days as she flips upside down, and another hitting the house. That’s £50 on carbon blade lawn mowing!

Leave a Reply to Hove Cancel reply

Your email address will not be published. Required fields are marked *

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