feat: consume vehicle-provided parameter metadata by JackSkellet · Pull Request #4069 · bluerobotics/BlueOS

JackSkellet · 2026-07-31T15:04:17Z

Summary

This adds support for consuming parameter metadata published by the connected flight controller instead of relying exclusively on BlueOS's bundled ArduPilot metadata files.

The implementation:

receives MAVLink COMPONENT_METADATA advertisements;
downloads bounded parameter metadata documents over MAVFTP or HTTPS;
validates the advertised CRC and document structure;
exposes the active document from ArduPilot Manager with ETag support;
merges vehicle-provided metadata over the nearest compatible bundled metadata in the frontend;
refreshes the table when the vehicle advertises a new metadata generation;
keeps bundled fallback selection within the same vehicle family;
upgrades mavlink2rest from t0.11.25 to 0.11.26, adding COMPONENT_METADATA while preserving the 0.11 API.

Why

BlueOS currently assumes that parameter names, descriptions, units, ranges and enum choices are fully described by a static metadata file bundled with the frontend. That does not work well for custom firmware or for parameter choices that depend on devices discovered at runtime.

This enables use cases such as:

custom or development firmware supplying descriptions for parameters that do not exist in an upstream ArduPilot release;
detected sensors being presented as meaningful enum choices without a BlueOS-specific override;
per-lane EKF source-target selection, for example selecting different DVLs for EK3_SRC1, EK3_SRC2 and EK3_SRC3;
refreshing source-target choices when sensors are attached, removed or replaced;
vehicle-specific parameter descriptions, units, defaults, ranges, bitmasks and enum labels;
continuing to use bundled ArduPilot metadata when a vehicle does not publish component metadata.

The live metadata overlay has exact-name priority and also supports parameter templates. Invalid documents fail closed and do not replace the last valid snapshot.

Parameter import reliability

The parameter loader is also made tolerant of parameter files from another firmware version or feature set:

parameters absent from the connected vehicle are skipped instead of blocking the whole import;
PARAM_SET uses the live parameter's MAVLink type;
rejected values stop retrying after the existing bounded retry budget and are reported as skipped;
retry timers and state are cleaned up when the dialog completes or closes.

This allows a useful subset of a parameter file to be applied without leaving the loader permanently failed because optional parameters are unavailable.

mavlink2rest compatibility

COMPONENT_METADATA is not available through the previously pinned mavlink2rest release. Version 0.11.26 adds it through rust-mavlink 0.10.13 while preserving the existing 0.11 JSON API.

Validation

ArduPilot Manager parameter-metadata tests: 9 passed.
Frontend parameter-metadata tests: 8 passed.
Targeted ESLint and Stylelint: passed.
Ruff and Mypy checks for the changed Python paths: passed.
Official mavlink2rest 0.11.26 artifacts resolved for x86_64, ARMv7 and AArch64.
Live ARMv7 Raspberry Pi 4 and AArch64 Raspberry Pi 5 testing: BlueOS startup/shutdown, metadata advertisement, MAVFTP retrieval, ETag refresh, fallback selection and parameter-table rendering passed.

CLAassistant · 2026-07-31T15:04:28Z

All committers have signed the CLA.

patrickelectric · 2026-08-03T18:37:06Z

@JackSkellet can you rebase the PR over master ?

JackSkellet · 2026-08-04T01:17:07Z

@patrickelectric rebase has been completed.

patrickelectric · 2026-08-04T16:25:24Z

 set -e

-VERSION="t0.11.25"
+VERSION="1.0.2"


you should not update mavlink2rest since it breaks the api from 0.X to 1.X.

t0.11.25 does not contain the COMPONENT_METADATA message (ID 397) required by this implementation. That message becomes available in mavlink2rest 1.0.x, but I understand that upgrading breaks the existing API. Would you prefer an API-compatible 0.x backport of message 397, or an alternative BlueOS integration path?

The best way to workaround that, is to..
Send a PR to https://github.com/mavlink/rust-mavlink/tree/0.10 (0.10 branch), with a patch commit like this one mavlink/rust-mavlink@b0da5b2 and a update version commit like this one mavlink/rust-mavlink@b210832. After that, I will create a release.
With that done, we can then create a 0.x-dev branch to release an API compatible update mavlink2rest release.

JackSkellet · 2026-08-04T21:19:35Z

rust-mavlink 0.10 backport: mavlink/rust-mavlink#527

Tested on BlueOS with mavlink2rest 0.11.25; parameter metadata loads successfully.

patrickelectric · 2026-08-05T21:32:30Z

check: #4089

JackSkellet · 2026-08-05T22:41:54Z

