common.xml: deprecate MAV_CMD_SET_PARAMETER

[peterbarker]

I don't think anybody actually implements this.
ArduPilot doesn't.
PX4 doesn't seem to.
QGC doesn't seem to
MissionPlanner doesn't.
MAVProxy doesn't

[hamishwillee]

PX4 definitely doesn't, so it is unlikely that QGC does. This has previously however been some interest in doing so PX4/PX4-Autopilot#18957, but as noted by Daniel Agar:

I've been experimenting with making PX4 parameters fully accessible to ROS2, but I'm not sure when I'll be able to finish it.

Much more immediately we could probably implement MAV_CMD_DO_SET_PARAMETER if you think it's important. I find that interface quite awkward because you need to separately determine the parameter number and then the parameter value type is a mess, but I suppose it's better than nothing.

My thinking on this is that it is a lot like https://mavlink.io/en/messages/common.html#MAV_CMD_USER_1 or https://mavlink.io/en/messages/common.html#MAV_CMD_DO_SET_ACTUATOR - a wrapper around something that MAVLink doesn't want to standardize. I see that they are hard to use, because you don't know the parameter number/type meaning at this level - it is entirely up to the flight stack.

BUT, I can see that as a GCS you could use this "usefully" because at least for PX4 you can get the parameter metadata dynamically, and provide both docs and correct type info from that.

I also saw a use with camera definition stuff, which relies on parameters. With this, you could set a particular parameter in missions if you wanted, when there is no other way to do so. For example, I could use this to set the active IR vs Visible light sensor if that is exposed as a parameter.

On the other hand, if no one has implemented this, then working to shrink the standard set makes sense. If we had a true standard set though I'd be happy to have this in common.

@julianoes Got an opinion. I'll add to MAV call.

[julianoes]

For completion, MAVSDK doesn't use it 😄. I'm happy deprecating it.

[hamishwillee]

OK. I'm reaching out on PX4/PX4-Autopilot#18957 (comment) for comment, and I'd be interested in @auturgy opinion. However the inclination is to deprecate.

[hamishwillee]

We discussed in mav call 20240424. It is definitely "potentially useful" but since no one has implemented it adding deprecation at least indicates to potential users that it is not implemented and hints at an alternative. So we'll deprecate, and potentially remove in future. If someone needs this in the meantime we would be open to reverting.