Add support for actuator control via DO_SET_ACTUATOR

[coderkalyan]

Describe problem solved by this pull request
Implements MAV_CMD_DO_SET_SERVO

Describe your solution
The DO_SET_SERVO pwm value is normalized and fed written to a control group. There are 2 control groups allowed, set by the MAV_SET_SRV_GRP enum parameter. When in 0/RC mode (default), only 1, 2, or 3 are allowed for the instance number. This is mapped to RC aux 1, 2, and 3 on control group 3. When in 1/Payload mode, values from 1 - 8 are allowed, and are mapped to control group 6. Note that this requires a mixer for control group 6 to be defined prior to use.

Describe possible alternatives
This is still sort of hacky; I'm only implementing it because it's a simple solution for most people wanting to control a random actuator, and this feature has been requested many times. Use case-specific messages and control groups are preferred.

Test data / coverage
Unfortunately the only testing I was able to do was spin up SITL and do some logging. It seems to be working fine, and the values/calculations are all correc when I send MAV_CMD_DO_SET_SERVO, but I haven't tested on an actual drone to see if the servo value gets set. Unfortunately my only flight controller is currently in use; I will try to acquire a spare and test it in real life. If someone else could do this as well, that would be appreciated.

Additional context
Quick and dirty pymavlink script for testing:

from pymavlink import mavutil

conn = mavutil.mavlink_connection('udp:localhost:14552')
conn.wait_heartbeat()

conn.mav.command_long_send(
   conn.target_system, conn.target_component,
   mavutil.mavlink.MAV_CMD_DO_SET_SERVO, 0,
   1, 1700, 0, 0, 0, 0, 0) # replace 1 with the servo instance, and 1700 with the desired PWM

This PR builds on #10320. Also related mavlink/mavlink#1414 for reference.

[dayjaby]

This PR conflicts with #14809

[coderkalyan]

Update: both DO_SET_SERVO and DO_SET_ACTUATOR work (in theory). Still need to add logic to deconflict with RC. I just did extensive logging with SITL; if someone who has a spare FC that they can flash master onto could test this, that would be great!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.

[coderkalyan]

Whoops, was looking through my open PRs and realized that this never got finished! Reminder to myself to rebase this and clean it up, as well as test.

[hamishwillee]

What's this stalled on?

[coderkalyan]

@hamishwillee nothing really, when I wrote this I didn't have any spare testing hardware but now I do is it's just a matter of sitting down for a couple of hours and testing the rc and mavlink deconfliction logic on a real autopilot. Also needs to be rebased and I think the deconfliction logic needs to be updated

[jinger26]

@coderkalyan what testing hardware you are using?

[coderkalyan]

@jinger26 I usually bench test on our cuav v5+, I also have a pixhawk 4. Once the code is proved to work reliably I can try it out on our drone with a Nora autopilot but this is a relatively simple PR so not that much testing should be necessary.

[jinger26]

@bkueng could you help with review?

[coderkalyan]

That would be great, but I'd recommend waiting on a review until I finish testing and updating the deconfliction. Don't want to waste anyone's time :)

[coderkalyan]

Update: on @bkueng 's advice on slack, I'm going to ignore this PR and start fresh. Will link the new PR when I create it.

[coderkalyan]

Superseded by #16758.