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
I love watching this thread because there is so much struggle that i have never suffered. My hours go into flying and photography and here on this thread all the 'know it all' discuss the solutions to the non existing problems that are never being implemented.
@Tony - There are probably hundreds of bugs and problems that have been fixed over the years in this project that you've never encountered. Just because you don't encounter them doesn't mean they don't exist and shouldn't be fixed. Saying otherwise is incredibly ignorant. I'll agree this thread doesn't seem to be heading anywhere quickly, though.
@Forrest - You seem to be completely ignoring the ekf/ekf2 work that tridge and paul riseborough have been doing to address issues like this, specifically - I posted a link earlier. 3.4 has ekf2 which runs dual ekf threads and is more resilient to high z-accel. Is there a particular reason for that?
Hi Fnoop, You seem to know a couple things about this code/system. I'm not sure it's possible without certain folks re-hijacking the question again, but can you tell me what the trade-offs or downstream needs were that led to this situation where "0 m/s/s in any axis" still reads "-9.x m/s/s in Z" from the sensor? I've got no e-peen or position to defend here, I just want to understand something that doesn't make sense on the surface. It could be a bug, architectural limitation of the past left in, etc. that's fine -- I'm not complaining or witch hunting. I just kept getting non-answers and then people arguing about non answers.
So, why does an accelerometer read like a gravimeter but still call itself an accelerometer?
Why do we source this part, or are they all this way? (if there's a quick answer)
But mostly, why do we persist that accelerometer-polluted-by-gravity reading as-is, throughout the system instead of removing or reducing the error? (e.g., offsetting to add the inverse of whatever boot time was reading over a 1s window)
Thanks, and sorry for any frustration. I can sit down & shut up, too.. but have been bugged by not understanding this.
Chris
@Chris Hawley,
I can provide you with math-physical solution to the fly-away syndrome.
It's easy to understand, accelerometer, barometer, gyroscope and other sensors were designed and built not to study airborne vibrations of the airframe itself but to study and control the drone to fly safely.
Pixhawk, server-side sensor handlers are made of tens, hundreds of code loops, so we have tens of software clocks, timing clocks and sensor clocks.
If accelerometer is clocked 1KHz and airframe starts to resonate at 1KHz so depending on the phase shift between clocks, the value you can get is max negative value, 0 value or max positive value (within range).
Since phase shift between clocks is not controlled so you get random values from sensors like accelerometer, barometer, gyroscope.
Wind tunnel Lite for small personal drones is exactly the right approach to start with to study Drone Fly-away Syndrome at OpenFabLab or via Peer to Drone Crash Investigators.
Commercial drone model types can be designed and built to no show Drone Fly-away Syndrome since sensor hardware can be preselected and sensor clocks fine tuned via FFT analysis, not to match airframe resonant frequencies.
Personally assembled drone can be affected by Drone Fly-away Syndrome in every case since you don't get prior test knowledge to make improvements.
Testing personal drone on vibrating table indoor, phase shifting airframe resonant frequencies to match ones of sensors and software loops (sensor handlers) is what I can offer you at OpenFabLab.
email me if you are interested to study and test your drone.
OpenFabLab
manta103g@gmail.com
If the frame reaches "resonant frequency" it will BREAK !!! What does resonant frequency of mechanical vibration have to do with the phase of a accel signal in relation to the mechanical of the frame ??? How are you linking the two ? If the frame is in a resonant frequency how can it also be in phase with the accel sensors ? It has to be a controlled closed loop added vibration.. which drone is doing that ? maybe the Darius drones...
@Tony K,
you are not correct,
resonant frequencies are present with Diesel cars if motor idles
and chassis vibrates at resonant frequency, motor vibrates at resonant frequency and nothing breaks.
Musical instruments like violin, gran piano, guitar are made of resonant chamber, that doesn't break if you play them.
You can test Helmholz resonance frequency making beer bottle whistle.
So drone airframe generally don't break at resonance frequency since energy consumed and transferred into vibrations is limited and self-damping mechanism works making vibration frequency to fluctuate.
But at resonant frequency amplitude of vibrations is increased greatly
to invoke Fly-away Syndrome, making phase shifted sensors to output
data to handlers at fixed clock frequency FFT correlated to resonant frequency of the drone's airframe.
For sine wave open Wikipedia
https://en.m.wikipedia.org/wiki/Sine_wave
For phase shift open Wikipedia
https://en.m.wikipedia.org/wiki/Phase_(waves)
For resonance, resonant frequency open Wikipedia
https://en.m.wikipedia.org/wiki/Resonance
For Helmholz Resonator open Wikipedia (for Himalayan vase)
https://en.m.wikipedia.org/wiki/Helmholtz_resonance
For Fast Fourier Transform FFT open Wikipedia
https://en.m.wikipedia.org/wiki/Fast_Fourier_transform
"
How are you linking the two ? If the frame is in a resonant frequency how can it also be in phase with the accel sensors ?
"
I said:
Since phase shift between clocks is not controlled so you get random values from sensors like accelerometer, barometer, gyroscope.
Reading data from sensor clocked at 100Hz, modulated by sine wave vibrations (at resonant frequency) can result in any value from a range
(-amplitude , + amplitude) if sensor's data handler is clocked at 100Hz
and sensor's clock and handler's clock are phase shifted.
(open Sine wave link above)
Vibrations outside of resonant frequency range (values) get damped by airframe construction, installed weights ( motors, battery) and airframe layout, mounting scheme, since amplitude of vibrations is low.
Only at resonant frequencies amplitude of vibrations can result in
Fly-away Syndrome, if supported by matching between resonant frequency and frequency of sensor's data handler.
Sensor can be clocked at higher frequency (vide GPS)
but what matters is frequency at which sensor's data are read by handler.
Ok, I don't claim the above to work as 100% explanation to Drone Fly away Syndrome but the above has been studied and verified at Vibrating Tablet for resonant frequencies of a drone, drone's airframe at OpenFabLab.
Hey Darius,
What drones do you fly? Those of us who follow your posts are assuming that you fly an MR, because you focus on Drone FlyAway Syndrome so much. FlyAways are less common in ArduPlane. Do you fly a quad, a hex or an X8?
Some photos of one of your recent builds pointing out the modifications that you've implemented to reduce FlyAways would be appreciated!
JoeBob
@Fnoop,
I believe the current algorithm can't handle runaway gyro due to vibrations. That said, I believe the vibration issues can be miniumized by installing anti-vibration pad and proper tuning the frame/motor/prop.Currently, I feel avoidance system has much higher priority
I agree. This discussion has taken it's course. We have a solution if it is needed. Thanks to all.
Just a note on vibration pads for the FCU. There has been a long (and sometimes heated) discussion about this method of minimizing vibrations using pads or gel. However, there is a large body of evidence that gets better results with a stiff frame and hard mounting the FCU to that frame. The evidence is in the form of actual before and after analysis of vibration of the FCU in flight. Of the 8 cases tried, all 8 saw improvement with hard mounting. But that doesn't mean that hard mounting is better in all cases. It probably isn't. But, the advantage, of hard mounting, when it does improve vibration, is indisputable. The tighter the link between the FCU and the frame, the quicker and more accurately the FCU knows the attitude of the ship. Improper isolation between the ship and FCU can decrease safety. So please, test before and after any changes to how the FCU is mounted.
Thanks again everyone for your input. The NASA article appears to be an excellent place to start.
@fnoop dog.
Yes i totally agree. I know there are issues. 1.2 million lines of code...ofcourse. But in this thread we are not working on issues as specific issues but a general fix proposal which I do not agree with. This has been my point from the beginning.
-
1
-
2
-
3
-
4
-
5
of 20 Next