Add support for multi-GCS operation

[Davidsastresas]

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 thread instead. Mavlink docs will be updated shortly, when we confirm all of this looks good.

On this PR, the implementation is as follows:

New top toolbar indicator

This indicator will be populated if the active vehicle is sending the new CONTROL_STATUS message. On this icon we can grasp:

• System Id in control
• If this GCS is currently in control
• If takeover is allowed automatically, or we need to ask to the GCS in control first.

Note this icon will have an animation effect whenever the control status changes, whether it is because of a change in takeover allowed, or because of a change in system in control.

This way, we have some variants:

On this case this GCS (252) is in control, as we see the the sysId label green, and also the aircraft icon and the segment joining label and aircraft.

On this case, this GCS (252) is not in control ( label is white, not green ), and also the aircraft icon and segment joining is white, indicating automatic takeover is not allowed ( we need to ask to the GCS in control first )

On this case it is similar to the above situation, only automatic takeover is allowed ( aircraft icon in green ) so we don't need to request permission to the GCS in control, we can adquire control directly.

Expanded menu after clicking top toolbar indicator

After clicking the top toolbar icon, we see an expanded panel. This panel changes depending on the particular control situation. On this panel, we can:

• See what system id is in control, and see it highlighted in green when it is us
• See if automatic takeover is allowed, or the requesting GCS needs to ask permision first
• Send control requests, in case we are not in control
• If we are in control, we can change if automatic takeover is allowed or not
• We can also change SystemID of this GCS from here, similar to how we usually do in the general settings -> telemetry settings
  

Control request procedure when takeover is allowed

In the most simple case where we are not in control and takeover is allowed, just clicking "Acquire control" will grant us control of the vehicle.
Note that on this situation, we can choose before acquiring control if we want to allow automatic takeover or not, on the tickbox. If we want to change this after being in control it is possible too, see previous screenshot.

Control request procedure when takeover is not allowed

On this situation, we will have the following panel:

Clicking "send request" will send a control request to the GCS in control, with a timeout specified in "Request timeout (sec)", in this case 7 seconds. This timeout will be sent as a parameter in the command, to syncronize progress indicators in both GCS.
We can not sent another request until that timeout expires. This way, after clicking "send request", we will see the following:

And in the current GCS in control, a popup will appear indicating the request, with a syncronized countdown:

Clicking "Ignore" will just discard the popup, with no consequences, and if we click "allow takeover" the requestor GCS will be able to adquire control directly, as in the previous section "Control request procedure when takeover is allowed". However, we will see the following popup appear:

We have a timeout of 10 seconds after clicking "allow takeover" above. If after those 10 seconds the requestor GCS didn't take control, automatic takeover will be set to disabled again. This will happen regardless of discarding ( clicking Ignore ) on the panel above. This is done as a security measure so operators don't forget they accepted a takeover that was never fully completed.

Aditional comments

A couple of new command line arguments were added, in order to make testing easier:

• Argument to specify system id con command line when launching the app, useful for sending 2 instances at the same time with different sysid regardless of offline settings

--system-id:254

• Argument to be able to run multiple instances at the same time, by default only one instance of QGC can run

--allow-multiple

Using both arguments it is handier to test this in SITL

Testing status

This has been tested in SITL using the following Ardupilot branch ArduPilot/ardupilot#29252

Here is a short video showing this testing:

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

For awareness @hamishwillee @rmackay9. Also @julianoes might want to take a look at it too, for Px4 support.

Thanks to https://harrisaerial.com and https://www.lincesystems.com for sponsoring this PR, and to @hamishwillee for his wise and valuable support, experience and patience during all the iterations that preceded this work.

[HTRamsey]

--allow-multiple is only for testing right? There's probably a lot of potential issues with running multiple instances but I guess it doesn't matter that much if it's just meant for testing. https://github.com/itay-grudev/SingleApplication has a neat concept of primary/secondary instances that could be used to better support multiple instances in the future.

[Davidsastresas]

@HTRamsey Yes, it is only meant for testing. I really can not imagine a situation on real world usage where you would want to have 2 GCS instances.

