This is a discussion related to the Copter development priority debate that popped on the Copter-3.3 beta testing thread. A quick categorization of the things we work on in each release include:
- bug fixes (i.e. fixes to existing features that have a defect)
- safety features (i.e. new features that improve reliability)
- other new features (i.e. non safety features like landing gear)
The basic question might be, "are we spending too much time on new features, time that should instead be spent on bug fixes or safety features?". Let the debate continue!
Replies
I believe we have everything required to guarantee that no fly away takes place from a single failure.
We have detections of GPS failure or large glitches. We provide a switch to manual control (Stabilize or Alt Hold). We also have a comprehensive ground station and Frsky telemetry that can let the pilot know the state of the autopilot.
This combined with the clear rules on flying line of site means that there are rarely any excuses for a fly away.
However, I can give you one: There is a transmitter problem or interference on the 2.4G band causing the copter to go into loss of receiver failsafe and RTL. Then you have a GPS glitch that isn't detected by the autopilot.
Unfortunately the devs don't have control over things like having optical flow installed, the copter being properly setup, or the pilot being comfortable flying manually, having emergency procedures practised, and not relying on GPS at the bottom of a canyon or in a thick forrest. We don't control the primary causes of GPS glitches and fly aways. Most people that experience these issues have not done the basic things required to minimise these risks. Coming up with additional sensors that these same people won't install and that we don't have, doesn't fix the problem.
To my mind many of these reliability problems, like most GPS glitches, are actually caused by pilot error or poor mechanical setup. The only solution to these examples I see is improved education, and making sure people have realistic expectations of the equipment they have chosen.
Thx for the feedback. Isn't there another possible case of fly-away when Pixhawk hardware would crash , hang or messes on accel/compass measurements (due to vibrations for ex)? We have also seen lots of user cases where poor quality Pixhawk powering (with noisy sources. cf the huge thread on this on this forum) generates accel/compass issues leading to crashes and fly aways.This is what I'm most afraid about (personally much more than GPS glitches). This is obviously mostly hardware reliability issues. As a side note: thank you developpers and hats off for trying to mitigate in sw consequences of these hardware issues (such as EKF, etc). But I would hope 3DR who's leading Pixhawk hardware would understand this as being a next priority and push toward much producing a much more reliable flight controller: power resilience and protections, more reliable IMUs and QA at factory, vibrations resilience, etc...Common users like me today do not accept anymore half-baked systems that become dangerous for real uses (you can kill someone even with a 1Kg drone falling on the head of someone), this is a very serious matter and a huge (if not legally , at least morally) responsability for hardware and software developers.
I do not understand when you say that GPS glitches are caused by pilot error or mechnical setup? Do you mean a bad physical installation of the GPS ?
I do fully agree that my dream/wish to get a "fly-away free reliable system" must be conceived simultaneously on all themes : software, hardware, and what goes around : the builder (Q&A), the pilot (Skills) and procedures.
Nice debate, I hope I do not shock you to push it....
Hi Hugues,
Pilot error is directly responsible for a GPS glitch if if the pilot relies on GPS at the bottom of a deep canyon, between large skyscrapers, indoors, or in the middle of a dense and high forrest. When flying in these situations it may be possible to use GPS modes but the pilot should always be ready to deal with a switch to stabilize or land if a GPS glitch is detected. The pilot should also expect loiter to move more, and the position of home to vary by a significant distance.
Many users take GPS for granted because it works just fine on their car. However they don't understand that the requirements are dramatically lower for car navigation.
You asked "Isn't there another possible case of fly-away when Pixhawk hardware would crash , hang or messes on accel/compass measurements (due to vibrations for ex)?".
The answer is that if the pixhawk crashes or hangs the copter will immediately stop stabilizing and crash. This is what we see if we get a brown out from a bad power supply. So that can't cause a fly away because the copter can't fly at all.
Vibrations have only caused flyaways vertically while in Alt Hold. We recently discovered this was caused by vibrations in excess of 7g or 68m/s causing clipping in the Z-accelerometer. This then caused a vertical climb. We have all but fixed this problem by increasing the G-limit to 16g (I think there is also some code in the EKF to handle clipping too). This is an example of poor mechanical design causing flyaways.
I understand that we can lose the compass completely if we have a good GPS signal, without having a fly away. One of the best things about the EKF is that it can detect when the compass output doesn't make sense based on other sensors like the gyros and GPS. When this happens the copter triggers a land failsafe (depending on how the pilot sets things up) and the pilot is free to take control in a manual mode. It may be possible to cause a fly away from poor compass but there are checks in place to minimise the risk. I would need to talk to Paul about this further though.
I actually said "many of these reliability problems" "are actually caused by pilot error or poor mechanical setup". For the GPS that would be poor antenna placement, poor wiring to the GPS, noisy power supplies, and poor placement of other transmitters on the copter that cause interference with the GPS. Other issues are strong vibrations from poor frame design causing poor loiter and alt hold performance, wiring come to loose, screws to come loose, motors come loose, and dry solder joints to break (probably from a poor diy solder joint). Then there is poor power train design, under rated ESC's (especially Simon K on large props), not using redundant power for the Pixhawk.
Don't worry about having an enthusiastic discussion with me.
With all due respect , please do not put words in my mouth that what I ask is impossible. I said precisely the opposite (cf my first post in this thread) and I repeat here : I am very aware some improvements are impossible in software and that certain improvements can only be made if hardware evolves/is improved (I have listed a few examples in my first post).
The feedback that would be interesting from you would be to list all of the limits you found as a developper (such as the one you describe in the GPS glitch example) in order to look for possible hardware evolutions and/or extra sensors that would be required to avoid incidents, particularly fly-aways. Taking your GPS glitch example, if we have hard limits with one GPS not allowing to avoid fly-aways systematically, maybe two or three GPS and/or additional sensors ? I'm not a specialist, you know better what would be required to improve the issue of fly-aways (I suggested visual processing, but maybe other solutions are better?) a voting between multiple GPS would allow to detect that the GPS is giving false positions ? Any other solutions ?
And what if the GPS glitch is caused by atmospheric conditions, as they often are, which means that the glitch appears exactly the same for all GPS on the aircraft? This is one of the issues I'm talking about, is that user seem to think GPS glitches are because the GPS processor screwed up. It's usually not.
And what if you are flying at 350 feet, and the ground is too far for visual methods? Then what?
The answer, is manual control. This is why we so firmly defend our position that Stabilize is Manual. People constantly ask for little tweaks here and there, to make it hold altitude better, or slow the response to changes in throttle, etc. No. Manual is Manual. Period. And then if users are competent in manual piloting, they can save most "flyaway" stituations.
You can not resolve all problems with GPS just with desire and attitude.
I know several ppl who lost their Phantoms due to fly-aways. Nobody's got perfect software.
If you need good positioning, you have to diversificate sensors. Maybe add GSM module and calculate location with triangulation assist as the mobile phone does.
In worst case, you can phone your drone to come back :D
I think fully autonomous missions should not be off the visual range or should not rely solely on GPS. Maybe FPV assisted, but not GPS only.
Yes Marco, I think you're right. If you remain within visual range (maybe FPV assisted) and can fly manually, you should be able to save most situations.
GSM might be a good idea indeed ! Thx for suggesting that. I am sure they are plenty of other possible solutions...
Don't get too comfortable, cell operator will always know where your drone is :D
Big Brother won't let this be :D :D :D
FWIW I believe RTL_ALT = 0 means RTL at the current height
-
13
-
14
-
15
-
16
-
17
of 18 Next