MAVLink: support mavlink 2.1 32 bit system IDs

[tridge]

Summary

Implements 32 bit system IDs

See also:

• implement 32 bit system IDs pymavlink#1229
• mavproxy: allow 32 bit MAVLink system IDs MAVProxy#1704
• pymavlink: update for 32 bit system ID support mavlink#515
• added rough mavlink 2.1 proposal mavlink/rfcs#20

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

This implements mavlink/rfcs#20 but with 32 bit system IDs to allow for IPv4 addresses to be used for system IDs. This should make large drone light shows easier.
I also plan on making full 32 bit integers work with mavlink parameters to make this more practical for real IPv4 addresses. That will be a separate effort. For now this PR is really 24 bit sysid support, but once we get the mavlink param change in it will work with 32 bit

Some open questions:

• should we put target_system&0xff in the uint8_t target_system field in messages or should we put in 0? This PR uses 0
• the lua script changes are tricky as the mavlink receiver gets the raw C structure which is now 3 bytes larger. Should we add compatibility code so the new lua script handles both forms? UPDATE: I've added compat code

Testing done both in SITL and on a fixed wing (bixler) at Spring Valley

Note on MAVLink peripherals

Setting MAV_SYSID above 255 means all packets are incompatible with older mavlink2 implementations. That means all packets to older peripherals will be dropped. We could add pre-arm checks in the future if this turns out to be an issue.

[tridge]

Automated review note — AI-generated (Claude), validated against the live diff. Please sanity-check before acting.

Review verdict: COMMENT

A large but carefully staged change (one commit per subsystem, submodule bump isolated, parameter conversions complete). The blocking item is external: the modules/mavlink pointer must land upstream first. The 24-bit parameter range and the Lua size-sniffing shim are the two things worth tightening before merge.

Findings

• ISSUE — Blocked on an unmerged upstream mavlink commit — this is what the red check actually says. The job is named check-merge-commits but runs check_branch_conventions.py, and every check passes except one: 8f8c578ed394 references modules/mavlink@5ad0e9105606: exists in ArduPilot/mavlink but is not yet merged to master (it is ahead of master). Notably "No merge commits" and "All submodule updates are isolated in their own commits" both pass. So this is the expected coordination gate on ArduPilot/mavlink#515, not a defect in the branch — but it does mean the PR cannot merge until that lands.
• ISSUE — The settable range is 24-bit, but the stated motivation needs 32. The widened parameters are capped at 16777215 (224−1) — three get @Range: 1 16777215 and two @Range: 0 16777215 — presumably because PARAM_VALUE carries parameters as a float and only 24 bits of mantissa survive the round trip. The PR body already flags full 32-bit parameter transport as separate future work — but since the headline use case is putting an IPv4 address in the system ID, and IPv4 needs all 32 bits, the parameter documentation should say outright that the settable range is currently 24-bit. As it stands a user reading "32 bit system IDs" will try to set an address above 16.7M and have it rejected with no explanation. GCS.cpp:41
• ISSUE — Mount's _SYSID_DFLT is widened with no @Range at all. The other five widened parameters all get an explicit 16777215 ceiling to stay inside float-exact territory, but AP_Mount_Params::sysid_default goes AP_Int8 → AP_Int32 while its metadata block is left untouched — and it has no @Range on master either. Widening it therefore removes even the implicit 0–255 bound the AP_Int8 type gave it, leaving a 32-bit parameter with no documented limit that a GCS or parameter-checking tool could enforce. It should get the same @Range: 0 16777215 as its siblings. AP_Mount_Params.h:60
• ISSUE — The Lua compatibility shim sniffs firmware layout by struct size, with hardcoded offsets. mavlink_msgs.sysid32_layout() decides between the old and new mavlink_message_t layouts with #message >= 299, then reads the extended target at fixed offsets 295 and 299. That works today, but it silently couples user-facing Lua to the exact byte size of a C struct: any future change to mavlink_message_t flips the heuristic with no error, and the failure mode is misparsed messages rather than a clean break. At minimum the three constants deserve a comment naming the struct fields they correspond to so a future mavlink bump has a chance of catching them. mavlink_msgs.lua:30
• NOTE — Parameter widening is handled completely — verified 1:1. This was the main thing I expected to find broken, since AP_Param matches stored entries on type == phdr.type (AP_Param.cpp:495,528), so a bare AP_Int16 → AP_Int32 change would silently reset every user's value to the default. All six widened parameters have a matching convert_parameter_width() call: GCS::sysid, mav_gcs_sysid, mav_gcs_sysid_high (in GCS::init), AntennaTracker g.sysid_target (in AntennaTracker/system.cpp) and AP_Follow::_sysid (in AP_Follow::convert_params) — all from AP_PARAM_INT16 — plus AP_Mount sysid_default from AP_PARAM_INT8 (in AP_Mount::init). Nothing is missed. GCS.cpp:1193
• NOTE — send_message_target() documents an unenforced caller contract. Its comment requires the caller to have already written the payload's target_system byte as (target_sysid > 255 ? 0 : target_sysid). Nothing checks this, and getting it wrong produces a packet that is subtly mis-addressed rather than rejected. Since the helper already has target_sysid in hand, consider having it write that byte itself. GCS.h:520
• NOTE — Routing correctly handles the targetted-without-msg-entry case. get_targets() now proceeds when MAVLINK_IFLAG_TARGETTED is set even if msg_entry == nullptr, which is necessary for forwarding messages this build does not know — the old code bailed out. Widening the sentinel-carrying locals to int64_t (so a full uint32_t plus the -1 "no target" sentinel both fit) is the right call, and the %lld/(long long) debug cast matches. MAVLink_routing.cpp:60
• NOTE — 82 checks still pending. Only 2 had reported at review time, so the build/autotest surface of a 68-file change touching every vehicle is essentially unverified so far. Worth a re-check once the run completes.

---

Generated from an automated review of all PRs labelled DevCallTopic on 2026-07-28. Full report: https://uav.tridgell.net/DevCallReviews/DevCallTopic/devcall_pr_reviews.html