AP_Mount: Add delta_yaw and delta_yaw_velocity support for AP_Mount_MAVLink

[jnomikos]

Summary

Added delta_yaw and delta_yaw_velocity support in AP_Mount and added an AP_Mount_MAVLink implementation, for GIMBAL_DEVICE_ATTITUDE_STATUS.

Classification & Testing (check all that apply and add your own)

• Checked by a human programmer
• Non-functional change
• No-binary change
• Infrastructure change (e.g. unit tests, helper scripts)
• Automated test(s) verify changes (e.g. unit test, autotest)
• Tested manually, description below (e.g. SITL)
• Tested on hardware
• Logs attached
• Logs available on request

Tested on cube blue with Gremsy Pixy LR payload (v7.8.7) (with ArduCopter).

Description

1. Added get_attitude_deltas to AP_Mount.h and AP_Mount_Backend.h
2. In send_gimbal_device_attitude_status, if we are able to get_attitude_deltas, attach it as part of the MAVLink message.
3. Added AP_Mount_MAVLink implementation of get_attitude_deltas. Only true if we ever receive a non-zero value for either of them (indicating the gimbal sends the extended value).

Rationale: A gimbal device maintains its own yaw estimate, which can differ from the vehicle's heading. The difference may be small (separate compass with different calibration) or arbitrarily large (some gimbals reference yaw to an arbitrary zero, such as their power-on direction, rather than to north). Some gimbals, such as the Gremsy Pixy LR, report their attitude quaternion in vehicle frame in both follow and lock modes (GIMBAL_DEVICE_FLAGS_YAW_IN_VEHICLE_FRAME), so a consumer must always add a vehicle heading to compute the gimbal's earth-frame azimuth.

ArduPilot currently always sends NaN for delta_yaw and delta_yaw_velocity in GIMBAL_DEVICE_ATTITUDE_STATUS, even when the gimbal reports them. A GCS therefore has to either use the autopilot's vehicle heading, which is offset from the gimbal's own estimate, or bypass the gimbal manager and listen for GIMBAL_DEVICE_ATTITUDE_STATUS directly from the gimbal device's component, contrary to the intent of the gimbal protocol v2, and impossible when the gimbal is not visible on the GCS link. The offset produces real failures: on the Pixy LR, switching from follow to lock commands an azimuth computed from vehicle heading, which the gimbal executes against its own heading estimate, so the gimbal visibly slews by the difference (in testing, sometimes more than 180 degrees, with the size of the error depending on vehicle heading).

delta_yaw exists in the spec for exactly this: it is the vehicle heading as estimated by the gimbal itself. Converting between body and earth frames with the gimbal's own estimate makes the round trip self-consistent, so the frame offset cancels regardless of its cause or size. With this change, when the gimbal reports delta_yaw, ArduPilot forwards it in GIMBAL_DEVICE_ATTITUDE_STATUS, so a GCS can do that conversion without relying on vehicle heading. Vehicle heading and gimbal attitude also arrive at different rates, so using the gimbal's own value avoids mixing estimates sampled at different times.