AP_Mount: use new GIMBAL_DEVICE_CAP_FLAGS_CAN_POINT_LOCATION_GLOBAL

[peterbarker]

Summary

we had a temporary hack in place for the AVT gimbals to use. Replace with the standardised bit

Testing (more checks increases chance of being merged)

• Checked by a human programmer
• Tested in SITL
• Tested on hardware
• Logs attached
• Logs available on request
• Autotest included

Description

We had a temporary hack in place while we got the MAVLink side of things sorted (added in #32162)

We now have the bit thanks to @julianoes work.

@KSimeonAVTA - we now have a bit which can replace the hack. I've put a comment in that we should remove the hack in ArduPilot 4.9, which I'm hoping is plenty of time for the AVT firmware to start to use the bit. Open to debate.

This does actually point an interesting thing out. Assuming the AVT gimbal has its own positioning system (e.g. a GPS), sometimes the gimbal will not be able to point in the global frame (e.g. GPS has no fix) when the vehicle might know where it is and be able to direct the gimbal with angles. How do we represent this? Should the gimbal only report "can point in the global frame" when it can actually do that, or always on the assumption that at some stage it will be able to? ArduPilot will absolutely handle the updating of the gimbal's capabilities, so I would strongly suggest the AVT gimbals not report ability to point to lat/lng/alt until they can do that (e.g. GPS lock). When they get a fix their GIMBAL_DEVICE_INFORMATION message should start to reflect the capability. @hamishwillee @julianoes

I don't currently have the means to test this locally. I'll need to write some simulation stuff for it or something to test here.

[rmackay9]

This looks pretty good to me. We don't need to know whether the capabilities flags are valid or not? We could differentiate based on whether we've received the mavlink message that holds the capability flags or not. Perhaps we have no need to know the difference though between invalid and no capabilities

[peterbarker]

This looks pretty good to me. We don't need to know whether the capabilities flags are valid or not? We could differentiate based on whether we've received the mavlink message that holds the capability flags or not. Perhaps we have no need to know the difference though between invalid and no capabilities

We know the flags are valid if they are non-zero (per the spec). If they are zero then falling back to the original 16-bit field is correct. The bottom 16-bits in the new field must have the same value of the old field (by spec).

[KSimeonAVTA]

@peterbarker I have tested this PR changes with the temporary hack removed
and it is working using QGC daily build and AVT gimbal. I can ROI at location and point to home,

[peterbarker]

Needs double-shuffle once the mavlink PR is merged

[peterbarker]

Needs double-shuffle once the mavlink PR is merged

Done

[peterbarker]

Merged this. Thanks for testing, @KSimeonAVTA !