Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/PX4/PX4-Autopilot/llms.txt

Use this file to discover all available pages before exploring further.

PX4 Autopilot is an open-source, safety-critical flight control stack maintained by a global community of developers, researchers, and pilots. Whether you fix a typo in the docs, report a bug, or land a new feature, every contribution moves the project forward. This guide explains how to get involved and what the contribution process looks like from start to finish.

​
Ways to contribute

Bug reports

Open an issue on GitHub with a clear reproduction case, flight log link, and hardware details. Good bug reports are one of the most valuable contributions you can make.

Documentation

Fix typos, improve explanations, add examples, or translate content via Crowdin. Documentation PRs follow the same review process as code.

Code

Implement new features, fix bugs, add drivers, or improve performance. All C/C++ code must follow the PX4 style guide and pass CI checks.

Code review

Review open pull requests, test changes on hardware, upload flight logs to Flight Review, and leave constructive feedback to help maintainers triage work.
PX4 follows the code of conduct. All contributors are expected to foster an open and welcoming environment.

​
GitHub workflow

All code and documentation changes flow through GitHub pull requests. PX4 targets a linear history using rebases rather than merge commits.
1

Fork the repository

Go to github.com/PX4/PX4-Autopilot and click Fork. Clone your fork locally:
git clone https://github.com/YOUR_USERNAME/PX4-Autopilot.git
cd PX4-Autopilot
git remote add upstream https://github.com/PX4/PX4-Autopilot.git
2

Create a feature branch

Always branch off main. Use a short, descriptive branch name:
git checkout main
git pull upstream main
git checkout -b fix/ekf2-height-fusion-timeout
3

Make your changes

Edit code or documentation. Run make format on any changed C/C++ files before committing. Write or update tests where applicable.
4

Commit with a conventional message

Follow the conventional commit format (see commit message format below). Each commit should be atomic and independently revertable.
5

Open a pull request

Push your branch and open a PR against PX4/PX4-Autopilot:main. Include a description of what changed, why, and a link to a flight log or test evidence if applicable.
git push origin fix/ekf2-height-fusion-timeout
6

Respond to review

Address reviewer comments by pushing new commits or rebasing. Once CI passes and a maintainer approves, your PR will be merged.

​
Branch model

PX4 maintains three long-lived branches:
BranchPurpose
mainActive development — unstable by default
betaThoroughly tested — intended for testers
stablePoints to the latest release
Always target main for new contributions unless a maintainer directs you otherwise.

​
Commit message format

PX4 uses Conventional Commits for all commit messages and PR titles. CI enforces this format — commits that don’t match will block merging.

​
Format

type(scope): short description of the change
PartRule
typeCategory of change (see types table below)
scopeThe module, driver, board, or subsystem affected (e.g., ekf2, mavlink, ci)
! (optional)Append before : to mark a breaking change
descriptionImperative mood, at least 5 characters, no trailing period

​
Commit types

TypeWhen to use
featA new feature
fixA bug fix
docsDocumentation-only changes
styleFormatting or whitespace — no logic change
refactorCode change that neither fixes a bug nor adds a feature
perfPerformance improvement
testAdding or correcting tests
buildBuild system or external dependencies
ciCI configuration files and scripts
choreChanges that don’t modify source or test files
revertReverts a previous commit

​
Good examples

feat(ekf2): add height fusion timeout
fix(mavlink): correct BATTERY_STATUS_V2 parsing
refactor(navigator): simplify RTL altitude logic
docs(ekf2): update tuning guide
feat(boards/px4_fmu-v6x)!: remove deprecated driver API
perf(mc_rate_control): reduce loop latency

​
Commits to avoid

fix                                 # too vague — no type or scope
update                              # too vague — no type or scope
ekf2: fix something                 # missing type prefix
apply suggestions from code review  # squash into the parent commit
do make format                      # squash into the parent commit
WIP: trying something               # not ready for main
The PR title follows the same type(scope): description format. This is especially important because the PR title becomes the squash-merge commit message on main.

​
Code review process

PX4 maintainers review every pull request before merging. Here is what to expect:
  • CI must pass. Format checks, unit tests, and build checks all run automatically. A failing CI blocks review.
  • Test evidence is required. New features need unit tests or SITL integration tests. Bug fixes need a regression test or a flight log demonstrating the fix.
  • Maintainers may request changes. Push additional commits or rebase to address feedback. Do not force-push after a review has started unless explicitly asked.
  • Merge policy. Commits are squashed at reviewer discretion for messy histories. Clean, logical commits are preserved individually on main.
If CI flags your commit messages, fix them before asking for re-review: 
# Reword the last N commits interactively
git rebase -i HEAD~N
git push --force-with-lease

​
DCO sign-off

PX4 uses the Developer Certificate of Origin (DCO) to certify that contributors have the right to submit their work. Add a Signed-off-by line to each commit: 
git commit --signoff -m "feat(ekf2): add height fusion timeout"
This produces: 
feat(ekf2): add height fusion timeout

Signed-off-by: Your Name <your@email.com>

​
Community channels

Discord

Join the PX4 Discord server for real-time discussion with developers and users. It is the fastest way to get a quick answer or find collaborators.

Weekly dev call

The development team holds a weekly video call to discuss architecture decisions, PR reviews, and open issues. Check the dev call page for the schedule.

Discuss forum

The PX4 Discuss forum is the place for longer-form questions, feature proposals, and community announcements.

GitHub issues

Use GitHub Issues to report bugs, track feature requests, and follow ongoing work.

Build docs developers (and LLMs) love

Get started for freeTalk to us