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

Reply to This

Replies to This Discussion

I knew ESA had a newer dataset -- ESA GOCE captured a geoid in 2011 from some Googling...

Unless you somehow find a way to hack gravity, there will still be a 1G bias in the system regardless. Once you over saturate the sensor, then this bias will come in to play regardless of if the sensor says 15, 16 or 100G.

The only true fix is to make sure you have a handle on vibrations.

I understand what you're saying John, but you don't explain yourself, and it seems you are confusing a bit of physics and a bit of electronics and a bit of maths, when each are separate.  I'll try to explain it.

Physically, I guess acceleration is similar or indistinguishable from gravity by an accelerometer or gravimeter... but it is more or less a constant, aside from the variations from location to location as I mentioned, or the (perfectly constant) reduction in gravity as altitude increases.  So physically, gravity in an acceleration sense is a set value for any given spot on or above the Earth. And it's also a directional indicator for up/down -- at least physically.

In an electronics sense, the sensor will show say, 1 gforce as 10 metres/sec flying straight up or whatever.  That will move around a 3D space as the sensor changes attitude, providing "up" for calibration or at power up, when you know, or assume, the device is motionless enough that you'll get a strong terminal velocity type reading heading up.  PResumably any FC or other consumer of the accelerometer's inputs will calibrate and then proceed to calculate the differential measured in calibration to generate a balance point reading and some thresholds for movement etc.  The electronics that listen to the sensor electronics are compensating for the constant forces of gravity, with "maths". hah,the joy of being ignorant seems to serve me well. :-)

So the "Maths" above are basically just numbers -- vectors changing, variable functions or differentials or whatever fancy equations are used to correlate that with the other inputs and the programmed flight paths etc.  In this case to me it's simply a range of "I'm falling at maximum detectable speed" to "I'm climbing at maximum detectable speed".  It could be negative 16 times the value of g to positive 16 times the value of g.  But it's not.  It's asymmetrical because the starting point is 1, not 0.  Mathematically that's not required... but farther up the food chain, I think it is used, because someone somewhere in the code needs to know which way is "up".  Or maybe not; I am assuming someone wants things this way because they are in fact, this way.

So when massive vibrations incur "max" readings in the up and down direction, and presumably at a speed faster than something like 1/2 the sampling rate, the bias will then indicate that "I'm falling at 17 g acceleration and climbing at only 15 g, therefore, OMG I'm falling -- add lift!" and whizzzzzzzz goes the birdie.  If I get it.

So what if you took a reading from the sensor and then instructed it to report the 1g as 0 from now on, with relative values from that baseline reported instead?  Well, you'd not know (from this sensor) which way up is anymore!  But the fly-away bias would not occur.

So the why can't the FC just calibrate what g is at this point of power up and then let the raw signals create "up" for that need, but the rest of the uses is shifted through some register that trims the g value into the centre of the range for all other uses, including positional / stablisation. (using the "up" above too!)

Or I guess the accelerometer could provide a signal for up and output a "readings minus up" on the other pins... might be too smart for today's accelerometers?

Either way, the physical force is the only thing that can't be "hacked". :-)  the maths and the electronics using and performing the maths, can be!

Not vibrating is so much easier though!

Err, there's no gravity?  Stand back, I'm going to try Science!!!*bzzzzzzt*

@ Chris - We all do this (saying speed but meaning acceleration). so for a reader of your post, just to be clear to the reader, an accelerometer only senses and reports acceleration (not speed).

The ship, if moving at a constant speed of Mach 1, through a straight course that took it perpendicular to earth's gravitational field at sea level, would report approximately 1g in z, 0g in x, and 0g in y, the same as it would do when standing still at the same location.

Post processing math (taking the integral or time weighted sum of the accelerations) of course approximates speed. But the longer the sums are taken the less accurate they become as the error terms accumulate.

I agree the best way to solve the vibration issue is  minimizing  it. I use anti-vibration pad for the fc and balance my prop and motor. That said, I wish there are better options for barometer.

I do agree that eliminating vibration is the best way for improving the performance. That said, I also would like some one comes up with a correlation and/or algorithm that based on statistic.

Sorry Forrest, I don't usually have to be so precise in describing such things, and I'm not trying to be an expert in the technology.

If you want to be pedantic, your jet is experiencing zero acceleration in all axes.  Or if you want to be more pedantic, it is experiencing an arseload of thrust, and an equivalent arseload of resistance to make the net change in speed over time equal to zero.  It's absolutely the same as in the z axis with lift balancing gravity and all other downward pressures.

So why does a device called an "accelerometer" actually seem to behave like a "gravimeter" in one axis, and like an accelerometer in the others?  What is the purpose of adding the effects of gravity on the sensor to a signal that sensor generates which is treated (improperly I say) as an acceleration measure?

I suspect the only reason the device reports ~1g when at rest is because it's function is accuracy foremost, and sensitivity as the main input to that.  It leaves interpretation to others and concentrates on being as sensitive and accurate (and I suspect, small/list/low-power) as possible; but it makes no sense to contaminate Z with constant values such as g. BUT...

I further infer that the reason it's not sensible to create corrected output from the accelerometer is because g is NOT a constant after all, and decreases with altitude, measurably and significantly.  And of course the starting point at the surface is different across the globe.  All the more reasons it's "not the accelerometer's fault". :-)

