6de07ecf77
Per-motor model-based motor-failure detector for multirotors. Predicts the expected ESC current from the commanded actuator signal (I_exp = a*u^2 + c) and trips on a low-pass-filtered residual held above a threshold for a persistence time. The command (not measured rpm) is the fault-independent reference: a dead motor that draws no current while still commanded produces a large residual, whereas a current-vs-rpm model would mask a clean stop. The trip test is two-sided (|LPF(residual)| >= threshold), so it covers both under-current faults (open circuit, shed propeller, desync) and over-current faults (winding short, mechanical jam, demagnetization). Faults are caught only outside a dead band around the healthy current; mid-range partial losses fall inside it. The threshold is throttle-relative: threshold_a + threshold_rel*I_expected. The empirical healthy residual floor is a roughly constant noise term plus a fraction of the expected current, so an affine band tracks it better than a flat one -- tighter at low/mid throttle, wider only at high throttle. threshold_rel = 0 recovers a flat threshold. Built on PX4 primitives rather than hand-rolled equivalents: update() takes a timestamp (esc_status.timestamp in flight, the log timestamp in replay) and derives dt internally; the residual filter is a mathlib AlphaFilter; the persistence debounce is a systemlib::Hysteresis (with a sticky latch on top, and reset across data gaps so a dropout can't complete a pending trip). The data-gap threshold (kMaxGap = 0.3 s) is sized above the ~10 Hz arming-check feed interval and below the 400 ms ESC-offline timeout: a live feed is never mistaken for a gap (a smaller value equal to the feed interval reset the filter and debounce on the majority of jittered ticks, so a sustained fault never survived the persistence window -- offline replay: 0/100 sampling phases latched vs 100/100 gap-free), while a genuine outage still resets and is handled by the separate ESC liveness guard. Operator thresholds must then be tuned against the accumulated healthy residual (roughly an affine ~1.92 + 0.131*I_expected band); shipped MOTFAIL_* defaults stay 0 (monitor-only), so default behavior is unchanged. Includes a 17-case gtest spanning the failure-mode spectrum and edge cases: healthy-never-trips (incl. high throttle), open-circuit and over-current trips, severe prop-loss under-current, the missed ~50% partial loss (documents the detection floor), throttle-relative band scaling, persistence (short-spike crosses-threshold-but-recovers), gap reset, the 10 Hz feed vs. real-gap boundary, dropout-holds, multi-motor, the exclusion gate, monitor-only, and reset/latch.
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.