As it is a command line argument, I doubt users will boot QGC with this option without noticing in a production GCS.

I would really like to leave that option, I don't need multiple QGC instances often, but every now and then it helps to have during development, I think it is handy to have. I checked the SingleApplication link you mentioned, it is very interesting, but I think it is overkill for us, at least for the moment. Thanks!

[DonLakeFlyer]

I haven't look in detail yet, but a few things:

• development.xml things should only be supported in debug builds. So the addition of the indicator to the toolbar should be ifdef'ed.
• What's your thinking around dim=false? Not so thrilled about some dropdowns dim and some not. If it makes sense then I think it would make sense for all of them to not be dim.
• Similar to development.xml I would make --allow-multiple debug build only.
• Can you update the docs for this as well (explaining debug only for now)

[Davidsastresas]

@DonLakeFlyer

• About dimming or not, first time we used that was for gimbal indicator, it is like that on Stable. I get your logic of doing all of them or none of them. If I had to choose I would choose to not dim. Sometimes it could be interesting for an operator to have one of those extended panels to visualize some extended telemetry, or in the case of gimbal control to have the controls handy.

My logic to not dim this one, together with gimbal control, is that users might want to eventually leave the panel open momentarily during some part of the operation, and dim is inconvenient on such scenarios.

• About docs, @hamishwillee and I will finish this Add documentation for Multi GCS protocol (Draft) mavlink-devguide#556 when we get more testing from users hopefully in the incoming weeks, is that fine?

I pushed a couple off commits addressing the QT_DEBUG matter for controlIndicator.qml and --allow-multiple argument.

[DonLakeFlyer]

• About dimming or not...

Reasonable. I didn't even know not dimming was an option. Can you make them all not dim by changing main popup in MainRootWindow and then remove the option of dim or not. I think that's better overall.

• About docs

Make sense

[Davidsastresas]

@DonLakeFlyer I applied your latest comments, thanks for the review!

[DonLakeFlyer]

The other top level problem with this is that the toolbar indicator dropdown doesn't really match the new style of ui. That's fine for now. I can come in after this is merged in and clean it up.

[Davidsastresas]

@DonLakeFlyer thanks for the review. I addressed most of your requests, but some others required clarification, so I left the corresponding threads opened.

About UI and style, sorry about it, this was thought for 4.4 initially. I personally don't think it is a huge deal, because this popup, together with the gimbal one, are not quite the same as the other top toolbar indicators. The rest of indicators usually report telemetry, so the logic of the new UI makes total sense, but I am not sure I would change this one.

I am open to it though, so we can come back to this in the future if that is fine, to not hold the PR because of it?

[DonLakeFlyer]

About UI and style

No need to update UI in this pull. Once this goes through I'll take a look at it later on to see if anything needs updating.

[julianoes]

Thanks for the screenshare, it looks great!

One thing that I find a bit confusing is that you have to do two actions: first request, and then secondly confirm. Is that really required?

I would have expected to get control immediately if I requested it and it gets approved.

[Davidsastresas]

Thanks for the screenshare, it looks great!

One thing that I find a bit confusing is that you have to do two actions: first request, and then secondly confirm. Is that really required?

I would have expected to get control immediately if I requested it and it gets approved.

Hi Julian, thanks for the review. I am not sure what exactly you mean, but:

• If takeover is allowed, when you take control it is taken directly, just with one click.
• If takeover is not allowed, you send a control request. This control request needs to be accepted by the GCS in control, which will allow takeover, but only for 10 seconds. If control is not taken on those 10 seconds, takeover will be set to not allowed again, to avoid the operator forgetting about it and leaving the system in "allow takeover" state without having set it that way explicitely.

I imagine you were referring to the second scenario. This is something @hamishwillee and I discussed back at the time, and we ended up with that procedure.

I think the reasoning was that the "requesting GCS" does not know exactly when the GCS in control will grant control, so it could grant control when the "requesting GCS" is not expecting it. So this procedure of first allowing takeover, so "requesting GCS" can then get control instantly with a click made more sense, was more predictable and safer for everybody.

