This service defintion has been superseded by Gimbal Protocol v2 (gimbal manufacturers/GCSs/autopilots are expected to use the new API, but the old API is still in broad use, and there is no plan to for it to be removed).
The gimbal configuration message set uses a number of commands and few special-purpose messages to configure a payload mount.
By default the gimbal should be communicating with the component ID MAV_COMP_ID_GIMBAL.
Another possible control command would be MAV_CMD_DO_MOUNT_CONTROL_QUAT. This command does not seem to be implemented by any systems at time of writing.
To reboot or shut down a gimbal send the command MAV_CMD_PREFLIGHT_REBOOT_SHUTDOWN. The options to be set for the gimbal are found in
This is the same message/process as for autopilot systems.
A gimbal (or mount) should send a HEARTBEAT (e.g. every second) just like any other MAVLink component. Additionally, it can send feedback about the angles it's pointing using the message MOUNT_ORIENTATION.
This version of the gimbal protocol (v1) has a number of known issues:
- Unspecified signs in
- Confusing order of axes in
- Unclear “stabilize” flags in
- Confusing and unimplemented “absolute” flags in
- Unclear when to use
- Too many overloaded params in DO_MOUNT_CONTROL depending on GPS or targetting.
- Unusual param number for
- The GPS mode in
- MOUNT naming makes discovery hard.
- Confusion and conflicts between gimbal commands used between ground station and gimbal messages between autopilot and gimbal.
- Commands require acknowledgements back and are therefore not suitable for higher rate setpoint streams for manual control.
- Control conflicts between different sources. It is not clear what takes precedence and how the deconfliction between different sources and commands should be implemented.
If possible migrate to Gimbal Protocol v2 which addresses these issues.