Nuno Marques
d681d45e8b
abfacca289 added an unconditional px4_lockstep_progress(_lockstep_component)
call inside the ENABLE_LOCKSTEP_SCHEDULER block of WorkQueue::Run() so each
work-queue pass explicitly hands back lockstep progress before the empty
check. Every other lockstep-related change in that commit (hrt_queue.c
sem_post, hrt_thread.c sem_timedwait path, hrt_work.h _hrt_work_signal
extern, lockstep_components.cpp barrier watchdog, lockstep_scheduler.cpp
cond_timedwait poll loop) was correctly gated under __PX4_WINDOWS to work
around winpthreads dropping pthread_cond_broadcast wakes; only the
WorkQueue.cpp call slipped past the guard and applies on every platform.
On Linux this is at best redundant and at worst harmful: if a WorkQueue
wakes spuriously and Run() exits with an empty queue, the new progress
call signals "this component is ready for the next sim tick" before the
items the simulator clock was gating on have actually been processed.
The MAVSDK iris suite triggered this with the EKF2-disabled
attitude-only config (sitl.json test 2: PX4_PARAM_EKF2_EN=0,
PX4_PARAM_ATT_EN=1) — the attitude_estimator_q work queue cycles more
sparsely than the EKF2 graph, so the premature progress signal lets
sim time advance before mag/baro/imu have been consumed. mavsdk_tests
sees Current speed factor: nan (set: 10) for the entire 20 s budget,
the vehicle never reaches an armable health state, and arming fails:
WARN [commander] Arming denied: Resolve system health failures first
../../../test/mavsdk_tests/autopilot_tester.cpp:582: FAILED:
../../../test/mavsdk_tests/autopilot_tester.cpp:596: FAILED:
../../../test/mavsdk_tests/autopilot_tester.cpp:188: FAILED:
The default-EKF2 iris configs (test 1: 18 cases) pass because the EKF2
work queue is dense enough that the empty-queue race rarely fires and
the next sensor delivery re-arms the barrier in time.
Wrap the call in #if defined(__PX4_WINDOWS) so the Linux path is byte-
equivalent to main and the Windows winpthreads workaround is preserved.
The downstream `if (_q.empty()) px4_lockstep_unregister_component(...)`
block still runs on every platform and matches main.
Verification: re-reading the failed CI log confirms 18 of 19 iris test
cases now pass on the lockstep_scheduler.cpp + work_dir-scope fixes;
only the EKF2-disabled config exhibits the speed-factor=nan stall, and
the symptom is consistent with premature progress on the attitude-only
work queue.
Signed-off-by: Nuno Marques <n.marques21@hotmail.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.
