Add support for multi-GCS operation #29252
Conversation
Absolutely - I do this all the time |
No, you need to change The reason is that this information isn't just for other GCS. It is for components of the system to know what the system in charge is. If you don't set this to 0 then they will refuse commands from anything other than the GCS that used to be in control. |
FWIW My intent with this protocol was that parameter and mission data from a controlled system should be available to all GCS, in the same way as telemetry. However a controlled GCS should only accept a mission upload from its controlling GCS. The protocol wording is something like "a controlled component/system should only accept commands and command-like messages from its controller" so we should perhaps clarify that broadly speaking telemetry and metadata are expected to be available to all GCS. |
|
Thanks for the comments @hamishwillee. I would like to get the Ok from some of the AP dev team before proceeding with the changes. @rmackay9, could you take a look at this one? Thanks! |
This PR adds support for the recently added multi-GCS mavlink subprotocol mavlink/mavlink#2158. This allows graceful change in control ownership on a system with multiple GCS. Please note this subprotocol does not attempt to cover security, it assumes all the operators are in contact between them and they work in a collaborative manner.
For more information about the protocol itself, please read that mavlink thread instead, and also please take a look at the corresponding QGroundControl PR here mavlink/qgroundcontrol#12410. I am also attaching a short video showing how this was tested in SITL:
multi-GCS-demo-2025-02-08_17.12.46.mp4
How the implementation works
GCS UI is populated based on CONTROL_STATUS being received. For single GCS operations, it is probably desirable to not show such UI, and not send that message at all. For that reason I left the evaluation to send this message or not at initialization, based on SYSID_ENFORCE parameter. If set to 0 at boot up, this message won't be sent at all, and no UI will be populated.
When the current GCS in control releases control, it only sets takeover allowed to true, but does not change sysid_mygcs. Mavlink protocol says we should use 0, no one in control, but maybe this is too hardcore at the moment, until we are sure all of this makes total sense. So the current solution of setting takeover allowed to true from my point of view is a balance. Let me know your thoughts.
As it is now it will assume all the GCS are connected to the same link. Is it worth implementing something so this can work between different links? for example a GCS connected on serialport x to a 900MHz radio telemetry and another GCS possibly connected to a different serial port to a serial to ethernet converter and a digital Ip link.
On link loss, when we stop seing heartbeats from the GCS in control, we set the allow override, so other GCS can take over automatically.
Right now, when a GCS that is not our SYSID_MYGCS sends a command it just ignores the command, so the GCS ack mechanism times out and we see a "no response" message. When we were working on this at the mavlink level, @hamishwillee suggested the use of a new MAV_RESULT_PERMISSION_DENIED, but in the end we ditched it due to the extra complexity. Maybe we should come back to this later if this concept works, to make more user friendly when a GCS not in control is exchanging messages with the vehicle.
In any case, I don't think this one in particular is too bad at the moment.
As we are basing this on sysid_enforce, when a GCS is not in control it will have trouble to download the mission and parameters. Maybe we should allow parameters and mission to be sent to GCS that are not in control?
Notes
We need this mavlink changes ArduPilot/mavlink#382 for this PR to build
Pending work to do
For awareness @rmackay9