90913df7de
* feat(gps): inject SPARTN corrections alongside RTCM Add a SPARTN transport-layer framer and feed gps_inject_data through both RTCM3 and SPARTN parsers so PointPerfect-style SPARTN streams can be reassembled and written to the receiver the same way RTCM already is. Gated by CONFIG_GPS_SPARTN (default on). Disabled on px4_fmu-v6x where flash is already at the limit; enabled on ark_can-rtk-gps. Depends on PX4-GPSDrivers for automatic u-blox SPARTN input enable. Signed-off-by: alexklimaj <alex@arkelectron.com> * fix(gnss): avoid undefined shift in SPARTN CRC-32 Use uint64_t for the CRC working register so n==32 does not perform 1u << 32 (clang-analyzer BitwiseShift). Signed-off-by: alexklimaj <alex@arkelectron.com> * make format * feat(gps): enable SPARTN support in board configurations * feat(gps): enhance SPARTN support with additional frame tracking and status reporting * fix(gps): frame RTCM3 and SPARTN from a single buffer Feeding every inject chunk to an independent framer per protocol let each one resync inside the other's payloads. That is not symmetric: RTCM3 is covered by CRC-24Q, but SPARTN's header carries no usable integrity check (TF006 is 4 bits over a non-byte-aligned field) and TF005 permits an 8-bit message CRC, so a stray 0x73 in an RTCM3 payload is framed as SPARTN at roughly 1 in 1024. RTCM3-only is what every board actually runs, and over 50 MB of it the two framers produced 211 bogus SPARTN frames (210 declaring CRC-8), each re-injecting up to 1 kB of the stream back into the receiver. The reverse direction produced none. Frame both protocols from one buffer instead: whichever preamble comes first is framed, and a valid frame consumes its own payload, so bytes inside one protocol's frame never start the other's. The same 50 MB now yields zero. Frames are also injected in arrival order rather than all RTCM3 then all SPARTN, and one buffer replaces two (2248 B/instance, down from ~4350 B). Also reject TF002 message types 5-119, which SPARTN reserves, as the one header field with a checkable range. CONFIG_GPS_SPARTN was default y, so it built into every target with a GPS including px4_fmu-v6x, which the flash report showed gaining the framer despite the intent to keep it off. Default it to n and enable it explicitly where it is wanted; the ark GPS boards already opt in, and SITL opts in so the framing tests keep running in CI. Rtcm3Parser and SpartnParser are replaced by CorrectionFramer; their tests carry over to it. RtcmStress fed "garbage" drawn from 0x01-0xD2 to avoid a preamble, which includes 0x73, and RtcmBustedSender ended its stream on a candidate the framer was still waiting to complete; both now avoid every preamble and flush respectively. * feat(gps): enable SPARTN on ARK flight controllers Covers receivers attached over UART rather than CAN. All four targets link with margin; fmu-v6xrt has no px4board on this branch yet. Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com> --------- Signed-off-by: alexklimaj <alex@arkelectron.com> Signed-off-by: Jacob Dahl <dahl.jakejacob@gmail.com> Co-authored-by: Jacob Dahl <dahl.jakejacob@gmail.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.
