# 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

Views: 6543

### Replies to This Discussion

Thanks Forrest!

Okay, I'm sorry for "hijacking" the thread -- but solving this is apparently the root cause of the problem noted in the first post.

Not being able to even discuss the issue ... this seems to be a real problem if smart folks don't know the difference between acceleration and gravity -- even to the point where they go on to describe why "free fall" is not "zero gravity".  I'm actually scared that I am missing something, and so is Forrest, as he continually talks about gravity, while I cannot accept remedial astrophysics as an answer to my concern with what appears to be misuse of an instrument (accelerometer) by the flight controller and/or he software stack running upon it -- though I get the feeling I'm missing something. :-)

So I am sensing there is something connecting gravity to acceleration in our software stack; but I am unable to get a sensible answer on why the electronic component includes g in acceleration when it (g) is apparently completely unused in maintaining attitude, altitude, airspeed, or direction, other than indicating which way is currently up -- if this is the sensor providing that input. The last response shouts in bold type that the accelerometer is correctly reporting 'net force'.  But acceleration is also not force but only one of two components of force... what am I missing?

Can someone who knows why we see gravity as "downward acceleration" -- and therefore, why a saturated Z axis results in the FC compensating for that false reading and vertically flying away, please indicate the design decision taken to work this way?  There must be a worse case that is avoided.  At least we cold then understand... or maybe come up with an idea to fix that.

It's an honest question, and with all politeness, please can we answer the question directly rather than using incorrect analogy to jet planes or completely unrelated gravity stories about satellites and so-called non-decaying orbits! :-)

Chris

ah ...

first understand that a -1g in the accelerometer is not saturated. it's just a number defining it's state at a particular moment that can roam between all g states that the ship will encounter in flight (say -4g to +4G):

second, understand that in determining altitude, the FU:

- is really determining relative elevation so it can hold steady up and down

- cannot do this with GPS because it's not accurate or fine enough

- cannot do this with the barometer because i'ts not accurate, fine enough, and affected by natural air variation which gets further disturbed by prop wash

- so it primarily uses Accel-z

In alt-hold, loiter, return to launch, position hold, etc., the ship doesn't need to know it's elevation or altitude, only whether or not it is going up or down (yes ... even in RTL amazingly enough). It turns out that the accel-z sensor is highly sensitive. Move the ship up an inch (to do so it needs to accelerate up ever so slightly thus increasing the g-force) and the sensor knows allowing the FU to correct.

So when you see your ship just hovering in space and not moving up or down, surprisingly, it's not the baro that is doing most of the work.  It's accel-z.

@Forrest,

when you said"when you see your ship just hovering in space and not moving up or down, surprisingly, it's not the baro that is doing most of the work.  It's accel-z.", it confused me because the APM alt-hold is not using the GPS, if the baro is not the main source, please edicate me how to use the accel-z to pin out the altitude. Thanks

Barometer - that caught me by surprise too. always thought that the baro was so sensetive that it could report a 1" movement up or down and that was why alt-hold was so incredibly beyond belief in keeping my ship just hanging there in space. but that's not the case as was explained to me. baro only provides a fairly accurate indicator of pressure, which post processing math can change into changes in pressure. but changes in pressure has too many causes with only cause being moving the ship up or down.

Gravity - a cool side note is that there isn't a sensor built yet (to my knowledge) that directly detects gravity. primarily because it isn't something that we even as yet understand. we don't even know if it is something that originates in our 3 dimensional space or something that leaks in from 9 dimensional space. all we can do is sense the affect of gravity--it's ability to accelerate mass.

z-Accelerometer - so it doesn't sense gravity, it only senses net acceleration from forces on a piezo crystals (usually made of silicone and oxygen atoms) that displaces an electrical charge when the lattice is stretched or squeezed. Hold it just right (perpendicular to the Earth's core) and it displaces a charge that can be used to calibrate it to the gravitational force at that location. Move it from 0 to 9.8 m/s/s in deep space and it will produce the same displaced charge.

z-Accelerometer use in alt-hold - a wind moves the ship upward that was previously sitting still. Before the wind, the z-velocity was 0, 0, 0 (so acceleration was 0). The wind hits and the z directional movement speeds up to .001, .002, and 003 m/s/s (so acceleration, the change in velocity, is .001).

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

- electrons are displaced in the piezo crystal

- the brain of the accel chip sees this voltage change

- it converts via calibration data to a calibrated voltage

- it sends out this voltage to the ship FCU

- the ship FCU now knows that the ship is going up

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

- it reverses the acceleration that was reported

- until the ship is back where it started

When i was told this, i thought, how clever and unexpected! Of course it is more complex than this because the ship is actually using 3 sensors to 'see' changes in z:

- GPS

- Barometer

- Accelerometer

- Sonar or vision (if equipped)

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)

P.S. we could talk only in terms of m/s/s. Ya man, i was hauling ass at 29.4 meters per second squared. But it's easier to say, god my head hurt when i smashed into that tree at 3 g. So the term gravity is only a convenience of speech that give us a reference.  For example, one of my jobs at Boeing was to keep the floors in tact enough so that folks can exit after a "9g deceleration". OK ... a "crash". Or "slowing down at a rate of 88 m/s/s". Take you pick.

Thank's Forrest, very clear explanation and very interesting to know how our machines work.

@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?

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).

Just another case in  drone fly-away syndrome

http://www.ntsb.gov/_layouts/ntsb.aviation/brief.aspx?ev_id=2015050...

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).

Join

Peer to Drone Crash Investigators

darius

manta103g@gmail.com

@Forrest,

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.

Jumping in again at this point - we went through this discussion about 4 years ago with some "experts" in the field of altitude control and this is the main reason why we've been developing laser altimeters as part of the drone ecosystem. It is the only available technology that can be used to "correct" for the pressure and acceleration induced errors in absolute position because it is referenced to a fixed object (the floor) rather than atmospheric pressure or differential acceleration. We think that a "better" solution is to hybridize (EKF) the sensory inputs to merge the best available data so that if the laser is out of range then barometric altitude can be used for a limited period to fill in the gaps. Of course this works better when the laser altimeter has longer range, hence the release of our new SF11/C. I hope this makes more sense now that Forrest has clarified things for everyone - nice work dude :).

Gravity - a cool side note is that there isn't a sensor built yet (to my knowledge) that directly detects gravity. primarily because it isn't something that we even as yet understand. we don't even know if it is something that originates in our 3 dimensional space or something that leaks in from 9 dimensional space. all we can do is sense the affect of gravity--it's ability to accelerate mass.

I think we will never see a gravity sensor. Gravity is an unproven theory and many theoretical physicists are questioning it. Heavy things just fall down through lighter mediums and stop when encountering something of equal or higher density than the object falling. The copters thrust is just countering that weight by thrusting against the air fluid. I haven't looked at the code but how would it effect the stabilization if it was not considered at all?

1

2

3

4

5

6

7

## Groups

45 members

1472 members

282 members

470 members

• ### 3D Models

57 members

Season Two of the Trust Time Trial (T3) Contest
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here