mavlink
Discussion on Confirmation for Changing Modes via the Toolbar
Seems people are split over whether changing the mode should require a confirmation.
In my opinion it either needs an option with the default being to require a confirmation, or to use something like a DelayButton with a half second period. Anything else seems too unsafe to have as a default
I think we should ensure the mode change via QGC can be easy since the vehicle usually needs quick respond. Especially for fixed-wing. It can fly 20m-40m within 1 second delay. So we need the mode change in a short time. But sometimes we do worry about the "accidentally"trigger the wrong mode without confirm. for instant manual mode.....
So how to balance "safe" and "quick". Can we make the "dangerous" mode needs to be confirmed such as manual/acro.....and the "safe"mode not?
I agree that is should be single step. In all my flights over the years I’ve never put it in the wrong mode accidentally. Also, I’d argue that if this hasn’t been reported by many as an issue (going to the wrong mode), why are we changing it now? It’s actually more unsafe to not be able to get in a mode you need immediately (imo).
If this is a tablet issue then maybe we add some type of condition where android/ios(🙄) have the two step but everything else does not.
@ryanjAA if someone is reporting an issue on GitHub they're less likely to be the kind of person I'd be concerned about, but also in my own personal build I've removed the confirmation to the pause button that enters brake mode. So I see both sides, and that's kinda why I think making a toggle switch similar to the "Edit Displayed Flight Modes" would be the best solution.
It's hard to both open the list then select a mode accidentally but it's not as uncommon to open the list trying to change to a mode then fat-fingering another one, specially in small touchscreens. I've also had an issue where an user tried to open the list, it took a while to show up and by the time it did the user tapped to open it again which resulted in them changing to MANUAL (!).
IMO two step should be the default and then the user/custom fork developer can make it one step if they want, once their vehicle has reached the maturity where none of the modes in the list can be dangerous to accidentally switch to.
Definitely don’t make this two step. That’s dangerous. Fat fingering is rare (I have never done it).
List populating delay should never occur. Check hardware?
Make it a toggle for flexibility but I would not change something that has always been a certain way.
Imagine a user doing a flight with a change like this and the panic.
Another idea (not a great one but throwing it out there) - 2 step for manual mode only.
Definitely don’t make this two step. That’s dangerous.
Dangerous how? Isn't it more dangerous to accidentally switch to an unwanted mode? If you mean that changing to manual in an emergency will be slower, then you probably shouldn't be triggering the mode change via telemetry since that's much more likely to fail than through RC, and a physical switch will always be faster than any GUI.
Fat fingering is rare (I have never done it).
Maybe it's rare with your setup, but some of the most common devices where QGC is used are small-ish tablets where the list items appear quite small and close together. An example is the SkyDroid H16 which also has a REALLY bad digitizer. Misinputs are a real issue.
List populating delay should never occur. Check hardware?
The list is populated on vehicle connection, the delay is on rendering the list. QGC can be quite laggy on low power devices.
List populating delay should never occur.
Agree. I've never seen perf problems like this all the way down to my slowest Herelinks
So I think it makes sense that something should be done here, just not what is in there right now. So for 5.0 I'm going to put this back to the way it was before in 4.4 with no flight mode confirmation. And then I'll revisit it in 5.1 with something that tries to tread the center of simple but quick.
Definitely don’t make this two step. That’s dangerous.
Dangerous how? Isn't it more dangerous to accidentally switch to an unwanted mode? If you mean that changing to manual in an emergency will be slower, then you probably shouldn't be triggering the mode change via telemetry since that's much more likely to fail than through RC, and a physical switch will always be faster than any GUI.
Fat fingering is rare (I have never done it).
Maybe it's rare with your setup, but some of the most common devices where QGC is used are small-ish tablets where the list items appear quite small and close together. An example is the SkyDroid H16 which also has a REALLY bad digitizer. Misinputs are a real issue.
List populating delay should never occur. Check hardware?
The list is populated on vehicle connection, the delay is on rendering the list. QGC can be quite laggy on low power devices.
I’d agree that it’s dangerous to have an unwanted delay when not having one in the current norm.
Irrespective end the current mode, if you needed to go to return (notifications will be at the gcs, not person with the sticks assuming those are even present), two step change to return mode could be cumbersome to say the least and catastrophic if too much of a delay. Plus I’ve written and seen a lot of CONOPS that dictate immediate user intervention and often times it’s two in one, meaning, handing control to PIC is the verbal command while doing just that. GCS controller switches and PIC assumes control.
I think tbh we can make a case for and against this a million different ways but I don’t see a strong case to change the functionality from one extreme to the opposite. I see a strong case to offer it to be more than way though.
Catering to a specific type (and I don’t know what is the most popular device type but I imagine android vs pc download statistics do exist on the server) is not ideal. Especially because bad digitizer fidelity is a subset of even that…
I’m all for the option of change, but not absolute change. Aka a toggle.
Now, that said we run and maintain our own private fork anyway so this has very little practical implications for me but I really think forcing it to be two step isn’t ideal.
Toggle for the win.
I think using a delay button with a 500 msec delay works really (really) well. Simple and fast to confirm.