Add support for MAV_CMD_REQUEST_OPERATOR_CONTROL by peterbarker · Pull Request #33332 · ArduPilot/ardupilot

peterbarker · 2026-06-05T10:53:26Z

Summary

Adds support for development.xml messages (still under review) to pass control of the system from one GCS to another (or several)

Classification & Testing (check all that apply and add your own)

Checked by a human programmer
Non-functional change
No-binary change
Infrastructure change (e.g. unit tests, helper scripts)
Automated test(s) verify changes (e.g. unit test, autotest)
Tested manually, description below (e.g. SITL)
Tested on hardware
Logs attached
Logs available on request

Description

Much discussion in various places, most notably in the mavlink PR.

There's a MAVProxy PR adding support

QGC has support in the codebase but (a) it is not enabled by default and (b) the message set that QGC compiles against by default has an older version of this message.

Task #9 — takeover notification: when a takeover request is rejected (allow_takeover=0), broadcast MAV_CMD_REQUEST_OPERATOR_CONTROL on all active channels to notify the current owner so they can release or grant permission. Task #10 — heartbeat disconnect releases control: rate-limited check (1 Hz) in GCS::update_receive() releases operator control when the operator's heartbeat has been absent for GCS_OPERATOR_HEARTBEAT_TIMEOUT_MS (5 s). Uses the global sysid_mygcs_last_seen_time_ms() timestamp which is updated by any GCS in the operator range, so control is only released when ALL owners in a range disconnect simultaneously. Task #11 — gcs_secondary in CONTROL_STATUS: track secondary connected GCS sysids (sysids in the operator range that are not gcs_main) via heartbeats in a small per-GCS array. Populate gcs_secondary[] in CONTROL_STATUS from recently-seen secondaries so multi-owner range mode is correctly reflected. Autotest additions: notification forwarded to owner on takeover reject, heartbeat disconnect releases control after timeout, gcs_secondary populated when range operator is active. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

…ation send Restrict RC_CHANNELS_OVERRIDE and MANUAL_CONTROL to the primary operator (gcs_main) only. Secondaries can send state-changing MAVLink commands but not manual stick input, matching the spec: "only one GCS owner can control manual input of the vehicle". Fix operator control takeover notification: the original direct call to mavlink_msg_command_long_send() was silently dropped when the TX buffer was momentarily full (comm_send_lock sets chan_discard=true). Route the notification through the queued send_message()/try_send_message() path (MSG_OPERATOR_CONTROL_NOTIFICATION) so it goes out as soon as TX space is available, like all other deferred messages. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Georacer

This one's looking good, Peter! Thank you for your work!

I've left a couple of comments. I'll try to test it with MAVProxy next.

Georacer · 2026-06-05T12:54:01Z

