We’re reworking the build system underneath the per-vehicle-type firmware effort (Jake’s #27667). A few things are converging that the current model can’t cleanly express, so we’re addressing the foundation rather than working around it.
The problem. Today a build is board + one label, and that single label is overloaded to mean four different things: what vehicle it is, what dev flavor, whether it’s a bootloader, whether it’s a CAN peripheral. That overload is the root of a lot of friction. The manifest work has to guess a build’s purpose from its name, VOXL2’s two-processor build is wired by hand, and there’s no clean path to a new RTOS.
The model. A build is really a point on a few independent axes: board, runtime (RTOS), vehicle class, and variant. We’re already multi-RTOS today. NuttX, QuRT on the DSP, and Linux are all in the tree, we just never named runtime as an axis. VOXL2 already ships two of those from one board. Zephyr would be the fourth runtime, not the first.
What changes. We’re separating those axes. PX4 owns a canonical definition of each vehicle class; vendors tune it in-tree as a small additive delta, never a fork, so upstream improvements propagate everywhere automatically. Runtime becomes a real axis, so the same copter builds on NuttX or Zephyr. One board can declare multiple bundled artifacts as a first-class thing. And the target name becomes self-describing: px4.fmu-v6x.nuttx.copter instead of a cryptic string.
Status. This builds directly on Jake’s #27667, which already landed the foundation (canonical target_classes, the layered merge), so we’re extending that work, not competing with it. I’ve written up the conceptual model and done a full blast-radius inventory of what the target-name change touches (CI, SBOM, the manifest, docs, firmware-embedded URLs). It’s a big surface, so it’ll roll out in coordinated steps rather than one cut.
Proposal: v2.0. A change this size ripples through almost everything in PX4 and the ecosystem around it. I’m proposing we mark it with a major version bump to v2.0, giving downstream and supporting projects a clear line to break cleanly from older patterns rather than straddling both.
What this means for QGroundControl. We’ll carry the QGC-side implementation ourselves: fetching the new artifacts, installing the right firmware to the right hardware, and exposing the right metadata so users always know exactly what they’re flashing. As part of that, we’re drawing a clear line between stable hardware, boards that are flown, regularly tested, and maintained, and experimental hardware. Users should know what to expect from a board before they install it, and that distinction ships as part of v2.0.
For other MAVLink consumers. We don’t expect much to change, but we’ll keep an eye out and flag anything that does.
For internal PX4 tooling. A lot of our own tooling currently relies on hardcoded paths and filename patterns that won’t be valid anymore: SBOM generation, the CI build farm, and a long tail of smaller utilities. We’re updating all of it, and we won’t cut a release until everything internal is updated and working.
What we need from you. Think about how this affects your downstream project. If you have input or concerns, now is the time, jump into the PRs and comment. We’ve been putting this off for years, and we finally have the time and resources to commit to it, so we’re moving fast and a clean break is the direction. Feedback is due now. If you’re content to adapt later as a consumer, at least start thinking about how this reaches you so you can plan for it.
And of course, nothing ships stable without flight testing. The flight test team is ready to engage.
Hello, I’m working on the Septentrio GNSS drivers (positioning), and would like to specifically discuss resilience reporting and the MAVLink GNSS_INTEGRITY message (in particular, its potential inclusion in common.xml). In addition, I would also like to discuss an idea for a PR regarding the QGroundControl UI to authenticate Galileo satellites.
Hello, I would like to discuss some work / analysis on Prop Wash barometer compensation approaches that @dakejahl had put together and I’ve been testing and looking into SITL CI simulation using OpenFOAM. Looking for community feedback and talking about other approaches that Ardupilot is using for weighted measurement / covariance weighting approaches during takeoff and landing.
