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
@Forrest - I think you are absolutely correct but you can take the concept even further into 3 dimensions and, if I understand what is being done presently, you end up with an EKF. However, from my own experiments, I find that extremely non-linear events, such as impossible accelerations or large instantaneous positional errors, aren't handled particularly well by the EKF in the sense that the data is still given some credibility instead of being excluded from the decision making processes.
In my simple understanding of the root cause of fly-aways, whether from barometric errors or GPS errors, it boils down to an impossible set of circumstances - instantaneous translocation - that is not correctly identified and handled by the software.
washing machine@Forest, ok, I can write mathematical model but we should try to understand true nature of frame vibrations at higher altitude vs. low vibrations at lower altitude. Let do some vibration tests on vibration table first. Used
i'm not sure if the EKF would work in this case (but then again i might not understand the EKF well enough). However, what i do know about the EKF process is quite sound as it continually evaluates itself. so rather than a process that linearizes the non-linear function around the current estimate (which i think is what the EKF does), simply calculate the standard deviation of accel-z using a KF or EKF approach. Then divide accel-z by that to derive a 'significant z' value. this is tough stuff as reality can be difficult. so i don't know if a 'significant z' would work.
If someone wants to try to come up with something, the community can donate fly-away data files. I have a few.
I have to set up my PC and I am ready to preview fly-away data files.
Today I operate 10 inch Android Tablet based Las Vegas PC computer
(PC keyboard, PC mouse, external disk connected, 3G internal modem).
No noise from fans, no vibrations, no heat waves, power consumption reduced 20 times.
My previous suggestion was to try to reproduce high-altitude fly-away at the ground level, at your desk.
My washing machine at high spin speed can be a good starting point to build a vibrating table.
This file contains an actual fly away, occurring where the vibes get huge.
Essential discussion! If we could guarantee a "no fly away" drone, legislation and regulations and administration's trust might evolve to less restrictive requirements.
Such as discussion has been done a few months ago here on diydrones but I cannot find the thread anymore. Basically the conclusion from the developers (please correct me) was that software alone cannot care for hardware limitations, such as the baro drift issue, GPS errors, IMU failures, compass failures,etc.
So it seems that to eliminate all possibilities of fly aways, the job has to start at hardware level and of course be pursued at software level too.
I personally think that the best way,with current affordable means, to detect false translocation or false altitude drops would be to use computer vision processing as a complement to validate accel,baro,compass sensors.
Sorry the silly question. when you say "fly away" you refer that copter don't respond to any command and go where he wants? stabilize included? or only when the copter made a mistake in auto missions and you can recover flying manually?
This is the question. There is a big difference between a logical error flyaway, which cannot be recovered by switching to manual control. Ardupilot never suffers this. Then there is a navigational sensor error flyaway, which can be recovered by switching to manual control. This is very rare on well set up copters.
You missed the root cause of Z-accel vibration induced altitude "flyaways".
That being: the accelerometers operate with a range of +/-16G. The gravity vector is -1G. When vibrations reach levels that saturate the accelerometer, which begins at +/-15G which results in clipping only on the negative side, and fully saturates the sensor at +/-17G, the filtered/averaged sensor reading changes from -1G to 0G, leading the copter to think it is accelerating downward, so it responds by trying to accelerate upwards.
There is no solution to this problem, other than just ignoring the sensor altogether. This is not great, as without this sensor, altitude control becomes very poor, since the only way to determine vertical acceleration, is by getting the derivative of the barometric sensor, which is itself a very noisy sensor.
I haven't heard of an altitude flyaway in about a year. Are you still suffering them?
The solution, as you have been told many, many many many times, is physical vibration isolation, which reduces the chance of having Z-accel saturation.
That the answer, If you always can recovery manually, that I always can do after now, I take some (excess) precautions, I always use fpv with osd to visually watch were I'm flying, with two receivers, one with omni and one with long range patch antenna, I record the fly so have gps coordinates saved including long distances, I use a dragon LRS to don't lost rc signal in long distances, and have simple mode in a switch so if I know copter direction, I can aproximate without knowing its orientation and use telemetry too with Tower but that have a short range for the moment, a pending task. If can't recovery manually, nothing of this works except long range video saved, look coord and go for it.
It's sounds exagerate but I listened some lost histories (not APM) when I begun and if I lost my baby I can cry a month ;)
It's a pitty that fpv advantages are ignored for law administrators and is nearly banned for new rules here.
It happens so quick that in the time it takes to switch to manual the ship has accelerated so fast that you can no longer see its attitude, so then you are guessing/testing with the stick to see what works.
I had one ship with the new Pixhawk that would do a flyaway every time it flew and i switched to any form of altitude hold. Vibes were well under .3 (not good but should be tolerable. The issue may have also been that there wasn't correlation between the IMUs on acceleration in x, y, or z. Of the two Pixhawk that had this issue, i now have a new one that i'll test and i'm hoping that the correlation issue is long behind us.
thanks for helping with that, by the way, and steering me in the right direction. i've been too busy and distracted designing 250 racers and testing KDE & Tiger equipment. Hope to get back into the main fray soon.