Providing the user / pilot a good feedback is very important.. Right now most autopilots just have 1-3 LEDs, but no interaction concept. We would like to collect some feedback on this topic. It takes less than 60 seconds to complete and will help us a lot: Link to survey
Based on this feedback and general UI concepts we're trying to come up with a consistent interaction concept using the different LEDs, switches and buzzers to make the operation of the PX4 hardware as user friendly and safe as possible.
Comments
Hi Lorenz, Actually have PX4 flying very happily in stabilize in my F330 Flamewheel Rate P and I at half of default.
I really like the little pre-arm button continuous blink for not pre armed and 2 blinks and a pause for pre-armed.
I had a condition where I was checking correct thrust compensation while holding it where the motors would not turn off, transmitter, nothing would work stayed at medium throttle.
That little button saved me just held it down for a few seconds and back to not armed.
Transmitter battery was very low during this test so that may have been what dropped out.
In any case your little arm button/LED is a real asset.
@Dan Overholt: The paper was an awesome read, I like in particular the solid application of statistics with significance checks, instead of just conveying news concepts. You do not happen to have more referencers, also in the audio / buzzer domain?
I will refrain from conveying yet any particular position, I'd like to collect more feedback first.
Yeah, that DJI system is about as helpful as nothing (of course it can be learned...). Consider traffic lights. Simple, no misunderstanding (though I admit *some* people don't know what to do when some colors of traffic light are flashing). If it's important to know, it deserves its own indicator: no coding or counting, it's basic human ergonomics. Bad or dangerous situations should be in your face. If you need to know the number of something, bloody well display it as such, this is no micro-gadget where there's no space. The cynic in me would suggest there's no benefit to the manufacturer to help preserve your flying device, so little effort is put into this, why I like OS.
@Gerard, @Gary:
Totally agree with pretty much everything you wrote. The craft in flight should absolutely be as robust as possible, sensor fusion, clever tricks, all of it. If all it's got is one wing and a battery, it should keep flying.
Problem is, it should absolutely never allow itself to take off in that condition. There are too many stories in the forum of craft that took off thinking that home was 5 miles away, or that north was west, or that they were launched 500 feet underground. Full-scale pilots are trained to be able to fly to safety with failed instruments, but there are checklists to make absolutely sure that they never leave the ground that way.
Right now, many times the first indication of failure is a loss of control at altitude. Some poor soul has to ditch his plane in the tall grass or watches his quad fly to the horizon, posts the logs to the forum, and finds out the compass was way off from the start or that home was set when GPS mostly unsure of what hemisphere it was in. Obvious and preventable.
As far as "problematic" safety measures are concerned, that's the whole point. You want the system to be as problematic and fragile as possible, while its still on or near the ground, before anyone's safety is in jeopardy.
@Dany:
That chart completely disproves your point. Were you being sarcastic?
Dany,
I'd love to see you have that as an option, but personally I like to spend my time flying rather than learning Morse Code.
DJI is completely insane if they think that is appropriate for a consumer grade device.
I don't think it's appropriate here at bleeding edge central, but for newbies it is an utter disaster.
I agree 200% that we need more feedback.
I also wish it was simpler and more intuitive than just blink patterns or colors...
At first with the Phantoms many customers were thrown off by the "mandatory learning of patterns" but fear only last 2-3 flights. Humans have something called a brain... and one of its purpose is to store information. Use the system and you will learn it!
So with that said if we have nothing else than blinks and patterns I vote to use the DJI "standard"...
Ok that is not perfect, but that is simple... There is more patterns/colors we can do for sure...
The other main idea I had but still fail short finding time to implement is to have a section dedicated to flight mode (like the arm led code) so the Arms only indicate flight mode.
Then you have a back display for the health (GPS signal, armed or not.... things like that...) maybe an array of RGB LED (3-4) for GPS signal quality all red = not lock, no GPS, you start adding Orange as you get more and over 6 you turn to green.... something like that.
So we can train our brains to look at the back for GPS and Armed / Disarmed and the Arms blinks/colors for the modes.. Acro has to flash fast! Stabilize a nice slow pulsating. The follow me will need a Cylon visor pattern... all red... hehe
anyhow, I vote for more copter feedback, but please don't go banana on using 12 colors and 22 blink patterns... my brain is running out of space! :)
Dany
www.CanadaDrones.com
@Jonathan, I agree with most of what you say in principle, although I am afraid in practice, some of the safety measures would turn out to be more problematic than not having them.
In a normal consumer product, sure, but this is an open source, open hardware it changes everyday environment where final or stable builds are outmoded by the time they have happened.
In any case, one thing I absolutely do not agree with (at least for copters is for x seconds perform an immediate throttle cut.
If you were to implement such a thing at all, it should just be to ensure a reasonable descent rate until it stopped going down (arrived at ground) and then cut the throttle. Basically a standard fail safe.
I agree entirely with Jonathan, but would also like to raise a concern regarding "obvious" responses. The response itself is easy to implement. The hardest part is correct event detection in the face of potential sensor failure. Detecting a crash for example to explicitly disarm the motors is a safety feature. But detecting this only on GPS is very dangerous. Any GPS outage could cause the crash. So a bit of sensor fusion is needed with airspeed sensor and IMU. This leads to another problem that the detection may *not* work when sensor failure occurs. Then the safety feature doesn't work. It also highlights the fact that the system must somehow be able to know which submodules are failing and disregard those sensor readings. This gets very hairy very quickly, because it leads to situations where one simply has to state: "given X and Y, then Z works. Otherwise it assumes W".
This is further complicated by the fact that some of these events can only be detected over time. For example, a reduction in velocity from 5m/s to 0m/s in X milliseconds.
An AP which simply tries its best is more predictable. It either flies or crashes for some clear failure reason. A more clever AP can become a mysterious flying machine for an operator.
Anyway... back on topic... there's also a time when the operator sees the LEDs and for the rest of the flight, they're simply not visible. Personally, I think the value of the LEDs is most apparent during the action of arming. We've got the quad on the ground and we want to arm it and take off. A couple of checks are done to "allow" us to arm it. if one of those checks fail, it should give us some feedback.
Given the above paper, it could be helpful to investigate blinking patterns that people easily associate with failure of gps, telemetry, R/C or others. I don't think these LEDs can manage their brightness, so these can only be on/off?
-
1
-
2
of 2 Next