Generic Payload Protocol

[thomas-watters-skydio]

The goal of the proposed message set is to support as many payloads as possible and support discovery.

[thomas-watters-skydio]

@hamishwillee @julianoes would love a good look over this one

[hamishwillee]

@thomas-watters-skydio Thanks for this. Just had a proper read through.

1. Would it be possible to outline how this would replace "theoretically" the winch and/or gripper mechanism if you wanted to use this instead (say on a system that didn't support those). I'm having trouble understanding exactly what messages would be sent to represent these cases. (I.e. what payload, what function, what telemetry) and what a GCS could do with this compared to custom messages.
2. Do you have a flight stack/GCS you plan to implement this in? Would the integration be visible to us? How would you test it - with what payloads?
3. What kinds of timeframes are you looking at?
4. What kinds of payloads do you have in mind?

Historically we've considered that the requirements of payloads are quite different - consider a camera, illuminator, winch or a gripper - and hence that a useful integration requires custom messages.

That said their are common behaviours that we've started to identify as pain points in integrations. For example, a payload might have certain requirements on its use in a mission - such as indicating when it is ready to proceed to the next waypoint, or whether the vehicle needs to be able to land to use it.

Once I have a good understanding of how this works we'll put this before the flight stack vendors and GCS to gauge interest.

[thomas-watters-skydio]

@hamishwillee @julianoes i updated the RFC to address i think most of your concerns, i welcome your feedback

[thomas-watters-skydio]

@thomas-watters-skydio Thanks for this. Just had a proper read through.

1. Would it be possible to outline how this would replace "theoretically" the winch and/or gripper mechanism if you wanted to use this instead (say on a system that didn't support those). I'm having trouble understanding exactly what messages would be sent to represent these cases. (I.e. what payload, what function, what telemetry) and what a GCS could do with this compared to custom messages.
2. Do you have a flight stack/GCS you plan to implement this in? Would the integration be visible to us? How would you test it - with what payloads?
3. What kinds of timeframes are you looking at?
4. What kinds of payloads do you have in mind?

Historically we've considered that the requirements of payloads are quite different - consider a camera, illuminator, winch or a gripper - and hence that a useful integration requires custom messages.

That said their are common behaviours that we've started to identify as pain points in integrations. For example, a payload might have certain requirements on its use in a mission - such as indicating when it is ready to proceed to the next waypoint, or whether the vehicle needs to be able to land to use it.

Once I have a good understanding of how this works we'll put this before the flight stack vendors and GCS to gauge interest.

1. Would it be possible to outline how this would replace "theoretically" the winch and/or gripper mechanism if you wanted to use this instead (say on a system that didn't support those). I'm having trouble understanding exactly what messages would be sent to represent these cases. (I.e. what payload, what function, what telemetry) and what a GCS could do with this compared to custom messages.

I added an example of how we could replace the illuminator protocol

2. Do you have a flight stack/GCS you plan to implement this in? Would the integration be visible to us? How would you test it - with what payloads?

We will be implementing in our flight stack, we plan to do an end-to-end integration with a "anything" attachment, something with a sensor and an actuator. I could probably release the attachment side code relevant to the integration, but we will be integrating it with our first-party application

3. What kinds of timeframes are you looking at?

1-2 months

4. What kinds of payloads do you have in mind?

listed in the rfc

[hamishwillee]

Thanks for the changes @thomas-watters-skydio - really helped me get my head around this.
Added a few notes, but happy to take this to the dev call.

Note

That's just the beginning bit though. We'll have to get broader buy-in from the various communities.
A flight stack might not have any interest in this, or might have strong opinions about need for support in missions etc.
For example, I know that the biggest problem with using generic actuators in missions is that you don't know what is being triggered.
Let's see.

YOu've clearly put a lot of thought into this.
Just a few "stream of conciousness" notes as I was reading through.

• Limitations

  • Can't be used in missions - because these use messages not commands.
  • Can only be directed at components. What that means is that an FC could have at most one attached "logical" generic component.
    You could of course have (say) ten components represented as functions with different names etc.
  • The control messages need to be targetted or everything might try run them. Using the target_system and target_component fields. May need an ACK. Even better if a command can be used.
  • Control messages aren't efficient "over the wire" - i.e. each action must be sent in a number of messages. That will generally be OK for commands, but might not be as favourable for streamed telemetry.
  • The UI will have to be constructed dynamically from the description messages. This would be better as component metadata json because you could have control over the UI and ordering - harder for MAVLink because messages aren't necessarily ordered as you might expect.

• The _DESCRIPTION metadata messages are a great. I don't think any of them need to be streamed - they can be requested perhaps on a protocol bit.
  You could choose also choose to do these as component metadata. I would consider adding an URL for that at least to allow easier translation. Also useful for extending the extra payload metadata without having to extend the messages.

[thomas-watters-skydio]

Thanks for the changes @thomas-watters-skydio - really helped me get my head around this. Added a few notes, but happy to take this to the dev call.

Note

That's just the beginning bit though. We'll have to get broader buy-in from the various communities. A flight stack might not have any interest in this, or might have strong opinions about need for support in missions etc. For example, I know that the biggest problem with using generic actuators in missions is that you don't know what is being triggered. Let's see.

YOu've clearly put a lot of thought into this. Just a few "stream of conciousness" notes as I was reading through.

• Limitations

  • Can't be used in missions - because these use messages not commands.
  • Can only be directed at components. What that means is that an FC could have at most one attached "logical" generic component.
    You could of course have (say) ten components represented as functions with different names etc.
  • The control messages need to be targetted or everything might try run them. Using the target_system and target_component fields. May need an ACK. Even better if a command can be used.
  • Control messages aren't efficient "over the wire" - i.e. each action must be sent in a number of messages. That will generally be OK for commands, but might not be as favourable for streamed telemetry.
  • The UI will have to be constructed dynamically from the description messages. This would be better as component metadata json because you could have control over the UI and ordering - harder for MAVLink because messages aren't necessarily ordered as you might expect.

• The _DESCRIPTION metadata messages are a great. I don't think any of them need to be streamed - they can be requested perhaps on a protocol bit.
  You could choose also choose to do these as component metadata. I would consider adding an URL for that at least to allow easier translation. Also useful for extending the extra payload metadata without having to extend the messages.

We definitely intend to incorporate this into our "flight stack" and distribute and ICD pointing to it. I do not think the goal of this RFC was to cover the mission use case, but moreso just generic control/feedback from an unknown attachment. It allows payload developers to come up with things we haven't thought of or discovered yet, along with displaying useful information in the UX/UI, although I wil reiterate this is not intended to replace a first-party integration. We just are in the position where we want payload developers to be free to develop whatever they might have in min.

• Can't be used in missions - because these use messages not commands.
  -- I'm ok with that for now
• Can only be directed at components. What that means is that an FC could have at most one attached "logical" generic component. You could of course have (say) ten components represented as functions with different names etc.
  -- The FC may have other way to address components, ie in our case we know what port its connected to and so internally we can enumerate them differently.
• The control messages need to be targetted or everything might try run them. Using the target_system and target_component fields. May need an ACK. Even better if a command can be used.
  -- Yeah when I was developing this message I was not considering that a GCS would necessarily be sending these messages. The ILLUMINATOR protocol for example is used in our system internally, we do not expose this service to the GCS. We could add a COMMAND_LONG for this protocol. MAV_CMD_FUNCTION_CONTROL, but it would be byte packing the data into the float params. I'm open to further thoughts here
• Control messages aren't efficient "over the wire" - i.e. each action must be sent in a number of messages. That will generally be OK for commands, but might not be as favourable for streamed telemetry.
  -- Indeed this is a compromise we made for telemetry. Unfortunately even if we chose to bundle telemetry messages in a BER -encoded array wrapped in MAVLink we are still significantly limited to the data that can be transmitted because of MAVLink's 256 message size limit.
• The UI will have to be constructed dynamically from the description messages. This would be better as component metadata json because you could have control over the UI and ordering - harder for MAVLink because messages aren't necessarily ordered as you might expect.
  -- I agree and i think both should be available. I think using this generic protocol will be a lower barrier to entry. With the metadata service as far as i would understand is the component and the ui layer would still have to agree on some common description of the functions/capabilities of the payloads. This would mean on-going integrations with the UI and payload developers

[hamishwillee]

@thomas-watters-skydio Thanks. So the main point in response to the above is that MAVLink is supposed to be a standard. I get that you have something that works for you, but if the broader community needs support in missions, then that needs to be considered. I can pretty much guarantee they will want feedback from control actions too - at which point commands become logical solution.

In missions when using a payload there is the need for indication that an action is finished so that the next waypoint can be triggered. Do you think the current signals do this sufficiently? I'm not certain.

We could add a COMMAND_LONG for this protocol. MAV_CMD_FUNCTION_CONTROL, but it would be byte packing the data into the float params. I'm open to further thoughts here

See #28 (comment)

Yes it would require byte packing, though I'd probably require it to be sent in a COMMAND_INT. Either way, yes special handling would be needed for types that are more than 64 bits, and the UI is going to have to know this command is different - you can't just shove numbers into the params and expect it to work.

It is perhaps important to note that even though things like params allow for 64 bits, no one actually uses anything other than 32 bits and floats (32-bit reals).

With respect to your comments about this being generic and not intended to be as solid as a custom implementation, I get that. We talked in the MAV call about this, and really were not sure how much interest there would be for flight stacks. We are pretty sure that there are plenty of people doing forks who would like this though - someone who wants to add a simple trigger with a proper UI.

Discussed this a bit in the mav call. It certainly addresses the issues we've had in the past with poor payload design - such as omitting feedback mechanisms from the gripper protocol.

[thomas-watters-skydio]

@hamishwillee Thanks for the feedback. I believe the reason I am proposing this is to come to a standardization that can be broadly adopted. Also our goal of exposing this on main fork and the whole RFC rather than tucking it away in a vendor message definition is to get the feedback from the community on what has worked / may work for the community.

With respect to your comments about this being generic and not intended to be as solid as a custom implementation, I get that. We talked in the MAV call about this, and really were not sure how much interest there would be for flight stacks. We are pretty sure that there are plenty of people doing forks who would like this though - someone who wants to add a simple trigger with a proper UI.

I think you would be surprised about how much demand there is for this. I think a point of comparison would be other vendor's Payload SDK's. We are choosing MAVLink as this interface so that payload/attachment vendors are not necessarily locked into a certain platform.

With regards to incorporating the FUNCTION_CONTROL into a MAV_CMD, i'm OK with this, though I'm not sure ACK is always necessary and that there may be some user cases for tight-loop control, which may not be possible with the command protocol, so I would like to propose keeping the FUNCTION_CONTROL but also adding the MAV_CMD.

[thomas-watters-skydio]

Oh i'll add the URI for metadata as an optional field to the GENERAL_PAYLOAD_DESCRIPTION message as well, forgot that bit.

[thomas-watters-skydio]

Oh i'll add the URI for metadata as an optional field to the GENERAL_PAYLOAD_DESCRIPTION message as well, forgot that bit.

@hamishwillee i was about to add this but is this not just what the COMPONENT_METADATA would have, i might be misunderstanding, i can add similar fields ie a crc32 and 100char uri field to the description message but why can't we just re-use the component_metadata message in that case?

[hamishwillee]

@thomas-watters-skydio

I think for now let's forget the URL - it could be added as an extension or to component metadata.

Your logic for having both a command and a message makes sense.

You're right - I might well be surprised about the demand. I think once there is an implementation in QGC and perhaps in PX4 or ArduPilot then this could well take off. It's just getting to that point.

In any case this is far enough along to get feedback - which I will do when I'm on this work again next week. Thanks!

[dakejahl]

I did read through this once but have refrained from commenting. I haven't read through it thoroughly enough to fully understand the details. But in general I agree with the motivation. We need a way to dynamically render UI in the ground station for payloads. I would love to see an example in QGC/PX4 to check it out. Ideally we could create something in SITL for it.

[hamishwillee]

How would I provide metadata to represent a bitmask or the allowed values of an enum?

[hamishwillee]

@thomas-watters-skydio Can you comment on this?

[thomas-watters-skydio]

I don't have a great solution for this. I would assume it would need to be communicated apriori in some way alongside the attachment or through a component metadata service. Open to ideas for it, this was only added to support further configuration functions currently seen in other micro services.

[hamishwillee]

@dakejahl Thanks for the feedback.

• The design is sensible with respect to deconstructing all the functions you might want to set or discover feedback from a particular hardware. The caveat is that it is not lightweight since every function/status essentially represents one field.
• I am also not sure how it provides metadata for each bit in a bitmask.

We need a way to dynamically render UI in the ground station for payloads. I would love to see an example in QGC/PX4 to check it out. Ideally we could create something in SITL for it.

The UI could dynamically render a "generic" UI fairly simply as we have a name for the payload and each of its functions, we know how many functions there are, and their order, type, and units, and ditto for status.

Upshot is that you could relatively easily generate a UI for displaying each function alongside the setter function in a 2 column grid. [I'm not sure yet how the metadata for an enum or bitmask is provided].

My concern is much like yours. While this is tested internally by skydio, it doesn't sound like they have end to end testing integration with a GCS, missions etc. To test it fully and accept it into common we really need an implementation of both ends. ideally a MAVSDK server plugin on one side with a test implementation and on the other side a QGC UI.

@thomas-watters-skydio I guess you're not going to be able to provide either of those?

[thomas-watters-skydio]

@dakejahl Thanks for the feedback.

• The design is sensible with respect to deconstructing all the functions you might want to set or discover feedback from a particular hardware. The caveat is that it is not lightweight since every function/status essentially represents one field.

• I am also not sure how it provides metadata for each bit in a bitmask.

We need a way to dynamically render UI in the ground station for payloads. I would love to see an example in QGC/PX4 to check it out. Ideally we could create something in SITL for it.

The UI could dynamically render a "generic" UI fairly simply as we have a name for the payload and each of its functions, we know how many functions there are, and their order, type, and units, and ditto for status.

Upshot is that you could relatively easily generate a UI for displaying each function alongside the setter function in a 2 column grid. [I'm not sure yet how the metadata for an enum or bitmask is provided].

My concern is much like yours. While this is tested internally by skydio, it doesn't sound like they have end to end testing integration with a GCS, missions etc. To test it fully and accept it into common we really need an implementation of both ends. ideally a MAVSDK server plugin on one side with a test implementation and on the other side a QGC UI.

@thomas-watters-skydio I guess you're not going to be able to provide either of those?

We may eventually integrate it into UAS Tool, but no plans to integrate into QGC or MAVSDK. We support optimizing the protocol to work with these aswell though and are open to advice.

Our integration will be to support this protocol as a vehicle-payload communication, but we will be translating within our vehicle to be consumed by our first party GCS.

[julianoes]

but no plans to integrate into QGC or MAVSDK

You can consider sponsoring me to get it into MAVSDK.

[hamishwillee]

Perhaps add "if specified, it should define all the information in all the metadata. " The metadata messages would therefore not be needed and should not be emitted" ?

We should define the JSON for this.

[thomas-watters-skydio]

i'm not sure we should stop emitting the protocol messages if the metadata_uri exists. it could be possible that a consumer of the protocol doesn't know how to consume metadata or can't

[hamishwillee]

The bitmask and enum information obviously is trivially easy with metadata. The only way I can see to do this in messages is to send a message for metadata about a function type. This needs strings for each bit or enum values. Given the possible size of strings, probably do this in groups of 8. It could be quite efficient - you can know how many there will be and you only need to request that many and once for each service.

The message would use a value_index to allow for bits/values greater than 8. Strings still very limited.
Thoughts?

GENERIC_PAYLOAD_FUNCTION_VALUE_METADATA_DESCRIPTION (Message ID: TBD)

Generic payload for describing the values of functions that are of DISCRETE (enum) or bit type, sent on request with MAV_CMD_REQUEST_MESSAGE. The value index allows you to specify that this is the 0th, 1st, etc byte in the function, or for the 9th, 17th or so on enum value, and so on.
This does limit the descriptions. We might in theory allow some to be smaller and some larger, but it complicates things.

Field Name	Type	Min	Description
payload_id	uint8_t	1	Component ID of the generic payload.
index	uint16_t	1	Index of this function on the generic payload.
value_index	uint8_t	1	Index the first byte or value.
item 1	char[31]		Name of the item for UI display. NULL-terminated string.
item 2	char[31]		Name of the item for UI display. NULL-terminated string.
item 3	char[31]		Name of the item for UI display. NULL-terminated string.
item 4	char[31]		Name of the item for UI display. NULL-terminated string.
item 5	char[31]		Name of the item for UI display. NULL-terminated string.
item 6	char[31]		Name of the item for UI display. NULL-terminated string.
item 7	char[31]		Name of the item for UI display. NULL-terminated string.
item 8	char[31]		Name of the item for UI display. NULL-terminated string.

[thomas-watters-skydio]

yeah this would be a very verbose way to give names to the bitmasks/enumerations, i think we can leave this to the metadata

[hamishwillee]

Yeah, but once you go down requiring support for metadata you might as well say all of the description should be in metadata.

[hamishwillee]

but no plans to integrate into QGC or MAVSDK

You can consider sponsoring me to get it into MAVSDK.

This would certainly make it easier to validate and test. Something to consider if their is budget @thomas-watters-skydio . For this to be successful we really need the GCS side to already be solid, and to test that we need some way to drive the GCS. A MAVSDK server plugin is quite a good tool for that, because others can come along and write their own companion implementations for their own hardware more trivially.

[hamishwillee]

I started looking at how you would do this using component metadata for the MAV_CMD_DO_WINCH and associated telemetry. By no means complete, but started as below.

The command has a number of operations you can do, which are defined by a value set in actions. That would be one mapped function.

Have the MAV_CMD also allows you to set the line length and rate for that command.
My assumption is that you would map this as three commands, one each for setting the lenght and rate and the other for doing the action.

1. Does that make sense? (Its the same for when using the messages.
2. This isn't really doing an action - its just setting a value. Can you show me how you would do setting the line length?

{
  "generic_device_protocol": [
    {
      "payload_id": 1,
      "name": "Winch",
      "vendor": "Generic",
      "model": "AutoWinch-1000",
      "serial_number": "WNCH0001",
      "software_version": "1.0.0",
      "hardware_version": "1.0",
      "mass": 1200,
      "torque_arm": { "x": 0, "y": 0, "z": 50 },
      "description": "Autonomous winch payload capable of deploying and retrieving tethered loads.",

      "functions": [
        {
          "id": 1,
          "name": "Action",
          "type": "GENERIC_PAYLOAD_FUNCTION_TYPE_DISCRETE",
          "enabled": 1,
          "value_type": "GENERIC_PAYLOAD_VALUE_TYPE_UINT32",
          "min": 0,
          "max": 7,
          "control_modes": ["GENERIC_PAYLOAD_SUPPORTS_MOMENTARY"],
          "timeout_ms": 100,
          "units": "enum:WINCH_ACTIONS",
          "description": "Perform a winch action defined by WINCH_ACTIONS (e.g., RELAXED, RETRACT, HOLD, etc.)."
        },
        {
          "id": 2,
          "name": "Set Line Length",
          "type": "GENERIC_PAYLOAD_FUNCTION_TYPE_DISCRETE",
          "enabled": 1,
          "value_type": "GENERIC_PAYLOAD_VALUE_TYPE_REAL32",
          "min": 0.0,
          "max": 50.0,
          "control_modes": ["GENERIC_PAYLOAD_SUPPORTS_LATCHING"],
          "timeout_ms": 0,
          "units": "m",
          "description": "Sets the target line length (negative not allowed)."
        },
        {
          "id": 3,
          "name": "Set Line Rate",
          "type": "GENERIC_PAYLOAD_FUNCTION_TYPE_DISCRETE",
          "enabled": 1,
          "value_type": "GENERIC_PAYLOAD_VALUE_TYPE_REAL32",
          "min": -2.0,
          "max": 2.0,
          "control_modes": ["GENERIC_PAYLOAD_SUPPORTS_LATCHING"],
          "timeout_ms": 0,
          "units": "m/s",
          "description": "Sets the target cable rate (positive to release, negative to retract)."
        }
      ],

      "telemetry_channels": [
        {
          "channel_id": 1,
          "name": "Cable Length",
          "value_type": "GENERIC_PAYLOAD_VALUE_TYPE_REAL32",
          "update_rate": 5,
          "min": 0,
          "max": 50,
          "units": "m",
          "description": "Cable length deployed, derived from WHEEL_DISTANCE.distance."
        },
        {
          "channel_id": 2,
          "name": "Cable Speed",
          "value_type": "GENERIC_PAYLOAD_VALUE_TYPE_REAL32",
          "update_rate": 5,
          "min": -2,
          "max": 2,
          "units": "m/s",
          "description": "Winch cable rate of movement."
        },
        {
          "channel_id": 3,
          "name": "Tension",
          "value_type": "GENERIC_PAYLOAD_VALUE_TYPE_REAL32",
          "update_rate": 5,
          "min": 0,
          "max": 1000,
          "units": "N",
          "description": "Current measured cable tension from WINCH_STATUS.tension."
        },
        {
          "channel_id": 4,
          "name": "Voltage",
          "value_type": "GENERIC_PAYLOAD_VALUE_TYPE_REAL32",
          "update_rate": 1,
          "min": 0,
          "max": 30,
          "units": "V",
          "description": "Motor or system voltage from WINCH_STATUS.voltage."
        },
        {
          "channel_id": 5,
          "name": "Current",
          "value_type": "GENERIC_PAYLOAD_VALUE_TYPE_REAL32",
          "update_rate": 1,
          "min": 0,
          "max": 50,
          "units": "A",
          "description": "Motor current draw from WINCH_STATUS.current."
        },
        {
          "channel_id": 6,
          "name": "Temperature",
          "value_type": "GENERIC_PAYLOAD_VALUE_TYPE_REAL32",
          "update_rate": 1,
          "min": -40,
          "max": 125,
          "units": "°C",
          "description": "Motor or drum temperature from WINCH_STATUS.temperature."
        },
        {
          "channel_id": 7,
          "name": "Status Flags",
          "value_type": "GENERIC_PAYLOAD_VALUE_TYPE_BITMASK_32",
          "update_rate": 1,
          "min": 0,
          "max": 8192,
          "description": "Bitmask from WINCH_STATUS.status_flags indicating winch operational state.",
          "allowed_values": [
            { "value": 1, "name": "MAV_WINCH_STATUS_HEALTHY", "description": "Winch is healthy." },
            { "value": 2, "name": "MAV_WINCH_STATUS_FULLY_RETRACTED", "description": "Winch line is fully retracted." },
            { "value": 4, "name": "MAV_WINCH_STATUS_MOVING", "description": "Winch motor is moving." },
            { "value": 8, "name": "MAV_WINCH_STATUS_CLUTCH_ENGAGED", "description": "Clutch engaged, allowing motor to move freely." },
            { "value": 16, "name": "MAV_WINCH_STATUS_LOCKED", "description": "Winch is locked by the locking mechanism." },
            { "value": 32, "name": "MAV_WINCH_STATUS_DROPPING", "description": "Winch is gravity dropping payload." },
            { "value": 64, "name": "MAV_WINCH_STATUS_ARRESTING", "description": "Winch is arresting payload descent." },
            { "value": 128, "name": "MAV_WINCH_STATUS_GROUND_SENSE", "description": "Using torque to sense ground." },
            { "value": 256, "name": "MAV_WINCH_STATUS_RETRACTING", "description": "Returning to fully retracted position." },
            { "value": 512, "name": "MAV_WINCH_STATUS_REDELIVER", "description": "Redelivering payload (failover if tension threshold exceeded)." },
            { "value": 1024, "name": "MAV_WINCH_STATUS_ABANDON_LINE", "description": "Abandoning line/payload (failover from REDELIVER)." },
            { "value": 2048, "name": "MAV_WINCH_STATUS_LOCKING", "description": "Engaging the locking mechanism." },
            { "value": 4096, "name": "MAV_WINCH_STATUS_LOAD_LINE", "description": "Spooling on line." },
            { "value": 8192, "name": "MAV_WINCH_STATUS_LOAD_PAYLOAD", "description": "Loading a payload." }
          ]
        }
      ]
    }
  ]
}

[thomas-watters-skydio]

what you have makes sense, so i need to come up with a schema that allows you to communicate the generic_payload_protocol in its entirey?

This isn't really doing an action - its just setting a value. Can you show me how you would do setting the line length?

I don't really follow, i think how you described it is correct, settings would have to map to a "function"

[hamishwillee]

so i need to come up with a schema that allows you to communicate the generic_payload_protocol in its entirey?

FWIW I think this protocol makes way more sense as component metadata except in one respect: ArduPilot do not yet implement the concept.
In one sense though that doesn't matter; for this to work all that is really needed is that the component exposing the data is able to share the file via mavftp. If the data is static then it can be added to the firmware at build time.
The recipient has to understand the data format, of course, but QGC already supports the protocol (MISSION planner does not, but this might force it to).

That said, the answer to your question is not that you have to do anything - but it would be useful. The reason I did this was to test the feasibility once I ran into the fact that you can't document flags or enum values using the current approach.

This isn't really doing an action - its just setting a value. Can you show me how you would do setting the line length?
I don't really follow, i think how you described it is correct, settings would have to map to a "function"

Thanks. I just wanted to check that in order to emulate current winch functionality you would need to break this into three functions. If one of those functions is setting a parameter then you would also need to implement the setting parameter as a function, and presumably that function would be associated with the particular device instance.

This makes things a bit complicated for the user because it isn't obvious that deploying a winch is a matter of setting the line length, the action, the rate, This would be presented to them as a flat list of functions, which wouldn't necessarily be ordered.

W.r.t. the format above, I was just looking at the data at this point. But as a next stage we might look at formatting how the data is presented as part of the syntax.
For example, it might be possible to indicate that the three functions are grouped, and that they should be executed as such or rendered differently because of that. It might be possible to decide that some functions depend on other values, and so on.

The upshot is that I feel we really need implementations to test this in the UI to know what will work. It is all a bit abstract right now.

[thomas-watters-skydio]

@hamishwillee Can you summarize what action items you are expecting me to address still as part of this rfc?

I consider the metadata to be a separate component and not sure it belongs as part of this rfc, but if i need to do it to push this rfc forward then i can take a look further.

Is that it?

[hamishwillee]

@hamishwillee Can you summarize what action items you are expecting me to address still as part of this rfc?

What I would hope for:

• Addition of message for flag/enum metadata to the RFC doc itself.
• Summary of any explicit omissions and limitations, which might include omission of that message for flag/enum metadata. It might also note the UI limitations - stuff like the fact that some things that might be grouped as one command normally have to be send as multiple functions - like the winch command.
• Component metadata is not a requirement unless you want to use that for the flag/enum metadata. In that case I'd recommend you defined the full metadata in version 1 format and explain how you'd expect systems to work if they do/don't support metadata.

At that point we'd have a reasonable finished proposal. The next step would be on me to get an explicit statement from flight stacks about what they would need accept this.
We don't move things into development.xml, and then on to common.xml unless it is in a flight stack and there is interest in supporting it in at least one other (or at least stated "if we wanted this feature we would implement it this way).

NOTE, I am not confident of getting approval to move this forward as part of the standard.
The idea looks good, but initial feedback is that without a plan for validation that covers both autopilot and GCS ends it is unlikely to be accepted.

Mostly because it is hard to envisage how the GCS UI might work - and it will be hard to validate any flaws in our thinking without a prototype like the winch case. Last of all, it is easy to see adoption if it were in the GCS and a MAVSDK server plugin or flight stack, but hard to see otherwise.
Normally to progress something like this we'd have a stakeholder that was already planning to add to QGC and either PX4 or ArduPilot (a MAVSDK server plugin and QGC would do).

Hope that makes sense?

[thomas-watters-skydio]

Thank you for the feedback and for your support throughout this process. I’ll communicate these concerns in regards to integration into a GCS/Flight Stack internally. Unfortunately as mentioned we are mostly considering this as a Vehicle<->Payload interface which may be a new concept to MAVLink.

[hamishwillee]

Thanks. I'd love to say "just make it so", but all of this is a compromise between communities.