SaibernardandJacob Dahl
27d3a62df1
* feat(commander): name the GNSS reason when position is lost in flight When GNSS goes bad in flight and takes the local position estimate with it, the operator got "GNSS data fusion stopped" about two seconds after the position went, and nothing said why. EKF2 computes which receiver check failed every cycle and publishes it in estimator_status.gps_check_fail_flags, and outside of spoofing and jamming commander only reports those bits while disarmed. A receiver that stops sending altogether sets no bit at all. Report it the moment the local position estimate becomes invalid in flight, when GNSS position was fused within the last ten seconds. A failing check gives one event carrying every failing check as a bitfield, a receiver whose last sample is over a second old gives one event saying so, and boards with room for it also get a statustext. A vehicle that never fused GNSS gets nothing, since neither says anything about why its estimate went. What the estimator decides is untouched. In flight EKF2 raises only the fix, horizontal, vertical and speed accuracy, spoofing and jamming checks, so any bit set at that moment is a real cause. Once the position is invalid the existing fusion stopped event already drops to Info, so the log now reads reason, then consequence. Closes #24355 Assisted-by: Claude:claude-fable-5-1 Signed-off-by: Saibernard Yogendran <bernie97@seas.upenn.edu> * test(commander): cover the GNSS reason reported when position is lost Eight cases on EstimatorChecks driven directly, with the failsafe flags kept across cycles as commander keeps them: the failing check is named when position is lost in flight, with every bit in the event, it is reported once and not again while the position stays lost, spoofing is named ahead of an accuracy check, a receiver that stopped sending is named as such, and nothing is reported when no check fails with the receiver alive, when GNSS was not in use, when the vehicle has no GNSS configured, or while disarmed. Without the change four of them fail. Assisted-by: Claude:claude-fable-5-1 Signed-off-by: Saibernard Yogendran <bernie97@seas.upenn.edu> * fix(commander): remember the failing GNSS checks and name a silent receiver first The flags in estimator_status describe only the newest sample, while EKF2 keeps rejecting samples for at least a second after one failed and keeps fusing for up to seven, so the check that kept GNSS out can have passed again by the time the position goes and nothing was reported. Every check that failed is now remembered until none has failed for the same ten seconds that bound the recently fused window. EKF2 runs the checks only on new samples, so a receiver that stopped keeps the flags of its last sample. The silence is tested first and is the reason reported. The statustext could never be sent. Commander runs the checks without a mavlink log publisher first, that pass consumes the position validity edge, and the legacy pass that has the publisher sees the flag already set. The event reaches the ground station and the log on its own, so the statustext, its text selection and the test hook for it are gone. Assisted-by: Claude:claude-fable-5-1 Signed-off-by: Saibernard Yogendran <bernie97@seas.upenn.edu> * test(commander): cover a check that cleared before position was lost Two more cases: the check fails on one sample and passes on the next, and the position goes a cycle later, which still names that check; and a receiver that stops after a failing sample is reported as silent rather than as that check. The statustext assertions are gone with the statustext. Assisted-by: Claude:claude-fable-5-1 Signed-off-by: Saibernard Yogendran <bernie97@seas.upenn.edu> * fix(commander): expire each failed GNSS check on its own timer The shared latch cleared only after ten seconds without any failure, so a check that kept flapping held every earlier failure in the reason, e.g. a one-off spoofing flag or a drift check from the ground before takeoff. Each check now drops out ten seconds after it last failed. The fail time is the estimator_status timestamp, when EKF2 reported the check, which also lets the test age a report. Assisted-by: Claude:claude-opus-5-5 --------- Signed-off-by: Saibernard Yogendran <bernie97@seas.upenn.edu> Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.com>
The autopilot stack the industry builds on.
About
PX4 is an open-source autopilot stack for drones and unmanned vehicles. It supports multirotors, fixed-wing, VTOL, rovers, and many more experimental platforms from racing quads to industrial survey aircraft. It runs on NuttX, Linux, and macOS. Licensed under BSD 3-Clause.
Why PX4
Modular architecture. PX4 is built around uORB, a DDS-compatible publish/subscribe middleware. Modules are fully parallelized and thread safe. You can build custom configurations and trim what you don't need.
Wide hardware support. PX4 runs on a wide range of autopilot boards and supports an extensive set of sensors, telemetry radios, and actuators through the Pixhawk ecosystem.
Developer friendly. First-class support for MAVLink and DDS / ROS 2 integration. Comprehensive SITL simulation, hardware-in-the-loop testing, and log analysis tools. An active developer community on Discord and the weekly dev call.
Vendor neutral governance. PX4 is hosted under the Dronecode Foundation, part of the Linux Foundation. Business-friendly BSD-3 license. No single vendor controls the roadmap.
Supported Vehicles
 Multicopter |
 Fixed Wing |
 VTOL |
 Rover |
…and many more: helicopters, autogyros, airships, submarines, boats, and other experimental platforms. These frames have basic support but are not part of the regular flight-test program. See the full airframe reference.
Try PX4
Run PX4 in simulation with a single command. No build tools, no dependencies beyond Docker:
docker run --rm -it -p 14550:14550/udp px4io/px4-sitl:latest
Open QGroundControl and fly. See PX4 Simulation Quickstart for more options.
Build from Source
git clone https://github.com/PX4/PX4-Autopilot.git --recursive
cd PX4-Autopilot
make px4_sitl
Note
See the Development Guide for toolchain setup and build options.
Documentation & Resources
| Resource | Description |
|---|---|
| User Guide | Build, configure, and fly with PX4 |
| Developer Guide | Modify the flight stack, add peripherals, port to new hardware |
| Airframe Reference | Full list of supported frames |
| Autopilot Hardware | Compatible flight controllers |
| Release Notes | What's new in each release |
| Contribution Guide | How to contribute to PX4 |
Community
- Weekly Dev Call — open to all developers (Dronecode calendar)
- Discord — Join the Dronecode server
- Discussion Forum — PX4 Discuss
- Maintainers — see
MAINTAINERS.md - Contributor Stats — LFX Insights
Contributing
We welcome contributions of all kinds — bug reports, documentation, new features, and code reviews. Please read the Contribution Guide to get started.
Citation
If you use PX4 in academic work, please cite it. BibTeX:
@software{px4_autopilot,
author = {Meier, Lorenz and {The PX4 Contributors}},
title = {{PX4 Autopilot}},
publisher = {Zenodo},
doi = {10.5281/zenodo.595432},
url = {https://px4.io}
}
The DOI above is a Zenodo concept DOI that always resolves to the latest release. For a version-pinned citation, see the Zenodo record or our CITATION.cff.
Governance
The PX4 Autopilot project is hosted by the Dronecode Foundation, a Linux Foundation Collaborative Project. Dronecode holds all PX4 trademarks and serves as the project's legal guardian, ensuring vendor-neutral stewardship — no single company owns the name or controls the roadmap. The source code is licensed under the BSD 3-Clause license, so you are free to use, modify, and distribute it in your own projects.
