ardupilot: added VEHICLE_MODE message
this will allow for the creation of custom flight modes in lua scripts
Could this be considered in context of https://github.com/mavlink/rfcs/pull/17/files where a proposal for a somewhat similar message:
<message id="435" name="AVAILABLE_MODES">
<description>Get information about a particular flight modes.
The message can be enumerated or requested for a particular mode using MAV_CMD_REQUEST_MESSAGE.
Specify 0 in param2 to request that the message is emitted for all available modes or the specific index for just one mode.
The modes must be available/settable for the current vehicle/frame type.
Each modes should only be emitted once (even if it is both standard and custom).
</description>
<field type="uint8_t" name="number_modes">The total number of available modes for the current vehicle type.</field>
<field type="uint8_t" name="mode_index">The current mode index within number_modes, indexed from 1.</field>
<field type="uint8_t" name="standard_mode" enum="MAV_STANDARD_MODE">Standard mode.</field>
<field type="uint8_t" name="base_mode" enum="MAV_MODE_FLAG" display="bitmask">System mode bitmap.</field>
<field type="uint32_t" name="custom_mode">A bitfield for use for autopilot-specific flags</field>
<field type="char[50]" name="mode_name">Name of custom mode, without null termination character. Should be omitted for standard modes.</field>
</message>
I wonder if "MODE_DESCRIPTION" might be a better name. This message's purpose is not to provide the current mode but rather to give information about a mode.
Otherwise it looks OK I think.
@auturgy's message could cover the same requirement if the "short_name" field was added to it... I think
@hamishwillee fyi
Perhaps stupid questions but:
- What's the point of this short name - it's only 4 chars?
- What's the point of the long name for your use case? I.e. a lua script is going to need to know what modes it is dealing with right or are you presenting this to the user?
- RFC uses 50 chars for the name while you have granted 20. Are we wasting bits in the RFC message?
There is certainly a lot of overlap so assuming we go for the standard modes would be better to use that.