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>
Split the maintainer role into two types to make it easier to grow the
bench without asking new contributors to commit to a specific component
up front. Code Owners keep their existing scoped responsibility for a
category, while Reviewers help across the project without ownership of
any specific area. Both are full maintainers, share the @PX4/dev-team
GitHub team, and have the same write access and voting rights.
Rename the Active Maintainers table to Code Owners with no change to
the current roster. Add an empty Reviewers table so future nominations
land in their own PRs. Update the contributor docs to describe the two
types, cover both in the recruitment and onboarding flow, and note the
promotion path from Reviewer to Code Owner.
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
The asset file was renamed from X25-EVO.jpg to x25_evo.jpg in git but
all four locale files (en, ko, uk, zh) still referenced the old name.
macOS hid this because its filesystem is case-insensitive, but Linux CI
(case-sensitive) intermittently failed to resolve the reference during
Rollup bundling.
Fixes#26958
Signed-off-by: Ramon Roche <mrpollo@gmail.com>
Several helper scripts assumes bash is available at /bin/bash. That breaks on systems
such as NixOS, where bash is resolved from PATH instead of a fixed /bin location and
causes failures like `bad interpreter` during `make format`, e.g., on my host machine:
```sh
$ make format
/PX4-Autopilot/Tools/astyle/check_code_style.sh: /PX4-Autopilot/Tools/astyle/fix_code_style.sh: /bin/bash: bad interpreter: No such file or directory
```
This change switches these entrypoints to `#!/usr/bin/env bash` so they locate bash properly.
No functional changes intended.
Signed-off-by: Onur Özkan <work@onurozkan.dev>
