Jacob Dahl
bb75224d6d
* feat(afbrs50): static rate/DFM profiles, pipeline hardening, range offset calibration The distance-based short/long range switching only re-evaluates after a valid measurement, so once the target leaves the range the driver latches short-range mode and the sensor stays blind; frames that fail evaluation were never published, leaving consumers on the stale last value. Flight characterization of the LV85D and LX85D showed frame rate is the dominant range knob and DFM 4X beats the mode-default 8X on validity, spread and wrong-window returns at every rate, so the switching is replaced by SENS_AFBR_RATE / SENS_AFBR_DFM / SENS_AFBR_PROF with per-module defaults, SENS_AFBR_MODE gains Auto (module default) with fallback when the API rejects a mode, and the rate is clamped to the API's 5 Hz frame-time floor that previously put CONFIGURE in a silent retry loop. Invalid or quality-gated (SENS_AFBR_QMIN) frames now publish max_distance + 1 with quality 0 so uavcannode emits TOO_FAR, and the max distance is bounded by the configured unambiguous range. Pipeline fixes: measurementReadyCallback dereferenced g_dev after its null check, stop() deleted the object while a callback could still arrive, the DRDY interrupt stayed bound to the destroyed handle, S2PI_Abort left the bus BUSY forever, S2PI_Init leaked on restart, setRateAndDfm spun unbounded, and a lost completion callback or wedged device stalled the state machine for good. Non-OK result codes are counted by name for 'afbrs50 status'. 'afbrs50 cal' runs the vendor absolute range offset calibration on a low-priority task (the sequence busy-waits and would starve the IWDG feeder on wq:uavcan) and persists the offsets to SENS_AFBR_OFS_LO/HI. * fix(afbrs50): evaluate every completed frame and guard CONFIGURE against stale completions Argus_EvaluateData is what releases the API's raw data buffer, and the API refuses new measurements and rejects configuration writes once two buffers are held. An error-status callback skipped it, so two bad frames wedged the driver into the stall recovery with nothing published. The abort completion of that recovery, arriving from the SPI thread, could overwrite CONFIGURE with TRIGGER and skip the reconfigure. Also note the removed parameters in the 1.18 release notes. * refactor(afbrs50): run the driver in its own task and the SPI transfers on the bus work queue The transfer work item ran on wq:SPI0 (which does not exist on STM32 targets) purely for its near-top priority: before API 1.6.6 a DRDY firing within ~60 us of the last SPI clock was lost unless the transfer callback had already run. Since 1.6.6 ADS_SPI_Callback re-checks the IRQ pin and recovers a DRDY that arrives before the callback, so the deadline is gone and the transfer item can live on the work queue of the bus the sensor actually sits on, at its conventional priority. The blocking exchange stays on a work queue because the API requests transfers from hrt interrupt context. The state machine cannot share that thread: the API's configuration calls spin in ADS_AwaitIdle until the transfer they queued completes. It previously borrowed hp_default, whose 2800 byte stack Argus_EvaluateData overflows and whose priority puts the driver's blocking configuration waits ahead of dshot and pwm_out. It now runs as a SCHED_PRIORITY_SLOW_DRIVER task woken by the completion callback through a semaphore, so the range offset calibration no longer needs its own task either: the driver drops to SCHED_PRIORITY_DEFAULT for the duration of the sequence, below the wq:uavcan IWDG feeder, and a stop request aborts it. * fix(afbrs50): publish only NO_OBJECT as too far, reinit on stuck CONFIGURE, protect calibration Every evaluation failure and quality-gated frame went out as max_distance + 1, which collision prevention clamps to max_distance and enters as free space regardless of signal_quality, so a sensor fault on a horizontal mount cleared a real obstacle. Only the device's own STATUS_ARGUS_NO_OBJECT is published that way now; errors and gated frames are counted and left to the consumers' stream timeouts. CONFIGURE drains a raw buffer an abort may leave behind, since the API rejects configuration writes until it is evaluated, and falls back to Argus_ReinitMode after ten consecutive failures because a sticky error status never returns to IDLE on its own. The vendor calibration sequence blocks longer than ModuleBase's 5 s stop deadline while holding pointers into the task stack, so 'afbrs50 stop' is refused while it runs and a stop clears a not-yet-started request. The sequence also rewrites the per-pixel offset tables, which cannot be persisted; they are restored afterwards so the sensor runs in the state the stored global offsets re-create at boot. The destructor now also stops the API's periodic timer, the last path that could reach the completion callback after ModuleBase has deleted the instance. * fix(afbrs50): publish invalid frames with signal quality 0 instead of dropping them Dropping errored and quality-gated frames left a receiver unable to tell a sensor returning invalid readings from one that fell off the bus. Every frame is published again with signal_quality 0 marking the invalid ones. The distance sent with it is chosen for collision prevention, which ignores quality: NO_OBJECT stays beyond max_distance (free space, TOO_FAR on DroneCAN), errors carry min_distance (discarded, UNDEFINED on DroneCAN), and a gated frame keeps its measured distance with the quality floored to 0.
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.
