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
Replies
Okay, stupid question maybe but it bothers me enough to cop the whipping I may so richly deserve...
Why don't we just fix, or replace the accelerometers to report dead 0 in 1G (at least until Elon has us on Mars) and have full 'fidelity' in reporting +/-16G relative G? Possible issues are the difference in gravity from place to place, this could be calibrated at power up unless it is significant enough over a single battery to cause control issues, couldn't it? And if topo data is being added into the software already, couldn't we compile a simple G modulus into the topo / map data, courtesy of NASA (GRACE)?
Or, what about tossing the extra range and cutting the scale at +/- 15G and keeping the balance that way?
Please be gentle... *hides*
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 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 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!
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.
@ 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.
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...
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.
Thanks Forrest!
-
12
-
13
-
14
-
15
-
16
of 20 Next