GCS_MAVLink: added MAV_GCS_SYSID_HI

[tridge]

this allows for multiple MAVLink source system IDs to be treated as valid GCS nodes, allowing for multiple ground stations for GCS failsafe handling
In more complex operations with handover between GCS operators or redundant GCS operators this helps ensure each GCS can use its own system ID

[peterbarker]

@Davidsastresas (@hamishwillee) so this PR moves us from treating a single system ID as "my GCS" to allowing a sequential set of IDs to be considered "mygcs".

This is important for our current operations because it means that if tridge's laptop catches fire then the heartbeats from my laptop are sufficient for the vehicle to stay on-mission. At the moment if tridge's laptop goes down then the vehicle will stop receiving heartbeats from SYSID_GCS and will execute its GCS failsafe action.

David's PR adds a protocol for active transfer of control from one GCS to another. That is somewhat at odds with this PR.

I think you can see how in our scenario it is critical that either laptop can act as a source of heartbeats to satisfy the "can see my GCS" aspect of failsafing. Generally we consider either laptop a reasonable source of commands for the vehicle, and we do not need the sort of protocol you're introducing in your PR. However, it wouldn't be right to merge this one without considering whether the workflows you're trying to accomplish with your control-handover PR would be completely incompatible with this PR.

Further complication with the OPERATOR_CONTROL stuff - we absolutely need to trust our companion computer/s but not consider traffic from its system ID(s) to be considered as heartbeats for the purpose of failsafes.

There's the additional complication of what operations are allowed from who while the vehicle is armed / disarmed. So, for example, should a request to download parameters be allowed from a system when the vehicle is disarmed but be denied when it is armed.

This message is now diverging rapidly from @tridge 's change here, but I do want to make sure we're not setting ourselves up to not be able to do something cool in the future.

@Davidsastresas have you written down a "user story" for the "request operator control" protocol somewhere? I gave such a story above for our local operations where having multiple source systems is important!

[timtuxworth]

The multi-GCS protocol and workflow are documented here mavlink/mavlink#2158

Specifically:

A ground station can release control without it being taken over. A drone can decide it has no owner if the original owner is disconnected.

The use case for failure/handover should be accommodated, so it's not clear to me that this PR is a good idea. Can you not make it work using the agreed (and extensively debated) MAVLink protocol that was designed for this situation?

[tridge]

@timtuxworth the proposed protocol doesn't handle the case where you have two active GCS operators at once (like @peterbarker and I frequently do). It forces us to use the same source system on our two GCS, which is an incorrect setup.
If one of our laptops dies while the other is still running we want the aircraft to keep flying without having to send any command to the vehicle. As far as I can see that can't be achieved with the new protocol, but can trivially be done with this PR.

[IamPete1]

Why not use different component IDs on the GCS's and keep the same system ID?

[peterbarker]

@timtuxworth the proposed protocol doesn't handle the case where you have two active GCS operators at once (like @peterbarker and I frequently do). It forces us to use the same source system on our two GCS, which is an incorrect setup. If one of our laptops dies while the other is still running we want the aircraft to keep flying without having to send any command to the vehicle. As far as I can see that can't be achieved with the new protocol, but can trivially be done with this PR.

I don't think I said anything contrary to this. I just want to make sure we don't stuff up the mavlink hand-off protocol by adopting this PR. I think they can somehow be complementary.

[peterbarker]

Why not use different component IDs on the GCS's and keep the same system ID?

We have conjectured that this might work but have not yet tested it.

It's not actually a good idea - MAVProxy may want to spool up components and then you could easily end up with a clash between the two MAVProxys.

I still think it might be useful to know that it does work, but I don't think it's the best way to do things :-)

[timtuxworth]

@timtuxworth the proposed protocol doesn't handle the case where you have two active GCS operators at once (like @peterbarker and I frequently do).

Should you be doing this?

I understood we were moving towards adopting the manned aviation protocol "you have control", "I have control" on the basis that there should only ever be one pilot in command at any one time. What you are doing seems to break this rule and I kind of expect it might become a rule, or at least best practice, from some of the conversations I've been part of here in Canada. The discussion on the MAVlink protocol seems to be based on this principle

So should you have two active GCS at the same time, both able to send commands? Maybe it's pragmatic for what you are doing now, but it's dangerous and IMO it probably shouldn't be possible. One GCS should be in command, the other could be connected and receiving telemetry for display, but it should only be one GCS that has control at any given time.

The only question in my mind is how to make a quick and fairly seamless transition from the primary to secondary GCS if the primary goes down, ideally in less time than the failsafe timeout. Could it not be that when the timeout expires, there are two choices a. switch to a secondary GCS or b. failsafe?

But once primary/control has transitioned to Peter, then when Tridge's laptop comes back up it should be a secondary GCS and not able to send commands, unless/until control is specifically transitioned back.

[tridge]

Should you be doing this?

yes. In our case we're both standing next to each other, two GCS, connected over multiple links. We coordinate by talking to each other, but either of us is able to take an appropriate action as needed

[timtuxworth]

Should you be doing this?

