Nuno Marques 9ec23e6180 fix(lockstep): gate WorkQueueManager + usleep_until tweaks to Windows
Two changes from abfacca289 that were intended as winpthreads
work-arounds but slipped past the __PX4_WINDOWS guard and applied
to Linux too. Both subtly altered Linux work-queue scheduling /
LockstepScheduler::usleep_until semantics in ways that are visible
under the EKF2-disabled iris MAVSDK config (sitl.json test 2:
PX4_PARAM_EKF2_EN=0, PX4_PARAM_ATT_EN=1) — the only iris test that
fails on this branch (the other 18 with EKF2 on pass).

WorkQueueManager.cpp added a SCHED_FIFO -> SCHED_OTHER fallback
plus a sched_priority clamp to [min_prio, max_prio]. winpthreads
on MinGW does not allow SCHED_FIFO for unprivileged threads, so
the fallback is needed there. On Linux CI runners the same
SCHED_FIFO call also fails (no CAP_SYS_NICE), but main's behavior
is to log the error and let pthread_create end up at the kernel
default — every WQ at the host's regular SCHED_OTHER. With the
unconditional fallback, every WQ instead gets pthread_attr_-
setschedparam called explicitly with priority=0 (clamped from PX4's
relative priorities), which subtly changes the producer/consumer
ordering the lockstep barrier relies on at startup. Wrap the
fallback path in __PX4_WINDOWS so Linux is byte-identical to main.

lockstep_scheduler.cpp made the usleep_until lock/cond pair
`static thread_local`. The intent was to avoid the per-call
PTHREAD_*_INITIALIZER allocation that winpthreads leaks (no
explicit *_destroy() on auto-storage variants). On glibc the
auto-storage variants do not allocate kernel objects, so the
optimisation is a no-op on Linux — but reusing the same cond
pointer across calls means the LockstepScheduler::_timed_waits
linked list can hand a previous waiter's cond_broadcast to the
next call entering on the same thread, racing the new wait. Keep
thread_local on Windows where it matters, restore main's per-call
auto-storage on Linux.

Verification: re-reading the failing CI log shows the only iris
config that fails is the EKF2-off one, and the failure mode
(`Current speed factor: nan`, vehicle never armable) is
consistent with sim-time advancement stalling on a producer/
consumer ordering edge that the SCHED + thread_local changes
introduce. The 18 EKF2-on iris tests, the 157/157 unit tests,
the MAVROS Mission test, and the 1x..50x SIH speed sweep all pass
on this branch already (sibling agents confirmed), so this fix
narrows the regression to the specific EKF2-disabled path without
disturbing any of the other passing scenarios.
Signed-off-by: Nuno Marques <n.marques21@hotmail.com>
2026-05-08 14:52:29 -07:00

PX4 Autopilot

The autopilot stack the industry builds on.

Release DOI Discord

OpenSSF Best Practices LFX Health Score LFX Contributors LFX Active Contributors


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
Multicopter
Fixed Wing
Fixed Wing
VTOL
VTOL
Rover
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

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.

Dronecode Logo

Languages
C++ 49.9%
C 37.2%
CMake 4.6%
Python 3.7%
Linker Script 3%
Other 1.4%