search

d-ronin / dRonin

The dRonin flight controller software.
http://dronin.org
Other
289 stars 167 forks source link

Override to Allow Arming With Inapplicable Alarms #155

Open dustin opened 8 years ago

dustin commented 8 years ago

"Inapplicable" in this case means specifically related to the pilot's intent -- not that the alarm doesn't actually apply to the current configuration.

Use case:

User has Pos Hold or similar autonomous feature, but doesn't care whether it works. Would like to ignore alarms related to GPS signal most of the time since would be a rarely used feature. Not working is considered acceptable for the user, but the user does not wish to reconfigure.

Issues:

  1. When would they be ignored? Need some sort of signal that says "It's OK." Or just always, and the user is expected to pay a ton of attention before arming (better signaling, buzzer module, etc...)
  2. That mode would need to be rejected entirely. What would this mean? Should the three mode switch become a two mode switch? This part could lead to much confusion.

    Possible alternatives:

Get mode selection working in MWOSD similarly to BrainFPV. Don't allow alarming with invalid configuration, but make it easy to change the configuration in the field.

dustin commented 8 years ago

Another Alternative

Profiles.

Have configurable profiles indicating your intended type of flying. The ideas is to communicate how important it is to have GPS lock be an option, etc... A bit less clumsy than configuring your switches and is something people want anyway.

tracernz commented 8 years ago

I don't like this so much, it just opens up the possibility of the user shooting himself in the foot and blaming the software. You know people will make YouTube videos telling people to enable x, y, and z and one of those will be this and newbies will follow not understanding the consequences. I prefer that people just need to remove the invalid flight mode as part of the reconfiguration that results in it being misconfigured.

dustin commented 8 years ago

@tracernz I think the key point is capturing the user's intent. If the user says "I don't care that GPS doesn't work" and the ramifications of that are obvious, then that's fine. In that case, there is no autonomous mode available, so the flyaway wasn't caused by that.

The downside, though, is that the user could still think there is and have a flyaway anyway. The OSD, at least, wouldn't be showing you in an autonomous mode.

mlyle commented 8 years ago

Another issue is that the way mode sequencing works now is very lousy. There is no good central controller or handshaking of flight mode. If you go into position hold, and no one's there to service it... no one is controlling the quad.

tracernz commented 8 years ago

So is this checkbox going to disable just the poshold/no-gps-lock error or all flight mode misconfigurations? A checkbox that says "override GPS lock arming requirement", with a confirmation dialog is different to a checkbox that says "allow overriding arming requirements", I can see the latter ending up in every experts YouTube setup video with no explanation for new users.

P.S. Inapplicable alarms is a misleading title, we already do what the title says, a poshold error is applicable if that flight mode is configured ;-P.

dustin commented 8 years ago

I agree that the title is misleading. I tried clarifying that, but it is actually kind of confusing. I don't think it's trivial to do something that makes sense. e.g. even if you have profiles and stuff, does my tx know this? My Taranis stil tells me my 180 has an autotune mode when I disable the autotune module.

I agree that all the videos will tell you to just turn off the things anyway.

It seems that the two alternatives I listed are better. Don't allow alarming with flight modes that we know can't work -- but make it easy to change to a set that can.

ABLomas commented 8 years ago

About "limiting user" - there's no point to completely disable access to some "potentially dangerous" settings, because smart users will go away and dumb users will just listen "eh this can't do X or Y, it's useless". If someone wants to crash it's own copter, it will find a way, limiting configuration won't help, only scare away power users.

About GPS as dependency - this is not unique situation, many flight controllers already solved this in one way or another. But, let's implement wheel again ;-) Limiting copter from lift off if GPS has no lock does not save copter from loosing GPS lock in flight, which is the same dangerous situation (and yes, that happens - from power issues to wiring, from sky coverage to acro flying (all patch antennas are directional), etc) - so this needs to be handled, but you do not disarm copter in sky, if it lost GPS lock for some reason?

