Summary
On release/1.16 (v1.16.1), every v1.17 pre-release, and current main,
PARAM_REQUEST_LIST, PARAM_SET, and PARAM_REQUEST_READ aimed at a MAVLink
target_component in 100–105 are silently dropped by the UAVCAN parameter
bridge handler. Because that handler maps target_component 1:1 onto the
UAVCAN node_id, this also means DroneCAN peripherals (e.g. ESCs) at CAN
node IDs 100–105 are unreachable via MAVLink parameters.
Field symptom: QGroundControl's parameter download hangs / times out whenever a
DroneCAN ESC is powered at a node ID in 100–105. Reassigning the node ID to
anything outside that range resolves it.
Reproduction
- PX4 v1.16.1, or any v1.17 pre-release (α1 … rc2), or
main at the time of
writing.
- A DroneCAN peripheral (ESC works well for repro) at node ID ∈ {100, 101,
102, 103, 104, 105}, powered and emitting NodeStatus so QGC sees the
component.
- In QGC: open Vehicle Setup → param download to that component stalls /
times out.
Node IDs outside 100–105 — verified 26–29, 99, 106, 107–113, 120, 126 — are
unaffected.
Cause
PR #25651 added this guard at three sites in
src/modules/mavlink/mavlink_parameters.cpp (lines 82, 141, 219 on main):
&& !(target_component >= MAV_COMP_ID_CAMERA && target_component <= MAV_COMP_ID_CAMERA6)
Per MAVLink minimal.xml, MAV_COMP_ID_CAMERA = 100 and
MAV_COMP_ID_CAMERA6 = 105 — exactly the observed fault range.
The PR's stated intent is reasonable: stop MAVLink param messages aimed at
MAVLink cameras from being forwarded onto the CAN bus. But the same handler
immediately assigns:
req.node_id = req_list.target_component; // :87
req.node_id = set.target_component; // :146
req.node_id = req_read.target_component; // :225
i.e. on this path, the MAVLink component namespace is the UAVCAN node-ID
namespace. Excluding 100–105 from the bridge therefore excludes those CAN node
IDs from MAVLink-visible parameter access.
The original PR thread already contains a maintainer note that using CAN node
ID as MAVLink component ID "is fragile and we should address it properly
sometime in the future." This issue is the "sometime."
Why it hasn't hit more users
ArduPilot's DroneCAN convention assigns ESC node IDs counting down from 125
(four motors get 125, 124, 123, 122), which never enters the guarded range.
Users following generic DroneCAN examples that number up from 100 land
exactly inside the exclusion.
Proposed fixes
In order of preference:
A. Make the camera-vs-CAN-node disambiguation data-driven (preferred)
Only exclude target_component 100–105 from the CAN bridge when PX4 has
actually observed a MAVLink camera on that component ID — keyed on recent
HEARTBEATs with MAV_TYPE_CAMERA. If PX4 has seen a DroneCAN NodeStatus for
CAN node N but no MAVLink camera heartbeat for comp ID N, forward to CAN. If
both exist, prefer the camera and PX4_WARN the collision.
This preserves #25651's intent for real cameras while unblocking the common
DroneCAN ESC case.
B. Separate the two namespaces
Introduce a distinct component-ID range (or a dedicated MAVLink message / an
explicit CAN-node selector field) for addressing DroneCAN nodes, so the two
namespaces stop overlapping entirely. This is the clean long-term fix and
matches the maintainer's comment on #25651. Requires coordinated QGC-side
changes.
C. Narrow revert (stopgap)
Revert the 100–105 exclusion from main, release/1.17, and release/1.16,
and re-open the original camera-routing problem #25651 was addressing. This
reinstates that smaller issue but clears the far larger DroneCAN regression.
Acceptable only until A or B lands.
Affected code
src/modules/mavlink/mavlink_parameters.cpp — the three MAVLINK_MSG_ID_*
branches listed above.
References
Summary
On
release/1.16(v1.16.1), everyv1.17pre-release, and currentmain,PARAM_REQUEST_LIST,PARAM_SET, andPARAM_REQUEST_READaimed at a MAVLinktarget_componentin 100–105 are silently dropped by the UAVCAN parameterbridge handler. Because that handler maps
target_component1:1 onto theUAVCAN
node_id, this also means DroneCAN peripherals (e.g. ESCs) at CANnode IDs 100–105 are unreachable via MAVLink parameters.
Field symptom: QGroundControl's parameter download hangs / times out whenever a
DroneCAN ESC is powered at a node ID in 100–105. Reassigning the node ID to
anything outside that range resolves it.
Reproduction
mainat the time ofwriting.
102, 103, 104, 105}, powered and emitting NodeStatus so QGC sees the
component.
times out.
Node IDs outside 100–105 — verified 26–29, 99, 106, 107–113, 120, 126 — are
unaffected.
Cause
PR #25651 added this guard at three sites in
src/modules/mavlink/mavlink_parameters.cpp(lines 82, 141, 219 onmain):Per MAVLink minimal.xml,
MAV_COMP_ID_CAMERA= 100 andMAV_COMP_ID_CAMERA6= 105 — exactly the observed fault range.The PR's stated intent is reasonable: stop MAVLink param messages aimed at
MAVLink cameras from being forwarded onto the CAN bus. But the same handler
immediately assigns:
i.e. on this path, the MAVLink component namespace is the UAVCAN node-ID
namespace. Excluding 100–105 from the bridge therefore excludes those CAN node
IDs from MAVLink-visible parameter access.
The original PR thread already contains a maintainer note that using CAN node
ID as MAVLink component ID "is fragile and we should address it properly
sometime in the future." This issue is the "sometime."
Why it hasn't hit more users
ArduPilot's DroneCAN convention assigns ESC node IDs counting down from 125
(four motors get 125, 124, 123, 122), which never enters the guarded range.
Users following generic DroneCAN examples that number up from 100 land
exactly inside the exclusion.
Proposed fixes
In order of preference:
A. Make the camera-vs-CAN-node disambiguation data-driven (preferred)
Only exclude
target_component100–105 from the CAN bridge when PX4 hasactually observed a MAVLink camera on that component ID — keyed on recent
HEARTBEATs with
MAV_TYPE_CAMERA. If PX4 has seen a DroneCAN NodeStatus forCAN node N but no MAVLink camera heartbeat for comp ID N, forward to CAN. If
both exist, prefer the camera and
PX4_WARNthe collision.This preserves #25651's intent for real cameras while unblocking the common
DroneCAN ESC case.
B. Separate the two namespaces
Introduce a distinct component-ID range (or a dedicated MAVLink message / an
explicit CAN-node selector field) for addressing DroneCAN nodes, so the two
namespaces stop overlapping entirely. This is the clean long-term fix and
matches the maintainer's comment on #25651. Requires coordinated QGC-side
changes.
C. Narrow revert (stopgap)
Revert the 100–105 exclusion from
main,release/1.17, andrelease/1.16,and re-open the original camera-routing problem #25651 was addressing. This
reinstates that smaller issue but clears the far larger DroneCAN regression.
Acceptable only until A or B lands.
Affected code
src/modules/mavlink/mavlink_parameters.cpp— the threeMAVLINK_MSG_ID_*branches listed above.
References
main):Correction of routing issue of mavlink parameter messages to CAN nodes. #25651
release/1.16, shipped in v1.16.1):[BACKPORT 1.16] Correction of routing issue of mavlink parameter messages to CAN nodes #25658
https://mavlink.io/en/messages/minimal.html#MAV_COMPONENT