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
Yes, expert flyers have the same problem in my club, I'm not an expert so enjoy that mode :)
I don't care about FAA, not being in the states. I think my point did not go trough the language barrier: the point i was making was that indeed if would be excellent to never have flyaways and that, I believe, software solutions alone cannot give such a guarantee (due to hardware limitations). I believe software can detect and react accordingly to certain hardware limitations, but I believe it cannot detect and react to all of them. Therefore I was trying to introduce the idea of "side band" monitoring, outside of the sensor's band, by using a human like video analysis. today's companion boards such as snapdragon's or similar like Odroid XU4 are perfectly able to do real-time video analysis to detect false sensor's reading.
we should care about FAA since wherever you live, this is the FAA who set small model drone registration standards, followed by aircraft control agencies world-wide.
Ok, real-time video analysis boards successfully appeared at CES 2016
but Drone Fly-Away Syndrome can be cured right now and I know the right pills.
The problem is ArduDrone is highly sophisticated robot project, developed by
best developers, featuring sophisticated algorithms, sophisticated sensors
and logistics and algorithmics embedded.
Michael Oborne developed Mission Planner, others developed drivers and more and more excellent and quality software code,
so to implement any Drone No-Fly novelty it takes time and a chance to get
contact to Michael and others and their willingness to communicate with me.
If you know how to contact Michael Oborne, pls let me know.
If you mean drone installed real-time video analysis add-on board, so real-time in case of video analysis could be too slow to counteract timely, since video is clocked 30/60 fps only.
lol, do you really believe what you're saying about FAA ? This is hilarious.
I am curious about the solution you pretend having, please post details about it.
I believe compass and gps errors were responsible for majority of the fly-away.
Most likely causes for a flyaway and/or crash:
1. Pilot error
2. User mistake
3. Dumb sticks
4. Human error
5. Panic reaction
6. GPS reception
8. Signal noise/EMI from other components
9. Faulty sensors/electronics/cables
10. Autopilot logic
either Pixhawk firmware or Pixhawk hardware represent highly-sophisticated state-of-the-art in robotics and robot control today.
Number of sensors is so great and some may start to resonate from time to time generating random data.
EKF cannot replace Navigator's board still misssing.
Logistics behind Pixhawk firmware has not been tested and verified to work properly for such a large set of sensors:
GPS, barometer, IMU1 (3ch gyro, 6ch accelerometer) IMU2, Lidar Lite, optical flow meter, gimbal IMU to name just few.
Developers of Pixhawk software should publish official warning and report on bugs reported and publish only fully tested and certified version of Pixhawk, to work at 99.99%.
Otherwise, operator of model drone, pilot of drone, may risk
compensation claims in case of third party injuries as a result
of Drone Lost-Control or Drone Fly-away Syndrome.
Death Certificate is the most intelligent document issued by public administration, completed by medical officer
18. Cause of Death
1. Disease or condition directly leading to death (a): ... pulmonary artery or
Interval between onset and death : immediate
morbid conditions, if any, giving rise to the above cause (A)
Stating the underlying cause the last.
Due to (B) rheumatic disease ...
- many years
Due to (C) fibrillation
2. Other significant conditions
Conditions contributing to the death but not
related to the disease or condition causing death
Inked, certified, dated ...
As you can see from the above, alike examination procedure can be implemented of drone crash resulting in third party injuries
Cause of the crash
directly leading to the crash (A) ......
due to (B) ...
due to (C) ....
I experienced one weird behaviour with my y6. As stress test the copter was in low alt and spun 5 times very fast corkscrew pattern i suddenly lost control of the vehicle in stabilize. Haven't had time to check the log but should be related to gyro. As per my understanding stabilize =/= manual mode, despite the believe. Will check for the log and upload it...
@ John - As a developer, i can send you a ship (would be glad to donate it to the cause) that does a fly-away on command (just flick the switch to auto control; otherwise it flies great). Guaranteed to occur with three minutes. eliminated by investigation are reasons 1 thru 6. in this case, your reason 9 is probably the cause as there wasn't correlation between the sensor IMUs.
So what we are talking about is ...
has anyone tried a mathematical 'significant z' approach to taming the accel-z input as it is used in helping control altitude? significant-z would be accel-z / it's recent variance (whether a KF or simple exponential moving average of variance). As a developer, do you know the answer to that question? it may have been tried and discarded because it doesn't work.
To me, preventing flyaway is easy, currently, geofence can box the quad in a certain area. That said, there are still holes in geofence technology, mainly, lacking a dependable collision avoidance system and reliability of sensors. I have been working on the avoidance system for about 2 years. I got the algorithm for depth map and point cloud. Unfortunately, the weight and the costs of the sensor are killers.
collision avoidance system is either easy with 3D video systems, TAWS Lite, I am working on.
My robot vaccum cleaner is an excellent example of collision avoidance system being implemented satisfactory.
Algorithm for depth maps and point cloud has been made available for free
with 3D camera scanner app for smartphones.
You can extract depth or Z- dimension manipulating point cloud in real time
and going through the point cloud's layers to spot the closest point.
I am just testing 3D full body scan technology since I developed 3D USG tomography 10+ years ago and waited so long for 3D wireless IMU based manipulators and point cloud technologies to mature.
This is now the highest time to offer 3D USG tommography to the market
as non-invasive, none-xRay technology in medicine.