Proposal: Support for common flight modes

[hamishwillee]

EDITED. This has been updated to match the proposed RFC 0016 - Mavlink Standard Modes #17 as of mavlink/rfcs@0df3db8

It provides the four parts agreed in the RFC:

• A simple and agreed set of common modes.
• A way to set those modes
• A way to get the current mode
• A way to determine what modes are supported - ideally both standard and custom.

This proposal attempts to keep everything the same for existing systems - it is a pure addition. It allows you to discover the available modes and the mapping between them. A GCS can therefore choose to just support standard modes, or it can detect and use any other mode it likes without having to know the underlying system.

[khancyr]

I think that is good idea. But I don't see where the differents autopilot can agree on mode specification.
Even having things like MANUAL/STABILIZE, or AUTO mode are subjects to implementation and capacities wanted.

I think at one place that the standardization would be excellent is in the critical modes :
NO_GPS_LAND
SAFE_LAND
RTL
SAFE_RTL
ABORT
I think that for those we could have common and reproducible behaviour that would be handily.

Edit: I didn't saw it was a PR with some mode example, but the one proposed are clear and clean to me and closed to my though on safety modes.

[hamishwillee]

@khancyr Thanks for the edit. As you note, the modes selected are carefully defined to be high enough level that we can agree on them across flight stacks, and low enough level that they still make sense to a user when selected on a GCS.

W.r.t. more specific behaviour for return mode I do like aspects of your comment. In particular, it would help a GCS/user to know if a return is using a mission for the landing, or using rally points etc so that it can configure the UI. Not "necessary", but useful.

We could consider defining standard modes or "submodes" for these. But probably be better to have a separate command to get and set the return mode behaviour that is separate to this. My reason being that if we use modes we have to make the system treat these like modes, and think about what a GCS should offer in the UI if the system offers many possible options.

I'm refining this in an RFC which I hope to post this week. I'll add this as an open question "can we get more specific information about the actual return mode/other modes". Before settling on a design we should at least look at ways that we might extend for that in the future or agree that we will not extend it.

[hamishwillee]

@khancyr @auturgy @julianoes @LorenzMeier FYI, I have refined this and created an RFC here: mavlink/rfcs#17

The proposal differs materially from this PR only in that:

• the current standard mode gets added to HEARTBEAT rather than being in its own message.
• This is a 16 bit field to allow more than 256 standard modes ... assuming we might one day want to support modes for components other than the autopilot.

[julianoes]

FYI @dagar and @ThomasDebrunner

[auturgy]

@tridge @rmackay9 @magicrub @WickedShell @meee1 Broad input would be good here. I'm very much in support of bringing Mavlink closer to being a "standard", however the devil is always in the detail. Adding extensions to Heartbeat is a critical decision.

[hamishwillee]

@tridge @rmackay9 @magicrub @WickedShell @meee1 @dagar and @ThomasDebrunner Actually, could you please instead look at the RFC in mavlink/rfcs#17

This PR was the first iteration. The main difference is that this PR uses a specific message for getting mode updates while the RFC uses HEARTBEAT (which most people seem to think is more consistent and safer).

The RFC also includes some alternatives that are worthy of discussion - for example, if we decide to allow querying of only standard modes (rather than all modes) we would make the job easier for a user of the service, at the cost of some interesting options that are not essential to this service.

[rmackay9]

I wonder what problem this solves though...?

If the intention is to make it easier for GCSs to display a list of available modes then maybe we should try and aim just for that. So a request and reply which provides a string given a mode num. Doing this would be moving part of the mavlink definition into a real-time request-response but it could be valuable.

I can imagine there could be some value from a GCS or companion computer being able to always use the same number to change a vehicle into Return-to-Launch regardless of the frame (Rover, Plane, Copter) and flight stack but I wonder how much it matter in practice because there are so many other differences.

Sorry if this is coming off as negative..

[hamishwillee]

@rmackay9 The aim is to allow a GCS or SDK to use a flight stack (or more generally a component) that it knows nothing about. It doesn't make any difference if you are in a closed ecosystem that only cares about one flight stack. It makes a big difference to a GCS or SDK that wants to fly or do basic testing on any stack. It makes a difference to MAVLink, which is supposed to provide common mechanisms to do common things.

The suggest modes are defined broadly enough that most flight stack already match them (certainly ArduPilot does) and that a user choosing these modes in a GCS would not be surprised by the differences between stacks. The possible exception being return mode (for which I have open questions in the RFC).

Further, a GCS can configure itself appropriately based on the flight mode - e.g. displaying missions etc because it knows what they are. It can also provide standard strings and translations.
You can't do that just by getting the modes supported by the flight stack, because there is no way to map the string or ids that the flight stack uses for particular things to the defined behaviour - you call it return mode, I call it RTL, the GCS has to guess.

Publishing custom modes is not needed by this proposal, and it would be simpler if they were omitted. But personally I think it is useful for a GCS to be able to choose to expose these too, so that's part of the RFC.

Best place to discuss this is against the RFC, which already answers these questions: mavlink/rfcs#17

[rmackay9]

@hamishwillee,

I wonder a bit though if we can agree on standard modes. I've seen some changes in mavlink to do with deprecation of messages we still use that makes me question whether enough effort will be put in to really ensuring that everyone agrees on what the "standard modes" are now and in the future.. Perhaps one side will just unilaterally decide without any consultation.

[hamishwillee]

Hi @rmackay9,

The governance model has been designed to reduce the chance of unilateral changes; I don't think we've had any instances where that has happened since we started using it. I'm certainly trying very hard to make sure that every single addition and potential change gets oversight from all stakeholders and to work with @auturgy to remove the inconsistencies. If I have made a mistake I apologize - I'm doing most of the merges now, so any infraction is most likely my fault.

Further, the risk of that is particularly low in this case because any change would still have to meet the goal of allowing a GCS to support an arbitrary flight stack. The stakeholders who care about this most are government organizations who are afraid of lock-in to a particular stack.

Could you please look at the RFC and see if you can agree with the definitions now. Even better, can you think of improvements that meet the stated goals.

Thanks!

P.S. Would love to have a chat about the deprecated tag offline. MAVLink use the tag to mean "we invented a new message that does the same thing only better - we'd like implementers to start upgrading". That is a "needed" signal. If we can find a better way to signal it and broad agreement on that I'd love to adopt it.

More generally longer term MAVLink has to be better at signaling changes:

• better at getting buy-in for updates (governance model),
• define a more truly standard/common subset so that most users seeing a message there can expect it to probably be implemented (governance model, standard test suites
• flight stacks to be better at updating once agreed changes go in
• flight stacks to be better at publishing what parts they do/do not support (component information).
• versioned releases that remove cruft.

[hamishwillee]

Mavlink devcall 20220216 confirmed that RFC 0016 - Mavlink Standard Modes can be merged into development.xml for prototyping/testing.

This PR has been updated with the RFC version of the messages and will be merged.
FYI @LorenzMeier @auturgy