Feature Request
Feature request
While working on a companion computer integration I discovered that ArduPilot silently drops all incoming ONBOARD_COMPUTER_STATUS frames (MAVLink message ID 390). After investigating, I found the root cause: the message definition is missing from ArduPilot/mavlink, so ArduPilot has no CRC_EXTRA entry for it at build time and rejects any frame with that ID.
The mesage ONBOARD_COMPUTER_STATUS (ID 390) is in the MAVLink standard. It was designed for companion computers to report their hardware status (CPU, RAM, storage, temperature, network links) to the flight controller. It was added to the upstream mavlink/mavlink repository back in August 2019 via mavlink/mavlink PR #1186 and has been part of the standard common.xml ever since, as confirmed by the auto-generated C library: mavlink/c_library_v2 — mavlink_msg_onboard_computer_status.h
ArduPilot uses its own fork of the MAVLink library: ArduPilot/mavlink. ArduPilot Copter-4.6.0 pins its modules/mavlink submodule to commit bb87bc7.
Searching message_definitions/v1.0/common.xml at that commit for ONBOARD_COMPUTER_STATUS or id="390" returns no results (the message is absent). The same is true for development.xml at that commit.
The submodule reference in Copter-4.6.0 can be verified here: ArduPilot/ardupilot — modules/mavlink @ Copter-4.6.0
Because ArduPilot builds its MAVLink routing table and CRC_EXTRA map at compile time from these XML files, any incoming frame with ID 390 is silently rejected at runtime — even if the sender is a legitimate companion computer on the same vehicle.
I was also checking in master, but ONBOARD_COMPUTER_STATUS and it's mavlink pin is newer: f1d2d09. But still, ONBOARD_COMPUTER_STATUS is not there. So, this make me think that it won't be included by default in Copter-4.7.
Describe the solution you'd like
Sync the ONBOARD_COMPUTER_STATUS message block from upstream mavlink/mavlink common.xml into ArduPilot/mavlink common.xml, and then bump the submodule pointer in ArduPilot/ardupilot.
This is a pure sync of an existing standard message, no new design decisions required.
Describe alternatives you've considered
Currently we are patching modules/mavlink/message_definitions/v1.0/common.xml at Docker (for SiTL) and build time to inject the message definition before compilation. This works but is fragile: it must be repeated for every fresh clone of ArduPilot, breaks if the injection script is not maintained alongside ArduPilot version bumps, and is invisible to anyone building ArduPilot from source without that custom build step.
Platform
Additional context
Add any other context or screenshots about the feature request here.
Feature Request
Feature request
While working on a companion computer integration I discovered that ArduPilot silently drops all incoming ONBOARD_COMPUTER_STATUS frames (MAVLink message ID 390). After investigating, I found the root cause: the message definition is missing from ArduPilot/mavlink, so ArduPilot has no CRC_EXTRA entry for it at build time and rejects any frame with that ID.
The mesage ONBOARD_COMPUTER_STATUS (ID 390) is in the MAVLink standard. It was designed for companion computers to report their hardware status (CPU, RAM, storage, temperature, network links) to the flight controller. It was added to the upstream mavlink/mavlink repository back in August 2019 via mavlink/mavlink PR #1186 and has been part of the standard common.xml ever since, as confirmed by the auto-generated C library: mavlink/c_library_v2 — mavlink_msg_onboard_computer_status.h
ArduPilot uses its own fork of the MAVLink library: ArduPilot/mavlink. ArduPilot Copter-4.6.0 pins its modules/mavlink submodule to commit bb87bc7.
Searching message_definitions/v1.0/common.xml at that commit for ONBOARD_COMPUTER_STATUS or id="390" returns no results (the message is absent). The same is true for development.xml at that commit.
The submodule reference in Copter-4.6.0 can be verified here: ArduPilot/ardupilot — modules/mavlink @ Copter-4.6.0
Because ArduPilot builds its MAVLink routing table and CRC_EXTRA map at compile time from these XML files, any incoming frame with ID 390 is silently rejected at runtime — even if the sender is a legitimate companion computer on the same vehicle.
I was also checking in
master, but ONBOARD_COMPUTER_STATUS and it's mavlink pin is newer: f1d2d09. But still, ONBOARD_COMPUTER_STATUS is not there. So, this make me think that it won't be included by default in Copter-4.7.Describe the solution you'd like
Sync the ONBOARD_COMPUTER_STATUS message block from upstream mavlink/mavlink common.xml into ArduPilot/mavlink common.xml, and then bump the submodule pointer in ArduPilot/ardupilot.
This is a pure sync of an existing standard message, no new design decisions required.
Describe alternatives you've considered
Currently we are patching
modules/mavlink/message_definitions/v1.0/common.xmlat Docker (for SiTL) and build time to inject the message definition before compilation. This works but is fragile: it must be repeated for every fresh clone of ArduPilot, breaks if the injection script is not maintained alongside ArduPilot version bumps, and is invisible to anyone building ArduPilot from source without that custom build step.Platform
Additional context
Add any other context or screenshots about the feature request here.