The FC "should" in that line of thinking, correct; or provide correction; or (as today) leave it and deal with it all over the various consumers of FC services.  This means they too can benefit from those changes if they want to use them.  (for example, it should provide a guaranteed altitude without failures of GPS or air pressure involved, but only if we have the sensitivity and error margins to make ituseful) And really, just fix the freaking vibes!  hehe

But if we have the data we need (by "we" I mean our friendly devs) such as a boot time long-window average reading + the adjusted altitude from baro, and that gravity figure itself varying, and GPS data... we should be able to perform those calcs within "budget" and make this type of flyaway due to a crude usage of the sensor, a thing of the past.

Something I'm missing perhaps...  but I'm tryingto be useful and yes it's a little critical perhaps, but not in a personal way -- the sensor usage and the power of the flight controllers are changing, maybe we can do this more properly and make our favourite drones and FC's immune to another failure mode.

dreaming...

The topic has been hijacked by the discussion of acceleration. But i think we are done with the original discussion so ...

... the jet is experiencing 1g of downward acceleration in all cases even though it logically seems like it isn't. Once you understand this, you will also understand why the accelerometer correctly displays -1g (if +z is oriented away from earth's core). 

the following has way to many words, but if you follow them, you will understand what's not intuitive.

first, let's talk about x and y acceleration to get them out of the way.

Case 1: the jet is passing perpendicular to a planetary core (with the same mass and diameter as Earth) with no atmosphere. There is no drag, thus no need to accelerate the object in x or y to keep it at it's constant velocity. Thus there is no acceleration in x or y. The motors to maintain x/y velocity are turn off. The accelerometers for x&y are measuring 0.

Case 2: jet is passing through our atmosphere with the friction of the atmosphere creating drag. Drag is a force. Force is m x a, with the 'a' being acceleration. So the jet has a decelerating force acting on it. Thus to maintain velocity, the jet engines for x/y must exactly counter the force of drag. The accelerometer knows nothing of both individual forces. It doesn't know of the -.25g drag in x and +.25g thrust in x. All it sees is the net. Thus it correctly reports 0g.

This is easy to understand. There is no new knowledge here.

Now for z-acceleration.

Case 1 (which has 2 subcases): the jet is passing perpendicular to a planetary core (with the same mass and diameter as Earth) with no atmosphere. There is no drag. Given that there is only a jet motor that can propel in x (the flaps won't work in zero atmosphere), the only ways to get the jet perpendicular to the orbit are:

a) come in at an ellipse so that the jet is in a slingshot and perpendicular at only one point, the origin of the ellipical arc. Gravity acts on the jet to it draw it closer to the core (distance from the core is changing at a non-constant negative rate or negative z-aceleration), until the origin, where the rate of change is 0 (constant velocity thus 0 acceleration), followed by a non-constant positive change in distance from the core (positive z-acceleration). The gravitational force acting on the jet causes a free-fall that is later accelerated away from the core--called by space techs, a slingshot. An accelerometer correctly senses this force and can track it. Absolutely critical in space routing.

b) use the jet engines to put the object in a non-decaying concentric orbit that does not require further use of the engines to maintain that orbit. In this case, the ship is now perpendicular to gravity at all times. Let's say there is no drag at this particular orbit. so what holds the ship in the orbit?  Gravity is the centripetal (Cp) force that counters the centrifugal (Cf) force that would otherwise get the ship to take in a straight line and get the hell out of Dodge (circling around the planet). So here is the cool part that still blows my mind. Ready? One would think that since Cf counters Cp that the net force would be zero and the accelerometer would read 0 just as with the x/y accelerometers in a jet-drag situation. But the z-accelerometer will read between (but not including) 0g to -1g depending on the elevation of orbit (how far it's from the core). 

What??? The reason is that centrifugal force is not a true force (that's the part that screws with my mind). Force is derived from acceleration. Cf is derived from the inertia of motion (velocity). Cf is based on mass and velocity, not acceleration.

Thus once again, the z-accelerometer is correctly reporting net force.

The approximately -1g being reported by the z-accel is not a bias. It's reality. Whether i'm just sitting in my chair, running on a track, sitting in the seat of an aircraft on the ground, or siting in the seat of an aircraft flying at constant altitude at near the speed of sound, I stay in contact with the ground or my seat because there is about -1g trying to accelerate my body through the seat, floor, or ground.

Case 2: This is not hard to figure out as it just adds drags drag into the mix.

How would our copters fly if Gravity was taken out of the equation? In terms of the programming. Not the reality :) Is the gravity constant a big part of the equations in the stabilizer?

gravity really doesn't matter to the systems that deal with g-forces.

- we all know that it flies just fine at normal g-load (-1 g).

- you can take the ship into zero g manuver (0 g-load) and it flies through it just fine.

- you can fly the ship upside down (+g load) and it flies just fine (albeit for a short time).

if you flew it on mars or the moon inside a pressurize dome it would do just fine. all you would have to do is change the pids (and there are probably other issues too). So with reduced or no gravity, the primary forces are reduced to changing momentum in direction and angle.

Reply to Discussion

RSS

Groups

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

© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service