ArduPilot: Review AVAILABLE_MODES_MONITOR discussion and clean up QGC standard modes handling

[DonLakeFlyer]

Background

ArduPilot/ardupilot#33811 covers ArduPilot streaming AVAILABLE_MODES_MONITOR unconditionally after the first AVAILABLE_MODES request, which caused QGC to re-download the full mode list on every connect (see #14247). ArduPilot/ardupilot#33814 changes AP to only stream the monitor after the mode set actually changes.

Task

Review the full discussion in ArduPilot/ardupilot#33811 and clean up the QGC side accordingly. Items raised in the discussion that need review:

• Verify QGC behaves correctly when it connects to a vehicle that is already streaming AVAILABLE_MODES_MONITOR (modes changed before connect / another GCS previously requested modes). Monitor messages received before QGC has requested AVAILABLE_MODES should be ignored without causing problems.
• QGC currently requests modes one by one instead of using index 0 for "send all modes". Determine why (possibly a workaround for an old PX4 firmware bug) and switch to the single "send all" request if possible.
• Re-verify against the new AP behavior (GCS_MAVLink: rework AVAILABLE_MODES_MONITOR to only stream after a change ArduPilot/ardupilot#33814) that QGC only downloads the mode list once on a normal connect, and re-downloads correctly when the mode set changes.

References

• GCS_MAVLink: AVAILABLE_MODES_MONITOR is streamed unconditionally after first AVAILABLE_MODES request, deviating from MAVLink spec and forcing GCS re-downloads ArduPilot/ardupilot#33811 (comment)
• MAVLink standard modes spec: https://mavlink.io/en/services/standard_modes.html

[hamishwillee]

Just FYI, this has highlighted a genuine issue in the protocol that if a GCS connects and requests the modes, then gets an AVAILABLE_MODES_MONITER with a value > 0 (or maybe 1?), there is no way to know if it should re fetch or not.
If it gets zero then it can assume that the values have not been updated.

We could just say "live with the case". Discussion on fix in mavlink/mavlink#2557

[DonLakeFlyer]

Status review against current code and the upstream fixes:

Resolved upstream: ArduPilot/ardupilot#33814 is merged — AVAILABLE_MODES_MONITOR now only streams after an actual mode-set change, with per-channel seq starting at 0. Confirmed by @IamPete1 that QGC daily now downloads the mode list exactly once on a normal connect. No QGC change was needed for the double-download (#14247).

Task item review:

1. Vehicle already streaming the monitor at connect — QGC handles this correctly today: Vehicle.cc ignores AVAILABLE_MODES_MONITOR while the initial connect state machine is active, and StandardModes::_lastSeq{-1} means the first post-connect monitor triggers at most one redundant (but harmless) re-download. That edge case is not fixable without AVAILABLE_MODES.seq (update(common): AVAILABLE_MODES.seq mavlink#2557, approved but not yet merged).

2. Switch to index-0 "send all" request — the one-by-one requests are not a PX4 workaround; the reason is documented in StandardModes::request(): Vehicle::requestMessage can't handle a multi-message response. Switching requires new response-collection machinery (multiple messages, timeouts, restart-on-change) — real refactoring of the connect path.

Plan: Nothing here is a 5.1 stability risk and no code change is required now beyond a SITL verification pass against AP master + PX4. Moving the remaining cleanup (send-all refactor, adopting AVAILABLE_MODES.seq once mavlink/mavlink#2557 merges) to the 5.2 milestone.