Add support for generic payloads

[vivian-zhou-skydio]

• Add MAV_CMD_GENERIC_PAYLOAD_FUNCTIONS_CONTROL, GENERIC_PAYLOAD_STATUS,GENERIC_PAYLOAD_FUNCTION_STATUS, and GENERIC_PAYLOAD_ERROR_FLAGS to development.xml

GENERIC_PAYLOAD_STATUS is the status for the generic payload, and GENERIC_PAYLOAD_FUNCTION_STATUS is the status for individual function(s) of the generic payload that can be controlled via MAV_CMD_GENERIC_PAYLOAD_FUNCTIONS_CONTROL.
MAV_CMD_GENERIC_PAYLOAD_FUNCTIONS_CONTROL is used to control payload functions. It can be used for simple control such as ON/OFF of a flashlight. It can also be used to control multiple functions of a component such as arm/disarm and deployment of a parachute.

Topic: generic_payload

[vivian-zhou-skydio]

Reviews in this chain:
└#3 Add support for generic payloads

[vivian-zhou-skydio]

#	head	base	diff	date	summary
0	112e1ab4	01e0cc2f	diff	Nov 15 17:32 PM	1 file changed, 10 insertions(+)
1	91451e44	01e0cc2f	diff	Nov 19 13:53 PM	1 file changed, 20 insertions(+), 2 deletions(-)
2	c5f7ed27	01e0cc2f	diff	Dec 18 14:22 PM	1 file changed, 10 insertions(+), 9 deletions(-)
3	7b83b105	01e0cc2f	diff	Dec 19 14:15 PM	1 file changed, 10 insertions(+), 2 deletions(-)

[amy-chen-skydio]

lgtm!

[tal-zaitsev-skydio]

"If it is exactly 32 characters long, add a terminating NULL" is confusing. imo it's clearer to say something like "stores null terminated string if less than 32 characters, or 32 characters without null termination." Similarly to the language used elsewhere in this file

[amy-chen-skydio]

I think this was copied from existing example STORAGE_TYPE enum

[thomas-watters-skydio]

Textual storage name to be used in UI (microSD 1, Internal Memory, etc.) This is a NULL terminated string. If it is exactly 32 characters long, add a terminating NULL. If this string is empty, the generic type is shown to the user.

from STORAGE_INFORMATION

it is a bit weirdly worded though. because it sounds like they want 33bytes for a string that is exactly 32chars long.. but that would not work in the packing. unless oddly the packing doesn't check the length but simply looks for a null character, and then verifies the length afterwards

[tal-zaitsev-skydio]

Should there also be a maxValue of 65535? function_count is a uint16_t

[amy-chen-skydio]

Good point! Parameters are sent as float and could have a value bigger than 65535

[tal-zaitsev-skydio]

Do we need this in both messages?

[thomas-watters-skydio]

@vivian-zhou-skydio what was the reasoning here, i feel like I had convinced myself it was useful

[tal-zaitsev-skydio]

Is this expected to change dynamically for things like droppers? If not, should this then reflect the max weight of the payload?

[thomas-watters-skydio]

Suggested change

	<description>Generic payload function status.</description>
	<description>Generic payload function status. Use [MAV_CMD_REQUEST_MESSAGE](https://mavlink.io/en/messages/common.html#MAV_CMD_REQUEST_MESSAGE).param2 to indicate the index/id of requested function: 0 for all, 1 for first, 2 for second, etc.</description>

[thomas-watters-skydio]

Suggested change

	<param index="2" label="Enable" minValue="0" maxValue="1" increment="1">0: Disable, 1: Enable</param>
	<param index="2" label="Activate" minValue="0" maxValue="1" increment="1">0: Disable, 1: Activate</param>

[thomas-watters-skydio]

I wonder if there's reason to expand this to include something that specifies the control scheme ie :

enum ControlSchemeFlags {
  LATCHING = 1,
  NON_LATCHING = 2,
  BINARY = 4, 
  ANALOG = 8, 
  PWM = 16,
};

The non-latching idea was motivated by the dropper needing to "reset" after actuation. However in this case the current UI only sends on USER_ACTION to deploy, not reset. (Could be updated to send RESET maybe).

But non-latching would still be interpreted by attachment, ie it could latch for a time period, then reset on its own (in the case of the dropper), or it fires and resets immediately (one shot gpio0 on/off)