Add support for Volz on AP_Periph

[peterbarker]

Based on #29040

Adds an autotest which tests Volz-on-periph

• creates a separate AP_Periph build with relevant support compiled in
• creates a custom Plane build with appropriate options compiled in
• starts the simulations

The Periph firmware receives data via ArrayCommand.

The main Plane firmware receives telemetry data back from the peripheral via com_volz_servo_ActuatorStatus

At the moment there's no connection of the desired value sent by the autopilot and the achieved angle returned by the periph (and logged into CSRV. There's no facility in the return packet for the desired value.

[IamPete1]

I do have a branch for this somewhere, I did it in a similar way as you have sending the volz DroneCAN packet. Now we have the servo telem lib I wonder if we should do it using the standard DroneCAN packet. I think as you have it it doesn't actually have to be a volz servo that is reported because it is reading out of the servo telem lib (of course we might need to add support for other servo types on periph to populate that).

That is to say, should we split that addition of the volz support and then the reporting of servo telem such that they can be used independently.

[peterbarker]

That is to say, should we split that addition of the volz support and then the reporting of servo telem such that they can be used independently.

Yeah, I haven't split the commits in here to allow that, but did write things with an eye to allow for differently-attached servos. OTOH, I did choose to send back the volz feedback message rather than the generic feedback message here to get the extra fields (which I think is probably a mistake, and both packets are... not good).

There's several big holes here, the most notable being logging on the main flight controller for the serially-attached servos on the peripheral. You can't sensibly log anything in the CSRV[x].PosCmd field for the data coming back from the peripheral! I think we need a companion for the uavcan_equipment_actuator_ArrayCommand message, perhaps uavcan_equipment_actuator_ArrayResponse which we can use to properly populate CSRV

(as an aside, it would nice to rename PosCmd to DesPos to match other messages ;-) )

[IamPete1]

Its interesting the three DroneCAN reporting messages we support all have different data. Its also worth noting that now were going into the servo telem lib on the vehicle side we do loose some information from volz anyway. We could send back the secondary voltage and current for example, but its not implemented in the servo telem lib (we did log it for local servos prior to the merging of libs).

Out of the three the harmark one if probably the nicest, there is no reason we couldn't use it rather than the standard one I guess...