In my opinion there may be two ways to resolve that from FC side (alerts/telemetry later): 1) do this as many other FC's do - keep last selected mode, if next mode is unavailable. In other words, if there's no baro/gps, but althold selected from rate - keep rate. If no GPS lock, but RTH requested while flying attitude - keep attitude (autoland after timeout would be safer i guess, but who knows). 2) keep it as is - blocked arm if some potentially dangerous mode is selected, handle in-flight failure in some way as it is now (no idea how). Add option (without GUI) to let power users remain in control (not every user is dumb, not everyone blindly copy options, and yes, i know, i know, "if you want just fly with manual controls get yourself naze32 with baseflight") which overrides arm'ing requirement. If option is set to modename- let arm even if autonomous modes can be selected, but unavailable. If user sets autonomous mode without GPS lock, etc - set to "modename" selected by option (rate, attitude, etc). This way everyone will be happy - most users will just keep it on default and waits until lock, racers would race without waiting for GPS lock. Only dumb copycats may run into issues, but this would be extremely rare case (do not compare this to DJI pls ;-)

mlyle commented 8 years ago

@ABLomas We discussed this on IRC, and this is tiresome. We are planning on doing some things for usability.

There's a valid use case for "I'm flying my nav quad indoors where GPS isn't available". There is not a valid use case for "I want there to be positions on the mode switch configured for things that can never ever work with the rest of the configuration."

tracernz commented 8 years ago

Yeah, two separate issues there, misconfiguration, and unavailability of data. The latter we can think about doing something about, the former will always prevent arming (although we could do something about making it more obvious for users who can't see red boxes on the system health widget, or make it clearer what a red box means).

dustin commented 8 years ago

i.e. perhaps we should make it easier to have the user state that those modes won't be used.

Rather than trying to do something fancy like remap the mode definitions automatically based on what is available at arm time, let's just ensure each one is possible.

IMO, there's no difference between arming in a mode and arming and switching to a mode. If it's OK to not allow arming in a particular mode because the mode is broken, it's OK to disallow users from "working around" that by always arming in rate and then switching to some other mode which may or may not be what they have configured.

I'm not convinced there's a valuable expert mode that includes having the user's PH mode switch be in anything but PH.

I do think there's a valuable way to make sure that before it leaves the ground, everything that can happen in the air will be as valid as it can be. Things can go wrong in the air, but if they're already known to be wrong, then there we shouldn't take off.

(my experience with GPS varies -- I've had them burn up on the aircraft, come unplugged, or just take ten or fifteen minutes to get their initial lock -- so "just take off and see if you get GPS" is a pretty bad case as well).

Even the "profile" concept is a bit advanced. My taranis doesn't necessarily know what profile I'm in, so it can't remap flight modes and switches all that easily. I'm sure I can rig something up, but we're getting into pretty advanced configurations.

ABLomas commented 8 years ago

Back to question - did someone read #2 suggestion on my post? Maybe i did not explained it clearly, i will try to clarify:

In other words - no "unknown" mode. No "random" mode. Everything here is perfectly defined. This would close few existing issues too (who knows, what copter will do in air when GPS lock is lost when flying?) - if you set this value, you will know that copter won't try to run away without GPS lock for example, but hover using Attitude...

So, only issue is with "random youtube experts" and copycats?

mlyle commented 8 years ago

@ABLomas I'm concerned that we're pretty far afield and talking about things that were not in the original problem-- an invalid configuration.

I think right now the way I'm thinking of this is in the form of configuration profiles. We need them for other reasons (3S vs. 4S, VTOL, etc). You wouldn't be allowed to arm with a configuration with inapplicable flight modes or toggle to a configuration in flight with inapplicable/unattainable flight modes.

The way I view it, fallback behavior when an anomaly happens (loss of GPS lock in flight) is fundamentally different from when GPS is missing before arming which in turn is fundamentally different from configuration issues where we know there are parts of the configuration that cannot work in any case. What is "best" to do in these 3 situations likely differ.

ABLomas commented 8 years ago

"You wouldn't be allowed to arm with a configuration with inapplicable flight modes" - exactly that's what we are talking about. This limitation only adds complexity ("bring your PC to field, else you won't know why your copter refuses to arm") and limits usage ("wait until perfect GPS lock even if you do not use").

mlyle commented 8 years ago

"You wouldn't be allowed to arm with a configuration with inapplicable flight modes" - exactly that's what we are talking about. This limitation only adds complexity ("bring your PC to field, else you won't know why your copter refuses to arm"

Not really. The particular thing you encountered was one of many things we have where the configuration is known to be invalid and our GCS does a poor job of guiding you through getting a valid configuration. That is somewhere we plan to expend UI effort to improve things.

and limits usage ("wait until perfect GPS lock even if you do not use").

And like I have been trying to say above, I view this as a separate issue with separate solutions.

bazyl78 commented 8 years ago

Can you at least do a small patch and decrease nimber of sats to 5?