+        if (now_ms - _operator_control_last_hb_check_ms >= 1000) {
+            _operator_control_last_hb_check_ms = now_ms;
+            if (_operator_control_sysid != 0) {
+                const uint32_t last_seen = sysid_mygcs_last_seen_time_ms();
+                if (last_seen != 0 &&
+                    now_ms - last_seen > GCS_OPERATOR_HEARTBEAT_TIMEOUT_MS) {
+                    set_operator_control(0, 0, false);


I read here:
"Every 1s, check _operator_control_sysid. If it's not 0 and I have ever seen any of my GCSs, then release the control.
That doesn't sound right. Am I reading this wrong?

I guess the intention is that if the controlling GCS goes away for more than 1s, then the operator control will be released?
And the sysid_is_gcs() logic will fall back to sysid ranges.

You're right to be wary here, we flagged the same thing. The check keys on "any GCS in the range seen recently", so a secondary's heartbeats can mask the primary disconnecting, and a primary that's configured but never connects is never timed out (with takeover off, nobody can then take control). I think the fix is to track the primary's own last-seen separately from the range, so the timeout reflects the controller specifically. Happy to put that together if you and Peter agree on the direction.

Georacer · 2026-06-05T13:33:23Z

+        flags |= GCS_CONTROL_STATUS_FLAGS_TAKEOVER_ALLOWED;
+    }
+    uint8_t gcs_secondary[10] {};
+    gcs().get_secondary_gcs(gcs_secondary);


The MAVLink spec part "It should only include IDs for connected GCS" must have been a major pain.

We're essentially maintaining this secondaries list just to report it, IIUC.

Agreed it's a real cost. Now that the operator configures the secondary set GCS-side and it rides in the request range, ArduPilot already knows the authorized set without separately tracking who's been "seen", which is the only thing that bookkeeping buys is the spec's "only include connected GCS" wording. If that relaxed to "authorized range", AP could just report the range (the catch: gcs_secondary[10] caps at 10 while a range can be wider).

Georacer · 2026-06-11T17:40:27Z

I gave this a test today, using the modified MAVProxy.

I went through the 3 scenarios outlined in mavlink/mavlink#2158.

They all seem to work... most of the time.

Here are 3 successful .tlogs:
scenario1.tlog.txt
scenario2.tlog.txt
scenario3.tlog.txt

I haven't actually verified that both GCSs have been logged in there.

And some of the time I would get this. It would switch control and then immediately release it:

Here are two failed .tlogs with that issue:
failure.tlog.txt
failure2.tlog.txt

Davidsastresas · 2026-06-18T18:09:05Z

Hi @peterbarker @Georacer, I've been testing this against my QGC side mavlink/qgroundcontrol#14560 (multi-GCS SITL, 4 × QGC + MAVProxy to relay traffic) and the core request / grant / takeover handshake seems solid end-to-end. I needed a few fixes on the ArduPilot side, opened as a PR against Peter's branch (peterbarker#46). The fixes:

1. Separate gcs_main from the request range (c493dcf147)
gcs_main was reported as param4 (the range minimum), which need not be the requester; the spec defines it as the "GCS in control". Now tracks _operator_control_primary (msg.sysid) separately from the range.

2. Secondary GCS bypassed the takeover check (094b1ae3ab)
The "same GCS re-requesting" path used sysid_is_gcs(), so any in-range secondary was auto-granted control even with takeover off. Now compares against the primary. @hamishwillee you might want to be aware of this particular one.

3. Notification lifecycle (55117b5877)
_oc_notification.pending was write-only and clear_…() dead code, so notifications went stale / broadcast across ownership changes. Replaced with a per-channel pending mask (statustext pattern), keeping multi-link delivery.

4. Restrict release to the primary (930a4cce69)
Release was accepted from any in-range GCS, so a secondary could strip the primary. Now only the primary may release (uncontrolled still accepts a no-op release). Release is as privileged as takeover: a secondary that can't take control with takeover off shouldn't be able to force the primary out either.

5. Clamp request timeout (3abba2273b)
param3 (spec 3–60 s) was forwarded unchecked, including 0 from senders that omit it. Now constrain_float(param3, 3, 60).

Autotest (15ea302973)
Updates the operator-control test for points 4 and 5.

Design questions (not addressed):

Heartbeat timeout is one timestamp for the whole range — a secondary's heartbeats mask the primary disconnecting, so gcs_main keeps pointing at a gone GCS with no recovery. Track the primary separately, and on primary timeout fall to a secondary / go uncontrolled / failsafe?
Bootstrap lockout — with GCS_SYSID_ENFORCE on, init() pre-populates the primary from MAV_GCS_SYSID and the 5 s heartbeat timeout can't recover it (that path is guarded by last_seen != 0, so a never-seen primary never times out). If that GCS never connects and takeover defaults off, no one can acquire control. A recovery path might help (e.g. clear the pre-populated primary if never seen within the timeout) — though if this is intended, that's fine too; I don't mind that a GCS outside the configured range can't take control initially.
MAV_RESULT_NOT_IN_CONTROL never sent — the spec says non-controller commands "should be rejected with NOT_IN_CONTROL", but accept_packet() drops them silently. Worth ACKing rejected COMMAND_LONG/INT when the drop is operator-control specific?
Operator range replaces MAV_GCS_SYSID in sysid_is_gcs() — a GCS in the static params but outside the requested range is locked out. Keep the param range as a fallback?

QGC already ACKs the takeover notification (COMMAND_ACK/ACCEPTED), so the full handshake completes against this branch with fix 3.

Davidsastresas · 2026-06-22T12:28:57Z

@Georacer The "switch and immediately release" bug you hit might be fixed by the notification lifecycle fix (peterbarker@55117b5) _oc_notification.pending was write-only so notifications went stale across ownership changes, which could explain the immediate release after a switch. Would be great if you could retest against the fix branch (peterbarker#46) once it lands.

Also, if you have cycles, would love your take on the open design questions from my comment above, especially the heartbeat timeout tracking the whole range instead of the primary specifically. That one's the most likely to bite us in real multi-GCS setups. @hamishwillee also said his thoughts on it in the last part of his comment ArduPilot/mavlink#503 (comment).

peterbarker and others added 5 commits June 5, 2026 20:50

GCS_MAVLink: implement GCS_CONTROL protocol

b5f58cf

autotest: add test for REQUEST_OPERATOR_CONTROL

b6fb3f6

mavlink: reference MAV_CMD_REQUEST_OPERATOR_CONTROL message

9f26e44

peterbarker mentioned this pull request Jun 5, 2026

development.xml: copy MAV_COMMAND_REQUEST_OPERATOR_CONTROL from mavlink/mavlink/master ArduPilot/mavlink#503

Open

Georacer reviewed Jun 5, 2026

View reviewed changes

github-actions Bot added CI Copter MAVLink Python labels Jun 6, 2026

Davidsastresas mentioned this pull request Jun 18, 2026

Pr multi gcs june2026 ap peterbarker/ardupilot#46

Open

Davidsastresas mentioned this pull request Jun 22, 2026

Multi GCS update mavlink/qgroundcontrol#14560

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add support for MAV_CMD_REQUEST_OPERATOR_CONTROL#33332

Add support for MAV_CMD_REQUEST_OPERATOR_CONTROL#33332
peterbarker wants to merge 5 commits into
ArduPilot:masterfrom
peterbarker:pr-claude/MAV_CMD_REQUEST_OPERATOR_CONTROL

peterbarker commented Jun 5, 2026

Uh oh!

Georacer left a comment

Uh oh!

Georacer Jun 5, 2026

Uh oh!

Davidsastresas Jun 22, 2026

Uh oh!

Georacer Jun 5, 2026

Uh oh!

Davidsastresas Jun 22, 2026

Uh oh!

Georacer commented Jun 11, 2026

Uh oh!

Davidsastresas commented Jun 18, 2026 •

edited

Loading

Uh oh!

Davidsastresas commented Jun 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Conversation

peterbarker commented Jun 5, 2026

Summary

Classification & Testing (check all that apply and add your own)

Description

Uh oh!

Georacer left a comment

Choose a reason for hiding this comment

Uh oh!

Georacer Jun 5, 2026

Choose a reason for hiding this comment

Uh oh!

Davidsastresas Jun 22, 2026

Choose a reason for hiding this comment

Uh oh!

Georacer Jun 5, 2026

Choose a reason for hiding this comment

Uh oh!

Davidsastresas Jun 22, 2026

Choose a reason for hiding this comment

Uh oh!

Georacer commented Jun 11, 2026

Uh oh!

Davidsastresas commented Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Davidsastresas commented Jun 22, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Davidsastresas commented Jun 18, 2026 •

edited

Loading