RFC 0016 - Mavlink Standard Modes

[hamishwillee]

This RFC proposes a microservice that will allow a GCS (or MAVLink SDK) to use a safely use a "standard" set of flight modes without any prior knowledge of a flight stack.

The proposal defines a small (initial) set of standard autopilot modes, along with mechanism to query available modes, set the standard mode, and publish the current standard mode (if a standard mode is active).

This is sufficient to determine what modes are supported, command a flight stack into a standard mode, and have it behave in a predictable way.

EDITED: STATUS

• This has been "approved for testing". The messages defined in the proposal are now present in development.xml.
• PX4 issue: Support MAVLink Standard Modes PX4/PX4-Autopilot#19197

[auturgy]

from dev call: use capabilities bit to declare support for standard modes?
Suggest split MAV_STANDARD_MODE_SAFETY_RETURN to MODE_RETURN_HOME and MODE_SAFETY_LAND (rally point landing)

[hamishwillee]

@auturgy @LorenzMeier @julianoes @dagar, @ThomasDebrunner, @tridge @rmackay9 @magicrub @WickedShell @meee1

FYI, this has just had a updates to the proposed design and possible alternatives (following discussion in the MAVLink call last night).

The only change to the "proposed design" is that return mode was split into two modes: RTH/RTL and "safe recovery" (rally point/mission based landing). The argument for this change was that to an uninformed user a rally point landing looks like a flyaway: if the GCS can differentiate the mode it can show the user what is happening - for example, it can choose to show rally points.

The dev call also discussed a number of alternatives, all of which have pros and cons. These have been added as alternatives:

• To get and set the current mode we might infer the standard mode from the custom mode and then use existing fields in heartbeat and mode setting command, respectively. This makes things hard for consumers and users and requires that there must be a custom mode for each standard mode. Horrible, but a valid option.
• We could have a flag(s) to indicate support for standard messages rather than asking for available modes. This would be much easier for consumers but would mean no support for custom modes and we would have to publish the standard mode (in heartbeat or elsewhere).

Comments welcome. I'm very happy to talk offline about any concerns people would like to talk through. If you like the current proposal, indicating support to me or @auturgy would be appreciated.

[auturgy]

Still disagree with this description. "Circle fixed point" is a better description/behaviour for "position hold" in FW

[hamishwillee]

Bugger, of course you're right. Off to get a coffee. I will fix.

[hamishwillee]

@auturgy Actually no, this is what I meant:

On PX4 this is what the mode does on FW - it is a stabilized mode when flying (i.e. roll/pitch limited) but when you release the sticks it stabilizes orientation to the earth plane and holds the track - ie if you draw an imaginary line to infinity and get blown of course you return to that line.

I'm trying to work out what ardupilot does but I can't tell which is the most comparable flight mode from these descriptions - thoughts: https://ardupilot.org/plane/docs/flight-modes.html ?

I can certainly accept that position hold would be more logical as a circle/loiter (rather than holding track) based on the name. Not sure if it is "safer" - depends on whether you're more happy to take back over flying from straight flight or perhaps you'd just prefer it to circle while you think about it.

Well worth discussing.

[auturgy]

"Cruise" is the closest ArduPilot mode to what you describe. Perhaps omit Position Hold for fixed-wing. Acknowledging PX4 are using it to describe a mode, it actually doesn't make any sense as a mode name for fixed wing aircraft (that can't hover).

[auturgy]

A quick check of iNav (https://github.com/iNavFlight/inav/wiki/Navigation-modes and https://github.com/iNavFlight/inav/wiki/Modes) shows that they call this behaviour "NAV CRUISE", with "NAV POSHOLD" being loiter in circles around a point.

[hamishwillee]

Changes made following devcall discussion in this commit: aa2aa90

In summary, the naming of Position Hold would be confusing for users in the fixed wing case, because a fixed wing vehicle does not hold or loiter in this case but continues on the current track (and you would not want to be flying along and then have the vehicle circle in the deadzone). The proposal was that fixed wing be represented by a separate mode "Cruise" with the same semantics - this maps the behaviour of INAV, which supports the equivalent modes: "NAV CRUISE", with "NAV POSHOLD"

MC and FW vehicles should support the appropriate types. VTOLs that are commanded to fly a mode should transition to MC or FW as appropriate in order to fly it.

The other alternative was to find a name that does not imply holding. For example SAFE_MANUAL (I would personally have preferred this approach if a good name could be agreed, but there is a lot to be said for following prior art).

@auturgy @julianoes FYI

[hamishwillee]

@auturgy @LorenzMeier This adds the orbit mode, and tidies Position mode to note that FW must not implement it.

Please review. Note that this explicitly states that

• the manual behaviour of the mode is flight-stack specific.
• If VTOL gets set to orbit in MC mode and MC mode does not support orbit, should it transition to FW or just reject the mode? I have said it transitions to FW in the same way as MAV_STANDARD_MODE_CRUISE does, but to my mind this is a bit different, as MC can support orbit (but not cruise).

[hamishwillee]

@auturgy @LorenzMeier This section now suggests a separate message for getting the current mode, rather than using the HEARTBEAT. This was as I understand it discussed in https://github.com/mavlink/mavlink/wiki/20220119-Dev-Meeting.

[hamishwillee]

@auturgy @LorenzMeier This section was added suggesting using component information for getting available modes rather than having messages.

Component information is a much better approach - this sort of thing is why the service was invented. But we can't build on that unless it is part of the standard.

[hamishwillee]

Mavlink devcall 20220216 confirmed that this RFC can be merged into development.xml for prototyping/testing. This was done in mavlink/mavlink#1750

Next step: prototype implementation.

[hamishwillee]

This was accepted in principle by all parties. It is expected to change following testing, but in order to have some workflow here, I have set this as "Approved Draft" and will merge.