Mathematical Solution for Preventing a Fly-Away

Is there a mathematical solution for preventing fly-aways?

My understanding is that the following is what causes them:

- Accel z goes negative due to ship vibration versus an actual drop in altitude
- The ship corrects by adding power
- The added power causes a larger vibration-induced negative z
- The ship corrects the pseudo altitude drop by adding more power
- A fly away occurs

My understanding of mathematical solutions are:

- A filtered or weighted z only diminishes (does not solve) the effect.

Has anyone tried a "significant z", z / s, where s is the moving average of the variation of z?
- when the IMU isn't vibrating, s is low so the magnitude of z / s is high
   ... z is significant
   ... z can be trusted for use in altitude control
- when the IMU is vibrating,   s is high so the magnitude of z / s is low
   ... z / s has less effect
   ... and will not caused a flyaway

You need to be a member of diydrones to add comments!

Join diydrones

Email me when people reply –


                • MR60

                  In all things flying ... i needs lots of help ... thanks!

      • Sorry @Forrest

        but every time I am trying to write longer message, the code behind this web input form cuts it into pieces.

        Drone fly-away is due to low mass of a small drone exposed to tubulences

        and there is no technology to control small drone flying at higher altitude since its kinetic energy is too small vs. kinetic energy of air.

        Lidar is 50-year old technology based on single pixel scans.

        Good old technology to build 3D models, 3D maps, replaced today by 2D camera mapping since software technology enabled extraction of Z-axis depth from

        overlayed images.

        And please don't suggest baro + laser can do better job and we can turn off z-accel.

        IMU unit is made of gyro, accel and sophisticated algorithms

        but small drones fly like birds at higher altitude and there is nothing can be done to stop Small Drone Fly-away Syndrome.

    • So hopefully, you now know why:

      - the accelerometer is so good at sensing changes in elevation (change in movement begets acceleration just as gravity begets acceleration)

      - why the gravitational constant is irrelevant (the ship only cares about acceleration, the change in movement)

      This is my point.  The gravitational constant is irrelevant -- to acceleration -- so why is it present?  And if present "constantly", then why is the constant not subtracted from true acceleration calculations and responses?  Especially when the original issue is precisely the inclusion of g in z-accel figures, incorrectly and without purpose, causing "full saturation" to be unbalanced, resulting in the flight controller obtaining a false reading of "accelerating downward" (at about 9.8sm/s/s), and then compensating for that fale reading and flying away!

      I can see it's use in indicating "up" -- so load it into some register set for that purpose, but if the "attitude hold" (and/or "altitude hold" -- with it's sensory limitations) must manage the correction, then the sensor needs to somehow ensure it always reads a max value range of +/- 50.00000% of the overall range, so as to prevent any bias and the resulting uncontrolled climb if an undesired harmonic or partial failure occurs (bird/foliage strike).

  • Just another case in  drone fly-away syndrome

    Thank you Forrest,

    problem is Pixhawk software is affected by drone fly-away syndrome

    and since a true nature of drone fly-away syndrome has not been discovered yet,

    Pixhawk software operated drones should be grounded for safety reasons.

    If you claim, Drone Fly-Away Syndrome should be attributed to a specific hardware implementation of PX4 software, sensors installed, how they perform, it would be nice to

    get response of Pixhawk hardware developers directly since on-line support was claimed to be discontinued (by one of developers).


    Peer to Drone Crash Investigators 


  • @forrest,

    Thanks for the explanation, I believe I understood from

     the piezo changes shape (it's squeezed) during the acceleration



    - it compensates and stops the upward movement (cuts throttle)

    - it reverses the acceleration that was reported

    but I have trouble understand " where it started".  Is where means zero g or certain g threshold. If that is the case. it only means the vehicle is not accelerating nor decelerating, but it does not mean it is back to the original attitude. isn't it?

    • MR60

      great insight. absolutely correct. it never does come back the the same altitude because it can't.

      unless you have something like a really good sonar or vision system, you will never be back at the original altitude. it can only get back to the start of motion. but do this repeatedly over 10 minutes and the errors grow so you will need to manually readjust as time passes. not a problem on short duration ships. but a feature of flight when trying to break the world duration record and in the air for over 2 hours.

      altitude is a ghost. no matter how precise you make the barometer, the baro can only be absolutely accurate to about +/- 8 meters because of changing weather systems and their associated pressures:  high pressure = sunny and low pressure = cloudy. GPS, while amazingly repeatable for x/y is much worse in z.

      The fun part is the Return to Launch (RTL) code. First it goes to the fence height (if you have that set) but it doesn't really know how high it is for sure (+/- 8 m). Then it uses GPS to get to the launch point (this is x/y so usually pretty repeatable). Then if you have it set to do so, it descends and lands. This is the cool part because it doesn't know if there has been a reduction or increase in the pressure of the weather system. So it doesn't know where the ground is! So the landing algorithm has to 'feel' it's way to the ground ("Ouch, Oh, guess I'm there"). Again, really clever (and improved after many years of trials).

      • the docs for the baro sensor of the pixhawk says it has a precision (?) of 10 cm, which I recon is quite good. As flights duration with copter are quite short the variation of barometric pressure during flight are quite irrelevant, so a landing with a 10 cm incertitude isn't that bad, and not +/- 8m.

        Or am I wrong?

        • MR60

          when no ground wind (bringing air of different densities), when flying slow (keeping pressures constant on the sensor), when a short flight, absolutely correct.

          To understand how bad this can get, in MP, you can change the weights for elevation control. Change the weight of the baro to 100% (accel-z to zero and GPS to 0) and then report back if you like the result.

          • thanks Forrest, interesting suggestion, will look into it, but looks like a good receipt for crash.....

            as for ground wind I can understand the effect of it, but for RTL the last couple of meters should be always descending slowly, so constant pressure (maybe affected by propwash

            Also guess if you are doing loooong duration world records flights then the atmospheric condition may have changed quite dramatically between takeoff and landing..... ;)

            And thanks alot for your tutorials/contributions, always nice reading

      • @Forrest,

        Again, thanks for the reply.

        As for sonar or optical flow, they both have their disadvatage, current sonar sensor for consumer/hobby UAV is only good for few feet above ground, as for optical flow, I believe it is better for xy than z determination.

This reply was deleted.


DIY Robocars via Twitter
RT @a1k0n: @DanielChiaJH @diyrobocars @circuitlaunch Here's my car's view of that race. About 8.4 second lap times for laps 2 and 3... both…
DIY Robocars via Twitter
RT @DanielChiaJH: Great racing against @a1k0n today at @diyrobocars! Pretty cool to both break sun-9s at the track today I think I got very…
DIY Robocars via Twitter
Broadcasting the @circuitlaunch race live now at Races begin around 2:00pm PT
DIY Robocars via Twitter
RT @a1k0n: ran a huge number of hyperparameter tuning experiments yesterday; now I can train a new policy, far with better quality, in 15 m…
DIY Robocars via Twitter
RT @a1k0n: Did I get rid of hand-tuned parameters? Yes. Am I still hand-tuning more parameters? Also yes. I have a few knobs to address the…
Sep 26
DIY Robocars via Twitter
RT @a1k0n: I'm not going to spoil it, but (after charging the battery) this works way better than it has any right to. The car is now faste…
Sep 26
DIY Robocars via Twitter
RT @a1k0n: Decided to just see what happens if I run the sim-trained neural net on the car, with some safety rails around max throttle slew…
Sep 26
DIY Robocars via Twitter
Sep 24
DIY Robocars via Twitter
RT @SmallpixelCar: @a1k0n @diyrobocars I learned from this. This is my speed profile. Looks like I am too conservative on the right side of…
Sep 24
DIY Robocars via Twitter
RT @a1k0n: @SmallpixelCar @diyrobocars Dot color is speed; brighter is faster. Yeah, it has less room to explore in the tighter part, and t…
Sep 24
DIY Robocars via Twitter
RT @a1k0n: I'm gonna try to do proper offline reinforcement learning for @diyrobocars and throw away all my manual parameter tuning for the…
Sep 23
DIY Robocars via Twitter
RT @circuitlaunch: DIY Robocars & Brazilian BBQ - Sat 10/1. Our track combines hairpin curves with an intersection for max danger. Take tha…
Sep 22
DIY Robocars via Twitter
RT @SmallpixelCar: Had an great test today on @RAMS_RC_Club track. However the car starts to drift at 40mph. Some experts recommended to ch…
Sep 11
DIY Robocars via Twitter
RT @gclue_akira: 世界最速 チームtamiyaのaiカー
Sep 10
DIY Robocars via Twitter
RT @DanielChiaJH: Always a good time working on my @diyrobocars car at @circuitlaunch. Still got some work to do if I’m to beat @a1k0n howe…
Sep 10
DIY Robocars via Twitter
RT @SmallpixelCar: My new speed profile for @RAMS_RC_Club track
Sep 10