Updated to mavlink2rest 0.11.26 and reverted the temporary 1.x compatibility handling, restoring the existing BlueOS MAVLink code paths. Parameter metadata now decodes correctly on a live BlueOS system, while the remaining message handling works as before.

ES-Alexander

Thanks for the contribution @JackSkellet! :D

From some internal discussion, MAVLink Server includes MAVFTP support, and using its API for that would be a preferred approach over re-implementing MAVFTP handling in the ardupilot manager service.

ES-Alexander · 2026-08-06T20:41:02Z

    await fetchFirmwareVehicleType() // required to populate autopilot.vehicle_type
    const jsons = ardupilotParamPaths
-    let folder = "Copter"
+    let folder = 'Copter'


Was there a reason for this change (and the others like it)?

We generally avoid cleaning up code that we aren't already touching for other reasons, outside of occasional dedicated cleanup commits.

Ah, yes might have missed those, i had been doing some other unrelated changes on this branch. and then once i made the split, some of those changes might have slipped through.

i can revert those if that is prefered, so we keep the changes to a minimum.

photo of said unrelated work:

As for the Mavlink Server. i will switch this implementation to the API later today.

i looked into the MAVLink Server API and tested it.
The API receives the complete Metadata file, but then discards it when TerminateSession returns an EOF NAK. So there might be some cleaup handilng error going on here, unless i am missing something.

so should i make another Pull request over there for this specific issue?

The API receives the complete Metadata file, but then discards it when TerminateSession returns an EOF NAK. So there might be some cleaup handilng error going on here, unless i am missing something.

@patrickelectric thoughts on this^?

i can revert those if that is prefered, so we keep the changes to a minimum.

Yes please. Minimal changes are easier to review, including after a PR has merged (e.g. when inspecting the commit history to investigate something that's gone wrong).

Hi @JackSkellet can you describe exactly what you are doing for me to replicate your issue ? If you use the mavlink-server GUI, does it work ?

JackSkellet force-pushed the codex/dynamic-parameter-metadata branch from 8f65459 to f4818af Compare July 31, 2026 20:49

JackSkellet added 8 commits August 4, 2026 03:08

core: update mavlink2rest message serialization

113a23c

core: add vehicle parameter metadata transport

fe85e38

test: cover vehicle parameter metadata transport

fc28a0c

core: expose fresh vehicle parameter metadata

2b070d9

frontend: normalize vehicle parameter metadata

6d8dc4a

frontend: refresh metadata when opening parameters

2c6ca3e

frontend: finish parameter loads after rejected values

77f8b4a

frontend: disable Sentry upload without credentials

fcbb104

JackSkellet force-pushed the codex/dynamic-parameter-metadata branch from f4818af to fcbb104 Compare August 4, 2026 01:14

patrickelectric requested changes Aug 4, 2026

View reviewed changes

core: accept mavlink2rest character-array metadata URIs

2443f08

JackSkellet mentioned this pull request Aug 4, 2026

Backport COMPONENT_METADATA to 0.10 mavlink/rust-mavlink#527

Merged

core: use mavlink2rest 0.11.26

0531528

JackSkellet force-pushed the codex/dynamic-parameter-metadata branch from a1e015f to 0531528 Compare August 5, 2026 22:34

ES-Alexander requested changes Aug 6, 2026

View reviewed changes

Uh oh!

Conversation

JackSkellet commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why

Parameter import reliability

mavlink2rest compatibility

Validation

Uh oh!

CLAassistant commented Jul 31, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

patrickelectric commented Aug 3, 2026

Uh oh!

JackSkellet commented Aug 4, 2026

Uh oh!

patrickelectric Aug 4, 2026

Choose a reason for hiding this comment

Uh oh!

JackSkellet Aug 4, 2026

Choose a reason for hiding this comment

Uh oh!

patrickelectric Aug 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JackSkellet commented Aug 4, 2026

Uh oh!

patrickelectric commented Aug 5, 2026

Uh oh!

JackSkellet commented Aug 5, 2026

Uh oh!

ES-Alexander left a comment

Choose a reason for hiding this comment

Uh oh!

ES-Alexander Aug 6, 2026

Choose a reason for hiding this comment

Uh oh!

JackSkellet Aug 7, 2026

Choose a reason for hiding this comment

Uh oh!

JackSkellet Aug 7, 2026

Choose a reason for hiding this comment

Uh oh!

ES-Alexander Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

patrickelectric Aug 7, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

JackSkellet commented Jul 31, 2026 •

edited

Loading

CLAassistant commented Jul 31, 2026 •

edited

Loading

patrickelectric Aug 4, 2026 •

edited

Loading

ES-Alexander Aug 7, 2026 •

edited

Loading