Add human-readable labels and firmware classification to the build
manifest so ground stations like QGC can display friendly names and
filter builds by category.
New fields:
- label_pretty: human-readable variant name (e.g. "Multicopter")
- firmware_category: auto-detected classification
- "vehicle" for multicopter, fixedwing, vtol, rover, uuv, spacecraft
- "peripheral" for CAN sensor nodes (GPS, flow, mag, etc.)
- "bootloader" for bootloader/canbootloader
- "dev" for everything else (default, zenoh, mavlink-dev, etc.)
Peripheral detection uses ROMFSROOT="cannode" which is shared by all
~18 CAN sensor boards across ARK, Holybro, CUAV, Freefly, Matek, NXP.
A build-time warning fires when an unrecognized label falls through to
"dev", so new vehicle types are not silently hidden from end users.
Boards can override via CONFIG_BOARD_FIRMWARE_CATEGORY in .px4board.
CONFIG_BOARD_LABEL_PRETTY set on all px4/fmu-v6x variants as Phase 1.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Replace the two-tier approach (per-release manifest + top-level index)
with a single unified manifest containing all releases and their builds
inline. This allows QGC to fetch one file to find firmware for any board
across all releases, avoiding the need to fetch many per-release manifests.
Schema uses format_version 2 with releases as a dict keyed by version
for O(1) upserts. The manifest is stored at s3://px4-travis/Firmware/manifest.json
and updated on every CI build (tags + main/stable/beta branches).
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Ramon Roche