I am sure many of us have heard about "fly away" horror stories coming from people who own(ed) a DJI phantom... today I found this video which explains the companies solution to one of the supposed causes of the problem... starting at 5:07:
The premise is that 'flyaways' are caused by a stronger interference signal that overrides the transmitter, jerking the craft in one direction and away from the pilot.
What the code does is detect whether that signal is unchanged for 10 seconds - if it is unchanged the code flags it as possible interference and puts the craft into a hover.
This is because actual pilots don't hold the sticks in one exact position for long periods of time, that is unnatural.
I wonder if it is worth implementing something similar in the Ardupilot code...
Comments
R_Lefebvre 34 minutes ago
The real cause of accidents - a huge number of casual users.
Standart procedures -CALIBRATION. RTFM lol
Now some heretics
DJI Phantom become as most populare mass production low cost UAV in word
It makes NEW and GROWING market.
https://www.youtube.com/results?search_query=%22DJI+PHANTOM%22&...
448,000 results
UAV will be consumer product for all peoples. =)
Don't resist. Everything is fine
Just USE IT.
A $10 Chinese radio can't fail surely
How awesome would it be if DJI actually enabled data logging so users could figure out the true cause of flyaways, instead of just guessing.
If DJI flyaways are caused by radio spoofing, then their radio really sucks.
I agree, this is by no means a going to solve anything - this is not even an official release from the company. Most likely an effort to keep their customers, who don't know any better, placated.
Sounds like an arbitrary solution to me which yet has to show if it doesn't cause more pain than it resolves. 10 seconds is such a long time that it probably won't resolve any damage or hurt. 3 seconds is too long even.
It reminded me of my proposal on diydrones forums on failure detection in autonomous aircraft using probabilistic validation methods:
http://diydrones.com/forum/topics/proposal-for-a-systematic-method-...
YIKES!
Any decent radio system has hopping channels and I'm pretty sure some sort of ID is exchanged between the TX and RX (binding), I'm not a radio expert but would expect that at best the interference could cause a cut in the TX-RX link which would trigger a Failsafe, sound unlikely that the interference can send actual signal that the RX can interpret as valid input, unless the radio system on the phantom is really bad.
When we have fly-aways with ArduCopter it's normally because of GPS glitches or incorrect yaw heading. I don't remember seeing a situation where it was caused by the radio inputs freezing...so although we could implement the same check I don't think it would really help that much.
-
1
-
2
of 2 Next