Conversation
github-actions
Bot
added
kind:bug
amovlgf
marked this pull request as ready for review
September 20, 2026 06:49
Contributor
🔎 FLASH Analysispx4_fmu-v5x [Total VM Diff: 264 byte (0.01 %)]px4_fmu-v6x [Total VM Diff: 272 byte (0.01 %)]Updated: 2026-09-22T04:07:48 |
Contributor
|
No broken links found in changed files. |
DroneCAN ArmStatus is already published internally but never reaches the RID health check. Consume it in Commander and refresh readiness before normal arming checks, rejecting faults and status older than three seconds. Keep CAN as the source after its first valid status so MAVLink heartbeats cannot hide a fault or disconnect. Preserve existing parameter policies and preflight bypasses, and add focused regression tests and documentation. Compile the CAN-specific integration only with the DroneCAN Remote ID controller or tests. Propagate the internal flag to Commander consumers so non-CAN targets avoid the subscription and pre-arm refresh while test class layouts remain consistent. Signed-off-by: lvguofei <1969354053@qq.com> Assisted-by: Codex
amovlgf
force-pushed
the
pr/dronecan-rid-arming-check
branch
from
September 22, 2026 03:57
1475736 to
020aacd
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
With
COM_ARM_ODID=2, DroneCAN RID faults and status timeouts prevent normal arming without triggering an in-flight action; existing preflight bypasses remain available.Problem
PX4 already receives
dronecan.remoteid.ArmStatus, but Commander derives RID health only from MAVLink heartbeats, so the CAN module's readiness does not reach the existing arming check.Solution
Consume the existing status, accept only
GOOD_TO_ARM, expire it after three seconds, and refresh it before normal arming checks; after the first valid CAN message, use CAN until restart so MAVLink cannot mask a fault or disconnect (before that, MAVLink remains the fallback; only a single CAN RID is supported).Compile this CAN integration only when the DroneCAN Remote ID controller is enabled, or for tests; other firmware retains periodic MAVLink RID checks without the new pre-arm refresh.
Parameter definitions/defaults, existing
COM_ARM_ODID=3/4/5flight policies, other arming checks, flight-control algorithms, board configuration, and the CAN driver/protocol are unchanged by this PR.Validation: freshly built and passed 44 RID/health/failsafe tests,
px4_sitl_default, and FMU-v2, Flycore, and FMU-v6x firmware with Arm GCC 13.2.1; changed-file formatting and whitespace checks pass. FMU-v2 uses 1,019,996 of 1,032,192 Flash bytes. Hardware bench testing has not been performed.