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
In all things flying ... i needs lots of help ... thanks!
Sorry @Forrest
but every time I am trying to write longer message, the code behind this web input form cuts it into pieces.
Drone fly-away is due to low mass of a small drone exposed to tubulences
and there is no technology to control small drone flying at higher altitude since its kinetic energy is too small vs. kinetic energy of air.
Lidar is 50-year old technology based on single pixel scans.
Good old technology to build 3D models, 3D maps, replaced today by 2D camera mapping since software technology enabled extraction of Z-axis depth from
overlayed images.
And please don't suggest baro + laser can do better job and we can turn off z-accel.
IMU unit is made of gyro, accel and sophisticated algorithms
but small drones fly like birds at higher altitude and there is nothing can be done to stop Small Drone Fly-away Syndrome.
This is my point. The gravitational constant is irrelevant -- to acceleration -- so why is it present? And if present "constantly", then why is the constant not subtracted from true acceleration calculations and responses? Especially when the original issue is precisely the inclusion of g in z-accel figures, incorrectly and without purpose, causing "full saturation" to be unbalanced, resulting in the flight controller obtaining a false reading of "accelerating downward" (at about 9.8sm/s/s), and then compensating for that fale reading and flying away!
I can see it's use in indicating "up" -- so load it into some register set for that purpose, but if the "attitude hold" (and/or "altitude hold" -- with it's sensory limitations) must manage the correction, then the sensor needs to somehow ensure it always reads a max value range of +/- 50.00000% of the overall range, so as to prevent any bias and the resulting uncontrolled climb if an undesired harmonic or partial failure occurs (bird/foliage strike).
Just another case in drone fly-away syndrome
http://www.ntsb.gov/_layouts/ntsb.aviation/brief.aspx?ev_id=2015050...
Thank you Forrest,
problem is Pixhawk software is affected by drone fly-away syndrome
and since a true nature of drone fly-away syndrome has not been discovered yet,
Pixhawk software operated drones should be grounded for safety reasons.
If you claim, Drone Fly-Away Syndrome should be attributed to a specific hardware implementation of PX4 software, sensors installed, how they perform, it would be nice to
get response of Pixhawk hardware developers directly since on-line support was claimed to be discontinued (by one of developers).
Join
Peer to Drone Crash Investigators
darius
manta103g@gmail.com
@forrest,
Thanks for the explanation, I believe I understood from
the piezo changes shape (it's squeezed) during the acceleration
...
......
- it compensates and stops the upward movement (cuts throttle)
- it reverses the acceleration that was reported
but I have trouble understand " where it started". Is where means zero g or certain g threshold. If that is the case. it only means the vehicle is not accelerating nor decelerating, but it does not mean it is back to the original attitude. isn't it?
great insight. absolutely correct. it never does come back the the same altitude because it can't.
unless you have something like a really good sonar or vision system, you will never be back at the original altitude. it can only get back to the start of motion. but do this repeatedly over 10 minutes and the errors grow so you will need to manually readjust as time passes. not a problem on short duration ships. but a feature of flight when trying to break the world duration record and in the air for over 2 hours.
altitude is a ghost. no matter how precise you make the barometer, the baro can only be absolutely accurate to about +/- 8 meters because of changing weather systems and their associated pressures: high pressure = sunny and low pressure = cloudy. GPS, while amazingly repeatable for x/y is much worse in z.
The fun part is the Return to Launch (RTL) code. First it goes to the fence height (if you have that set) but it doesn't really know how high it is for sure (+/- 8 m). Then it uses GPS to get to the launch point (this is x/y so usually pretty repeatable). Then if you have it set to do so, it descends and lands. This is the cool part because it doesn't know if there has been a reduction or increase in the pressure of the weather system. So it doesn't know where the ground is! So the landing algorithm has to 'feel' it's way to the ground ("Ouch, Oh, guess I'm there"). Again, really clever (and improved after many years of trials).
the docs for the baro sensor of the pixhawk says it has a precision (?) of 10 cm, which I recon is quite good. As flights duration with copter are quite short the variation of barometric pressure during flight are quite irrelevant, so a landing with a 10 cm incertitude isn't that bad, and not +/- 8m.
Or am I wrong?
when no ground wind (bringing air of different densities), when flying slow (keeping pressures constant on the sensor), when a short flight, absolutely correct.
To understand how bad this can get, in MP, you can change the weights for elevation control. Change the weight of the baro to 100% (accel-z to zero and GPS to 0) and then report back if you like the result.
thanks Forrest, interesting suggestion, will look into it, but looks like a good receipt for crash.....
as for ground wind I can understand the effect of it, but for RTL the last couple of meters should be always descending slowly, so constant pressure (maybe affected by propwash
Also guess if you are doing loooong duration world records flights then the atmospheric condition may have changed quite dramatically between takeoff and landing..... ;)
And thanks alot for your tutorials/contributions, always nice reading
@Forrest,
Again, thanks for the reply.
As for sonar or optical flow, they both have their disadvatage, current sonar sensor for consumer/hobby UAV is only good for few feet above ground, as for optical flow, I believe it is better for xy than z determination.
-
11
-
12
-
13
-
14
-
15
of 20 Next