[Davidsastresas]

@DonLakeFlyer I spared some time today to look at your pending requests.

About mavlink and magic numbers

I updated mavlink to the latest version, tried to rebuild, but it still fails if I use MAV_CMD_REQUEST_OPERATOR_CONTROL instead of the magic number MAV_CMD(32100).

I used to be familiarized with how mavlink is integrated in QGC, but it has changed so much, and each time I look at it has changed again, so I am sorry but I don't have the time to troubleshoot why it isn't picking the commands in development.xml. I would not mind doing it if it was a stable version, but I would hate to spend the time for it to change again next time I look at it.

About handlers #12410 (comment)

Great point, and I agree that is the neat way of doing it. However I don't think I will have time until late April to spend time on this again. Do you think that should prevent the PR getting in? It is fine if you do, I will fix it in April.

Thank you very much for your review.

[Davidsastresas]

Another solution would be to leave this PR as draft, or close it, and do a PR against Stable QGC.

[DonLakeFlyer]

do a PR against Stable QGC.

That doesn't make sense since development.xml stuff is debug build only. Also 5.0 will be out in a couple months.

[DonLakeFlyer]

However I don't think I will have time until late April to spend time on this again. Do you think that should prevent the PR getting in?

Create an Issue for this, assign it to yourself. And then I'm fine with it going in like this.

[Davidsastresas]

@DonLakeFlyer good point about stable, makes sense. I created the issue #12552

Thanks!

[DonLakeFlyer]

I'll take a stab at the mavlink version upgrade...

[DonLakeFlyer]

I updated mavlink to the latest version, tried to rebuild, but it still fails if I use MAV_CMD_REQUEST_OPERATOR_CONTROL instead of the magic number MAV_CMD(32100).

It's pretty easy, it's just here. Not sure if you need a clean full build if you change that:
https://github.com/mavlink/qgroundcontrol/blob/master/cmake/CustomOptions.cmake#L37

[DonLakeFlyer]

And then you need to ifdef code which references development.xml stuff to be debug only since development.xml is debug only. I bumped the mavlink tag, updated code to use real command things from headers and build a debug and it worked fine for me.

[DonLakeFlyer]

No wait, it was working now it's not.. still looking...

[DonLakeFlyer]

No wait, it was working now it's not.. still looking...

It's broken upstream. I'll fix that, and bump the mavlink in that pull.

[DonLakeFlyer]

So once my fix goes through. You'll need to rebase. Then make sure to #ifdef QGC_DAILY_BUILD the important parts which light this thing up on debug builds only. Should mostly be the command handlers I think.

[Davidsastresas]

Please note I did a mavlink update right as you described earlier today, see commit b9e0dea, right before #12410 (comment) and it didn´t work for me.

About the QGC_DAILY_BUILD part, sure! I will be a couple of weeks away so maybe I can not service it on the next few days, but I will be back on April.

Thanks Don!

[Davidsastresas]

@hamishwillee I tested your suggestion and it works, thanks! I added it to the current PR 43ca6d3. As a consequence, there is no need to use magic numbers anymore @DonLakeFlyer, so I updated it here fc15204.

I also left the PR updated to current master. Thanks!

[Davidsastresas]

@DonLakeFlyer I also addressed your concern in #12410 (comment) in commit 862d647. When a operator request is not answered, or sent while we are waiting for a previous request, we will have a popup as follows:

I think as it is now it should have fixed your latest concerns about this PR which were:

• Magic numbers because development.xml wasn't working as it should
• What happens if vehicle does not respond to operator request command?

I know we are a bit tight for the 5.0 release you wanted to make, so it is fine to leave this out, but even if we leave this out for the incoming release, It would be good to merge it soon after that. I've had to rebase this PR a few times already, and it's super time consuming at the current rate the codebase is changing.

Thanks!

[DonLakeFlyer]

All good, thanks

[DonLakeFlyer]

@hamishwillee So what's the state of the mavlink for this support? Is it still in development or has it moved to regular mavlink?

[Davidsastresas]

@DonLakeFlyer Thank you, much appreciated!