Jacob Dahl
4af7b4e77e
* fix(uavcannode): publish UNKNOWN until time-synced and fix RawIMU integration_interval units The RawIMU and RangeSensor publishers computed the bus timestamp as getUtcTime() - (hrt_now - sample_hrt). getUtcTime() is 0 until the time-sync master disciplines the node's clock, so the unsigned subtraction underflowed and the truncated uint56 field went out as ~7.2e16 us. Publish UNKNOWN until the clock is disciplined, from one shared helper. RawIMU.integration_interval is specified in seconds but was assigned vehicle_imu.delta_angle_dt, which is in microseconds. * fix(uavcan): map node timestamps through the bus time base in the sensor bridges The accel, gyro and rangefinder bridges took msg.timestamp.usec verbatim as timestamp_sample whenever it was non-zero, which assumes the bus shared time base is HRT. It is not: the FC seeds its bus clock from HRT only after its own init has run, so the base leads HRT by that duration, and the FC may also be a slave to a lower node ID master. An undisciplined node, or one stamping a foreign epoch, put the sample time arbitrarily far from HRT. The CAN ISR stamps every received transfer in the same bus base the node used, so the sample age is the difference between the two. Bound that age to a plausible transport window and subtract it from the receive time, falling back to the receive time otherwise, in one shared helper. * fix(uavcan): stamp RelPosHeading and BatteryInfoAux in the bus base, map RelPosHeading on the FC Both node publishers put node-local time into a bus-base field, and the FC took the RelPosHeading stamp verbatim as HRT. Same defect as RawIMU and RangeSensorMeasurement, same two helpers. * fix(uavcan): read the bus clock and HRT together when mapping node timestamps The ISR receive stamp is taken at the first frame of a transfer while HRT was read in the callback, so the transfer and scheduling latency stayed in timestamp_sample as jitter. Sampling both clocks at the same instant cancels the bus-to-HRT offset exactly. The node-side helper takes the node for the same reason. The FC bus base leads HRT by the free-running timer phase at seeding, not by the init duration; correct the comment. * fix(uavcan): send true point samples in RawIMU and consume the integral on the FC RawIMU.*_latest carried the window mean, delta / integration_interval, under a field the DSDL defines as the latest point sample. The mean lags the message timestamp by half the interval, 2.5 ms at IMU_INTEG_RATE 200, and the FC published it as an instantaneous rate at the window end. The node now fills *_latest from the sensor_gyro / sensor_accel instance behind vehicle_imu, the same batch-end sample every PX4 IMU driver produces, and keeps the integrals and timestamp as they were. The FC bridges now consume the integral when one is present: divided by its interval it is float32 rather than float16, anti-aliased against the node's full-rate stream, and successive means spaced one interval apart integrate back to the node's exact delta angle in VehicleIMU. It is stamped at the window centroid. The point sample is used only when the node reports no integral, as the DSDL specifies.
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.
