9e93fd753e
* ci(pr-review-poster): add line-anchored review poster and migrate clang-tidy Adds a generic PR review-comment poster as a sibling of the issue-comment poster from #27021. Replaces platisd/clang-tidy-pr-comments@v1 in the Static Analysis workflow with an in-tree, fork-friendly producer + poster pair so fork PRs get inline clang-tidy annotations on the Files changed tab without trusting a third-party action with a write token. Architecture mirrors pr-comment-poster: a producer (clang-tidy.yml) runs inside the px4-dev container and writes a `pr-review` artifact containing manifest.json and a baked comments.json. A separate workflow_run-triggered poster runs on ubuntu-latest with the base-repo write token, validates the artifact, dismisses any stale matching review, and posts a fresh review on the target PR. The poster never checks out PR code and only ever reads two opaque JSON files from the artifact. Stale-review dismissal is restricted to reviews authored by github-actions[bot] AND whose body contains the producer's marker. A fork cannot impersonate the bot login or inject the marker into a human reviewer's body, so the poster can never dismiss a human review. APPROVE events are explicitly forbidden so a bot cannot approve a pull request. To avoid duplicating ~120 lines of HTTP plumbing between the two posters, the GitHub REST helpers (single-request, pagination, error handling) are extracted into Tools/ci/_github_helpers.py with a small GitHubClient class. The existing pr-comment-poster.py is refactored to use it; net change is roughly -80 lines on that script. The shared module is sparse-checked-out alongside each poster script and is stdlib only. The clang-tidy producer reuses MIT-licensed translation logic from platisd/clang-tidy-pr-comments (generate_review_comments, reorder_diagnostics, get_diff_line_ranges_per_file and helpers) under a preserved attribution header. The HTTP layer is rewritten on top of _github_helpers so the producer does not pull in `requests`. Conversation resolution (the GraphQL path) is intentionally dropped for v1. clang-tidy.yml now produces the pr-review artifact in the same job as the build, so the cross-runner compile_commands.json hand-off and workspace-path rewriting are no longer needed and the post_clang_tidy_comments job is removed. Signed-off-by: Ramon Roche <mrpollo@gmail.com> * ci(workflows): bump action versions to clear Node 20 deprecation GitHub has deprecated the Node 20 runtime for Actions as of September 16, 2026. Bump the pinned action versions in the three poster workflows to the latest majors, all of which run on Node 24: actions/checkout v4 -> v6 actions/github-script v7 -> v8 actions/upload-artifact v4 -> v7 No behavior changes on our side: upload-artifact v5/v6/v7 only added an optional direct-file-upload mode we do not use, and checkout v5/v6 are runtime-only bumps. The security-invariant comment headers in both poster workflows are updated to reference the new version so they stay accurate. Signed-off-by: Ramon Roche <mrpollo@gmail.com> * ci(pr-posters): skip job when producer was not a pull_request event Both poster workflows previously ran on every workflow_run completion of their listed producers and then silently no-oped inside the script when the triggering producer run was a push-to-main (or any other non-PR event). That made the UI ambiguous: the job was always green, never showed the reason it did nothing, and looked like a failure whenever someone clicked in looking for the comment that was never there. Gate the job at the workflow level on github.event.workflow_run.event == 'pull_request'. Non-PR producer runs now surface as a clean "Skipped" entry in the run list, which is self-explanatory and needs no in-script summary plumbing. Signed-off-by: Ramon Roche <mrpollo@gmail.com> --------- Signed-off-by: Ramon Roche <mrpollo@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.
