4e8f38ff87
* fix(ekf2): reject GNSS samples with vel above EKF2_VEL_LIM in EKF instead of in the on ground GNSS checks * fix(ekf2): drop the GNSS yaw coupling from the velocity limit skip path GNSS yaw fusion has had its own buffer and stopped-data timeout since the heading moved to its own topic, and stopGnssFusion() no longer clears gnss_yaw. Keeping gnss_yaw in using_gnss left it true after the first stop, so stopGnssFusion() and the EKF-GSF reset re-fired on every skipped sample while yaw fusion was active, and the yaw-only timeout test could no longer pass. Assisted-by: Claude:claude-fable-5-1 * fix(ekf2): keep the GNSS checks running while over-limit samples are skipped Short-circuiting the checks on an over-limit sample froze the published fail flags and checks_passed at the last evaluated sample for the whole timeout window, and the eventual stop was reported as poor quality. The checks now run on every sample so their status stays truthful, the velocity limit is its own skip reason with its own stop message, and the skipped samples are counted in an EKF2 perf counter so the ulog shows why nothing was fused until estimator_status gains a fusion-state flag. Assisted-by: Claude:claude-fable-5-1 * fix(ekf2): apply EKF2_VEL_LIM per axis to GNSS velocity samples constrainStates() clamps each velocity component to EKF2_VEL_LIM, so the state can hold a horizontal speed up to sqrt(2) times the limit. Testing the horizontal norm rejected samples the filter could represent, and a vehicle between 100 and 141 m/s ground speed lost GNSS after the timeout. The gate now uses the same per-axis test as the clamp, and the parameter description says that samples beyond it are rejected. Assisted-by: Claude:claude-fable-5-1 * fix(ekf2): stop GNSS height fusion when the checks time out Height control only evaluates its fusion timeout under _gps_data_ready and its no-data branch keys on the buffer push time, which keeps advancing while samples are skipped. With HPOS and VEL disabled, a sustained check failure or over-limit velocity therefore left gps_hgt latched with nothing fused and the height reference never released. Including gps_hgt in the skip-path timeout stops it with the other GNSS aiding. Assisted-by: Claude:claude-fable-5-1 * fix(ekf2): drop the parameter name from the velocity limit stop message No other ECL message names a parameter. Assisted-by: Claude:claude-fable-5-1 * refactor(ekf2): drop the velocity limit skip counter The skipped sample still reaches updateGnssVel(), so its velocity is logged in estimator_aid_src_gnss_vel.observation with fused false while the check flags stay clear, which already names the cause. The count-delta between the EKF library and the module was scaffolding for a rare case, and a fusion-state flag in estimator_status is the planned indication. The tests observe the behaviour instead: a skipped sample stops the fusion after the timeout, an accepted one at the limit resets to it and continues. Assisted-by: Claude:claude-fable-5-1 --------- Co-authored-by: jonas <jonas.perolini@rigi.tech> 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.
