AP_Mount: Fix GIMBAL_DEVICE_FLAGS in GIMBAL_DEVICE_ATTITUDE_STATUS

[nexton-winjeel]

This PR fixes two issues with the reported flags in GIMBAL_DEVICE_ATTITUDE_STATUS:

1. GIMBAL_DEVICE_FLAGS_YAW_IN_VEHICLE_FRAME is always set, even if the yaw is locked (i.e. in earth frame); and
2. The Servo backend always reports attitude in body frame, so the GIMBAL_DEVICE_FLAGS_YAW_LOCK and GIMBAL_DEVICE_FLAGS_YAW_IN_EARTH_FRAME flags need to be unset.

FYI: @rmackay9

[nexton-winjeel]

IMPORTANT: The clearing of GIMBAL_DEVICE_FLAGS_ROLL_LOCK and GIMBAL_DEVICE_FLAGS_PITCH_LOCK is only applicable if #27072 is merged.

[nexton-winjeel]

@Davidsastresas: You made the change to set GIMBAL_DEVICE_FLAGS_YAW_IN_VEHICLE_FRAME unconditionally (in f12ca0b). My understanding is that it should only be set if yaw_lock_state is false?

[rmackay9]

Hi @nexton-winjeel,

I think we should always be reporting the gimbal's attitude in body-frame. I think it will be too confusing for the GCSs to have to deal with body-frame sometimes and earth-frame other times.

I think the lock state (which is more of a target or control state) is not directly related to the reporting of the attitude estimate.

[nexton-winjeel]

Thanks @rmackay9. Yes, I agree the reported attitude should be in body frame.

I think the lock state (which is more of a target or control state) is not directly related to the reporting of the attitude estimate.

That doesn't align with the description here: https://mavlink.io/en/messages/common.html#GIMBAL_DEVICE_ATTITUDE_STATUS.

My understanding is that we should prefer GIMBAL_DEVICE_FLAGS_YAW_IN_VEHICLE_FRAME and GIMBAL_DEVICE_FLAGS_YAW_IN_EARTH_FRAME. However, these are new and might not be supported, so we should also fall back to setting the GIMBAL_DEVICE_FLAGS_*_LOCK flags as well.

[nexton-winjeel]

I'm going to close this, because it's not correct as-is.

However, we might need another PR to align the GIMBAL_DEVICE_FLAGS_*_LOCK flags with the MAVLink message description here: https://mavlink.io/en/messages/common.html#GIMBAL_DEVICE_ATTITUDE_STATUS.

[Davidsastresas]

Hello @nexton-winjeel, thanks for catching my attention. This matter with flags on gimbal is confusing, back at the time when we did the QGC implementation we also got confused for a while. Please see here:
https://mavlink.io/en/services/gimbal_v2.html#how-to-interpret-gimbaldeviceattitudestatus-yaw-gimbal-angle

So the recommended use is always for new systems:
GIMBAL_DEVICE_FLAGS_YAW_IN_VEHICLE_FRAME
GIMBAL_DEVICE_FLAGS_YAW_IN_EARTH_FRAME

But consumers ( mainly GCS ) need to also have support for GIMBAL_DEVICE_FLAGS_YAW_LOCK, as some older systems use it to indicate yaw frame too, if the above flags are not used.

As far as I remember, Ardupilot always deal with gimbal angles in vehicle frame, that is why I left GIMBAL_DEVICE_FLAGS_YAW_IN_VEHICLE_FRAME permanently set. This works perfectly fine and should be gimbal manager v2 compliant.

Then, in order to indicate if yaw is locked or not, we can just use GIMBAL_DEVICE_FLAGS_YAW_LOCK. If we have the 2 flags mentioned above to just indicate the frame reference, this flag will exclusively indicate yaw lock state.

Considering that, I think as it is now ( at least as it was the last time I looked at it a few weeks back ), it should be compliant and functional.

But I might be wrong, if it doesn't make sense to you let me know and I will look at it again.

Thanks!