yes. In our case we're both standing next to each other, two GCS, connected over multiple links. We coordinate by talking to each other, but either of us is able to take an appropriate action as needed

You could do this differently. If you are standing next to each other what's wrong with only one person being able to send commands if the other person can always tell/suggest what needs to be done? They are standing right there.

[peterbarker]

Should you be doing this?

yes. In our case we're both standing next to each other, two GCS, connected over multiple links. We coordinate by talking to each other, but either of us is able to take an appropriate action as needed

You could do this differently. If you are standing next to each other what's wrong with only one person being able to send commands if the other person can always tell/suggest what needs to be done? They are standing right there.

They may be working some other aspect of the aircraft at the time - so working on rejigging the mission or whatever.

In fact tridge and I are simplifying the situation a little here - there's at least one more GCS involved, that being the H16 hand controller which runs QGC.

[timtuxworth]

In fact tridge and I are simplifying the situation a little here - there's at least one more GCS involved, that being the H16 hand controller which runs QGC.

I see what you mean, so I'd have to say that it must be an option/parameter whether to allow only 1 or more than one "active" GCS at a time. I'm confident it will be a common requirement to restrict a vehicle to only one GCS (and the option "locked down" so it can't be changed).

[IamPete1]

It's not actually a good idea - MAVProxy may want to spool up components and then you could easily end up with a clash between the two MAVProxys.

Surely system ID clashes are more likely than component ID clashes? Are we just doing this in AP because its not currently possible to set a custom component ID in MAVProxy?

[timtuxworth]

A typical use of multiple GCS might be C2 vs payload. Could the 2nd GCS_ID be allowed only for payload related actions?

[LupusTheCanine]

A typical use of multiple GCS might be C2 vs payload. Could the 2nd GCS_ID be allowed only for payload related actions?

That should be handled by the payload (including ex servo gimbal and other translated gimbal drivers)

[Davidsastresas]

I mostly agree with @timtuxworth. Back at the time @hamishwillee and I spent a ton of time figuring out the protocol. It is basic but I think it could be key and nice to use for operations that require multi GCS.

Answering @peterbarker about the story for this PR, the initial idea was supporting non LOS operations in valley areas, where we could have an operator on each valley and keep transferring control safely.

I also understand your particular requirements for your current scenario, but to be honest it seems really niche. I don't think there is a lot of non dev/experimental operations that would be better with this approach than the "mavlink multi gcs subprotocol".

About your current requirement of taking control:

@timtuxworth pointed above a link to the documentation of this ( mavlink/mavlink#2158 ). In addition, in the QGC PR for this you can see a short video of it working mavlink/qgroundcontrol#12410 which I paste here as well:

multi-GCS-demo-2025-02-08_17.12.46.mp4

What you require, that 2 GCS can send any command at any time would not be possible with the multi GCS protocol. However, If the current GCS in control sets the vehicle as "takeover enabled", the other GCS could take control real quick. In the video I mention above it is demonstrated. Also see the explanation in that PR about this situation:

And you can see also a block diagram of how it would be, on the mavlink PR mentioned above:

Basically with "takeover enabled", if you are fine sending that MAV_CMD_REQUEST_OPERATOR_CONTROL, control will be granted automatically. I am not sure how invasive this would be on your current workflow.

My personal thoughts:

I understand this PR might be useful for your current setup, but I really think implementing multi GCS subprotocol will be useful for a bigger portion of userbase. If both can live together I think it would be good for the project.

QGC implementation is already functional in QGC 5.0, and I am happy to work on the Ardupilot PR #29252 (comment), but I am not as involved in Ardupilot as you guys are so I need some guidance. In that PR I asked back at the time, but I didn't get all the answers I needed to proceed. I am available in the following weeks to put time here if needed.

Thanks!

[tridge]

@Davidsastresas can you join the EU dev call this week to discuss?

[timtuxworth]

To @rmackay9 comment in the dev call about not liking MAV_SYSID_GCS_HI, how about we leave MAV_SYSID_GCS as it is and add a new range something like MAV_SYSID_GCS_MIN/MAX .. this would be in addition to MAV_SYSID_GCS. There could then be an option bit to enable the additional SYSID range, so it's completely NFC if the option is off.

This would then enable @Davidsastresas 's PR to work by allowing updates of the MAV_SYSID_GCS .. the existing field, only from MAV_SYSID values in the MIN/MAX.

[rmackay9]

HI @timtuxworth, thanks, yes, I had a similar thought.

So the param name ideas were:

• GCS_SYSID_HI (e.g. what's in this PR)
• GCS_SYSID_MAX
• two new params, GCS_SYSID_MIN ~ GCS_SYSID_MAX (e.g. what TimT's suggests)
• GCS_SYSID2, 3, 4, etc

[LupusTheCanine]

IMHO having two GCS devices active simultaneously is quite reasonable expectation as you can have GCS capable RC device and operator laptop for mission planning and monitoring. We typically fly with two man flight crew.

[hamishwillee]

Dumb question perhaps, but if you don't "really" care about safe handover in your workflow then perhaps make MAV_GCS_SYSID = 0 mean "will accept commands from any GCS"?

The current design is very much single ownership. I think it is well worth thinking about making sure that it works well with a fallback handover, but I'm not sure it makes sense for us to try mess with it to support multiple simultaneous owners.

For the handover case ...

• there is no reason that you might not use your internal range as a default GCS to fall back to as long as that publishes CONTROL_STATUS with the current id in control.
• There is also no reason you could not set an array of fallback GCS in MAV_CMD_REQUEST_OPERATOR_CONTROL. If the GCS loses heartbeats for whatever it is in control it could accept the first heartbeat from any of those as the presence of a system in control.

For the simultaneous owner case:

• If we absolutely had to support this case it would complicate things, in particular for components.
• We could update MAV_CMD_REQUEST_OPERATOR_CONTROL to allow "request control, release control, request simultaneous control".
• Then in CONTROL_STATUS we might have a number of control ids that the system would take commands from.

The trick here would be managing how we configure things to enforce the current strict handover vs simultaneous ownership. I think it is probably doable, but I don't particularly want to.

EDIT1
As for the two man crew thingy, I was thinking that would be separately handled by the gimbal management using a mavlink gimbal.

No one has to use this proposal if they don't want. It attempts to meet the most common use case really well - single ownership with handover. If we can also have failsafe then great. If we can support this use case too then awesome, but not at the cost of it being hard to adopt.

[Davidsastresas]

@tridge I am not sure If I will be able to make it to the EU call on Wednesday. If I am not able to, I can attend next global call on Monday probably. Would that work?

Thanks!

[hamishwillee]

@Davidsastresas Thinking about this a bit more I think the multiple ownership model is kind of fine. We could easily add support for multiple owners in the control status to indicate ownership and have components in system accept commands from any of them.
The problem is how you might handle requesting and granting control - who is the owner?

One way is that we mirror this PR:

• add end of range values to the MAV_CMD_REQUEST_OPERATOR_CONTROL and CONTROL_STATUS. Zero for just one in control.
• Allow requesting operator control in the same way as now but multiples may be specified
• Ask all GCS currently in control for permission to takeover
• Any GCS currently in control can send release command. This is where it gets hairy - I think it has to release the whole range/all owning GCS. Otherwise the ownership model is confused.

If this PR went in the MAV_CMD_REQUEST_OPERATOR_CONTROL would set the upper and lower range parameters.
What I don't like about this is that any allowed GCS that sends a command to get ownership will effectively take it from all other GCS that are currently owners, with the permission of only one.

Another possibility, and perhaps a little more flexible is to allow request to join in addition to release control and request control.

• add array of GCS in control to CONTROL_STATUS
• Add new option "request to join control" to takeover command
• Ask all GCS currently in control for permission to join control for specified GCS. If granted the new GCS joins control.
• A GCS can only release control for itself, leaving other GCS in control.

The first is a hammer - simple but not very "natural". The second doesn't fit as well with this PR.

Anyway food for thought. I think we could be open to either approach. @peterbarker interested in your thoughts on this.

[tridge]

@Davidsastresas I think you'll find your PR will be a lot easier after this PR is in, as it abstracts away sysid_is_gcs(), so your change should just need to change that function, using an in-ram variable (not a parameter)

[Davidsastresas]

After re reading everything again I agree it is handy to have the setup this PR allows.

@hamishwillee thanks for your analysis. I agree your second option is much more elegant, but it comes with the issue of only being able to set/report a range of system ids, non individual "non continuous" system ids from GCS in control. This is a problem if a current GCS of the group in control decides to leave the group and its system id is in between.
I think it would be too involved to figure out for the actual "extra usability".

I like your first option. It is kind of straightforward to implement everywhere, and it is 100% aligned with this PR.

The only drawback is a single operator could "give away" control of the whole group, but I think for the intended use case is fine. In the very first place, this mode of operation requires very good communication, so probably operators are used to confirm with others before doing mission critical stuff. I think if the team understands how this works it is acceptable that a single one could give away control of the whole group.

Considering the above I am fine with this PR, and I will update the other one accordingly.

Thanks!

[hamishwillee]

Me too! @Davidsastresas updated command/message proposal in mavlink/mavlink#2313. It should work for you too @tridge - allowing you to set this range via a GCS and choose to accept or reject requests to change the range (if all owners disconnect ownership can be set by anyone, but by that time you will have failsafed).

fixed

[rmackay9]

we had some discussion about parameters and some of us would prefer individual parameters but disagreements weren't strong enough to hold up merging

[Davidsastresas]

@rmackay9 just out of curiosity, what do you mean individual parameters? A few parameters dedicated to GCS SYSID that could be in control, opposed to just 2 for a range?

[rmackay9]

Hi @Davidsastresas,

Yes, that's right. So an alternative to having a range (GCS_SYSID_HI to GCS_SYSID) would be to have 2 or 3 parameters named GCS_SYSID, GCS_SYSID2, GCS_SYSID3.

[hamishwillee]

Yes, that's right. So an alternative to having a range (GCS_SYSID_HI to GCS_SYSID) would be to have 2 or 3 parameters named GCS_SYSID, GCS_SYSID2, GCS_SYSID3.

FWIW That seems more elegant when you're only talking a few GCS.