No version for distro humble showing github. Known supported distros are highlighted in the buttons above.

px4-autopilot repository

px4

ROS Distro
github

Repository Summary

Description
Checkout URI	https://github.com/px4/px4-autopilot.git
VCS Type	git
VCS Version	main
Last Updated	2026-03-16
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
px4	1.14.0

README

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.}

Quick Start

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.

File truncated at 100 lines see the full file

CONTRIBUTING

Contributing to PX4-Autopilot

We follow the GitHub flow development model.

Fork the project, then clone your repo

First fork and clone the project.

Create a feature branch

Always branch off main for new features.

git checkout -b mydescriptivebranchname

Edit and build the code

The developer guide explains how to set up the development environment on Mac OS, Linux or Windows.

Coding standards

All C/C++ code must follow the PX4 coding style. Formatting is enforced by astyle in CI (make check_format). Code quality checks run via clang-tidy. Pull requests that fail either check will not be merged.

Python code is checked with mypy and flake8.

Commit message convention

PX4 uses conventional commits for all commit messages and PR titles.

Format

type(scope): short description of the change

Part	Rule
type	Category of change (see types table below)
scope	The module, driver, board, or area of PX4 affected
`!` (optional)	Append before `:` to mark a breaking change
description	What the change does, at least 5 characters, written in imperative form

Types

Type	Description
`feat`	A new feature
`fix`	A bug fix
`docs`	Documentation only changes
`style`	Formatting, whitespace, no code change
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependencies
`ci`	CI configuration files and scripts
`chore`	Other changes that don’t modify src or test files
`revert`	Reverts a previous commit

Scopes

The scope identifies which part of PX4 is affected. Common scopes:

Scope	Area
`ekf2`	Extended Kalman Filter (state estimation)
`mavlink`	MAVLink messaging protocol
`commander`	Commander and mode management
`navigator`	Mission, RTL, Land, and other navigation modes
`sensors`	Sensor drivers and processing
`drivers`	Hardware drivers
`boards/px4_fmu-v6x`	Board-specific changes (use the board name)
`mc_att_control`	Multicopter attitude control
`mc_pos_control`	Multicopter position control
`fw_att_control`	Fixed-wing attitude control
`vtol`	VTOL-specific logic
`actuators`	Mixer and actuator output
`battery`	Battery monitoring and estimation
`logger`	On-board logging
`param`	Parameter system
`simulation`	SITL, Gazebo, SIH
`ci`	Continuous integration and workflows
`docs`	Documentation
`build`	CMake, toolchain, build system
`uorb`	Inter-module messaging

For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: src/modules/ekf2/ uses ekf2, src/drivers/imu/ uses drivers/imu, .github/workflows/ uses ci.

Breaking changes

Append ! before the colon to indicate a breaking change:

feat(ekf2)!: remove deprecated height fusion API

Good commit messages

``` feat(ekf2): add height fusion timeout

File truncated at 100 lines see the full file

# Contributing to PX4-Autopilot We follow the [GitHub flow](https://guides.github.com/introduction/flow/) development model. ## Fork the project, then clone your repo First [fork and clone](https://help.github.com/articles/fork-a-repo) the project. ## Create a feature branch Always branch off `main` for new features. ``` git checkout -b mydescriptivebranchname ``` ## Edit and build the code The [developer guide](https://docs.px4.io/main/en/development/development.html) explains how to set up the development environment on Mac OS, Linux or Windows. ### Coding standards All C/C++ code must follow the [PX4 coding style](https://docs.px4.io/main/en/contribute/code.html). Formatting is enforced by [astyle](http://astyle.sourceforge.net/) in CI (`make check_format`). Code quality checks run via [clang-tidy](https://clang.llvm.org/extra/clang-tidy/). Pull requests that fail either check will not be merged. Python code is checked with [mypy](https://mypy-lang.org/) and [flake8](https://flake8.pycqa.org/). ## Commit message convention PX4 uses [conventional commits](https://www.conventionalcommits.org/) for all commit messages and PR titles. ### Format ``` type(scope): short description of the change ``` | Part | Rule | |------|------| | **type** | Category of change (see types table below) | | **scope** | The module, driver, board, or area of PX4 affected | | **`!`** (optional) | Append before `:` to mark a breaking change | | **description** | What the change does, at least 5 characters, written in imperative form | ### Types | Type | Description | |------|-------------| | `feat` | A new feature | | `fix` | A bug fix | | `docs` | Documentation only changes | | `style` | Formatting, whitespace, no code change | | `refactor` | Code change that neither fixes a bug nor adds a feature | | `perf` | Performance improvement | | `test` | Adding or correcting tests | | `build` | Build system or external dependencies | | `ci` | CI configuration files and scripts | | `chore` | Other changes that don't modify src or test files | | `revert` | Reverts a previous commit | ### Scopes The scope identifies which part of PX4 is affected. Common scopes: | Scope | Area | |-------|------| | `ekf2` | Extended Kalman Filter (state estimation) | | `mavlink` | MAVLink messaging protocol | | `commander` | Commander and mode management | | `navigator` | Mission, RTL, Land, and other navigation modes | | `sensors` | Sensor drivers and processing | | `drivers` | Hardware drivers | | `boards/px4_fmu-v6x` | Board-specific changes (use the board name) | | `mc_att_control` | Multicopter attitude control | | `mc_pos_control` | Multicopter position control | | `fw_att_control` | Fixed-wing attitude control | | `vtol` | VTOL-specific logic | | `actuators` | Mixer and actuator output | | `battery` | Battery monitoring and estimation | | `logger` | On-board logging | | `param` | Parameter system | | `simulation` | SITL, Gazebo, SIH | | `ci` | Continuous integration and workflows | | `docs` | Documentation | | `build` | CMake, toolchain, build system | | `uorb` | Inter-module messaging | For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: `src/modules/ekf2/` uses `ekf2`, `src/drivers/imu/` uses `drivers/imu`, `.github/workflows/` uses `ci`. ### Breaking changes Append `!` before the colon to indicate a breaking change: ``` feat(ekf2)!: remove deprecated height fusion API ``` ### Good commit messages ``` feat(ekf2): add height fusion timeout File truncated at 100 lines [see the full file](https://github.com/px4/px4-autopilot/tree/main/CONTRIBUTING.md)

No version for distro jazzy showing github. Known supported distros are highlighted in the buttons above.

px4-autopilot repository

px4

ROS Distro
github

Repository Summary

Description
Checkout URI	https://github.com/px4/px4-autopilot.git
VCS Type	git
VCS Version	main
Last Updated	2026-03-16
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
px4	1.14.0

README

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.}

Quick Start

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.

File truncated at 100 lines see the full file

CONTRIBUTING

Contributing to PX4-Autopilot

We follow the GitHub flow development model.

Fork the project, then clone your repo

First fork and clone the project.

Create a feature branch

Always branch off main for new features.

git checkout -b mydescriptivebranchname

Edit and build the code

The developer guide explains how to set up the development environment on Mac OS, Linux or Windows.

Coding standards

All C/C++ code must follow the PX4 coding style. Formatting is enforced by astyle in CI (make check_format). Code quality checks run via clang-tidy. Pull requests that fail either check will not be merged.

Python code is checked with mypy and flake8.

Commit message convention

PX4 uses conventional commits for all commit messages and PR titles.

Format

type(scope): short description of the change

Part	Rule
type	Category of change (see types table below)
scope	The module, driver, board, or area of PX4 affected
`!` (optional)	Append before `:` to mark a breaking change
description	What the change does, at least 5 characters, written in imperative form

Types

Type	Description
`feat`	A new feature
`fix`	A bug fix
`docs`	Documentation only changes
`style`	Formatting, whitespace, no code change
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependencies
`ci`	CI configuration files and scripts
`chore`	Other changes that don’t modify src or test files
`revert`	Reverts a previous commit

Scopes

The scope identifies which part of PX4 is affected. Common scopes:

Scope	Area
`ekf2`	Extended Kalman Filter (state estimation)
`mavlink`	MAVLink messaging protocol
`commander`	Commander and mode management
`navigator`	Mission, RTL, Land, and other navigation modes
`sensors`	Sensor drivers and processing
`drivers`	Hardware drivers
`boards/px4_fmu-v6x`	Board-specific changes (use the board name)
`mc_att_control`	Multicopter attitude control
`mc_pos_control`	Multicopter position control
`fw_att_control`	Fixed-wing attitude control
`vtol`	VTOL-specific logic
`actuators`	Mixer and actuator output
`battery`	Battery monitoring and estimation
`logger`	On-board logging
`param`	Parameter system
`simulation`	SITL, Gazebo, SIH
`ci`	Continuous integration and workflows
`docs`	Documentation
`build`	CMake, toolchain, build system
`uorb`	Inter-module messaging

For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: src/modules/ekf2/ uses ekf2, src/drivers/imu/ uses drivers/imu, .github/workflows/ uses ci.

Breaking changes

Append ! before the colon to indicate a breaking change:

feat(ekf2)!: remove deprecated height fusion API

Good commit messages

``` feat(ekf2): add height fusion timeout

File truncated at 100 lines see the full file

# Contributing to PX4-Autopilot We follow the [GitHub flow](https://guides.github.com/introduction/flow/) development model. ## Fork the project, then clone your repo First [fork and clone](https://help.github.com/articles/fork-a-repo) the project. ## Create a feature branch Always branch off `main` for new features. ``` git checkout -b mydescriptivebranchname ``` ## Edit and build the code The [developer guide](https://docs.px4.io/main/en/development/development.html) explains how to set up the development environment on Mac OS, Linux or Windows. ### Coding standards All C/C++ code must follow the [PX4 coding style](https://docs.px4.io/main/en/contribute/code.html). Formatting is enforced by [astyle](http://astyle.sourceforge.net/) in CI (`make check_format`). Code quality checks run via [clang-tidy](https://clang.llvm.org/extra/clang-tidy/). Pull requests that fail either check will not be merged. Python code is checked with [mypy](https://mypy-lang.org/) and [flake8](https://flake8.pycqa.org/). ## Commit message convention PX4 uses [conventional commits](https://www.conventionalcommits.org/) for all commit messages and PR titles. ### Format ``` type(scope): short description of the change ``` | Part | Rule | |------|------| | **type** | Category of change (see types table below) | | **scope** | The module, driver, board, or area of PX4 affected | | **`!`** (optional) | Append before `:` to mark a breaking change | | **description** | What the change does, at least 5 characters, written in imperative form | ### Types | Type | Description | |------|-------------| | `feat` | A new feature | | `fix` | A bug fix | | `docs` | Documentation only changes | | `style` | Formatting, whitespace, no code change | | `refactor` | Code change that neither fixes a bug nor adds a feature | | `perf` | Performance improvement | | `test` | Adding or correcting tests | | `build` | Build system or external dependencies | | `ci` | CI configuration files and scripts | | `chore` | Other changes that don't modify src or test files | | `revert` | Reverts a previous commit | ### Scopes The scope identifies which part of PX4 is affected. Common scopes: | Scope | Area | |-------|------| | `ekf2` | Extended Kalman Filter (state estimation) | | `mavlink` | MAVLink messaging protocol | | `commander` | Commander and mode management | | `navigator` | Mission, RTL, Land, and other navigation modes | | `sensors` | Sensor drivers and processing | | `drivers` | Hardware drivers | | `boards/px4_fmu-v6x` | Board-specific changes (use the board name) | | `mc_att_control` | Multicopter attitude control | | `mc_pos_control` | Multicopter position control | | `fw_att_control` | Fixed-wing attitude control | | `vtol` | VTOL-specific logic | | `actuators` | Mixer and actuator output | | `battery` | Battery monitoring and estimation | | `logger` | On-board logging | | `param` | Parameter system | | `simulation` | SITL, Gazebo, SIH | | `ci` | Continuous integration and workflows | | `docs` | Documentation | | `build` | CMake, toolchain, build system | | `uorb` | Inter-module messaging | For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: `src/modules/ekf2/` uses `ekf2`, `src/drivers/imu/` uses `drivers/imu`, `.github/workflows/` uses `ci`. ### Breaking changes Append `!` before the colon to indicate a breaking change: ``` feat(ekf2)!: remove deprecated height fusion API ``` ### Good commit messages ``` feat(ekf2): add height fusion timeout File truncated at 100 lines [see the full file](https://github.com/px4/px4-autopilot/tree/main/CONTRIBUTING.md)

No version for distro kilted showing github. Known supported distros are highlighted in the buttons above.

px4-autopilot repository

px4

ROS Distro
github

Repository Summary

Description
Checkout URI	https://github.com/px4/px4-autopilot.git
VCS Type	git
VCS Version	main
Last Updated	2026-03-16
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
px4	1.14.0

README

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.}

Quick Start

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.

File truncated at 100 lines see the full file

CONTRIBUTING

Contributing to PX4-Autopilot

We follow the GitHub flow development model.

Fork the project, then clone your repo

First fork and clone the project.

Create a feature branch

Always branch off main for new features.

git checkout -b mydescriptivebranchname

Edit and build the code

The developer guide explains how to set up the development environment on Mac OS, Linux or Windows.

Coding standards

All C/C++ code must follow the PX4 coding style. Formatting is enforced by astyle in CI (make check_format). Code quality checks run via clang-tidy. Pull requests that fail either check will not be merged.

Python code is checked with mypy and flake8.

Commit message convention

PX4 uses conventional commits for all commit messages and PR titles.

Format

type(scope): short description of the change

Part	Rule
type	Category of change (see types table below)
scope	The module, driver, board, or area of PX4 affected
`!` (optional)	Append before `:` to mark a breaking change
description	What the change does, at least 5 characters, written in imperative form

Types

Type	Description
`feat`	A new feature
`fix`	A bug fix
`docs`	Documentation only changes
`style`	Formatting, whitespace, no code change
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependencies
`ci`	CI configuration files and scripts
`chore`	Other changes that don’t modify src or test files
`revert`	Reverts a previous commit

Scopes

The scope identifies which part of PX4 is affected. Common scopes:

Scope	Area
`ekf2`	Extended Kalman Filter (state estimation)
`mavlink`	MAVLink messaging protocol
`commander`	Commander and mode management
`navigator`	Mission, RTL, Land, and other navigation modes
`sensors`	Sensor drivers and processing
`drivers`	Hardware drivers
`boards/px4_fmu-v6x`	Board-specific changes (use the board name)
`mc_att_control`	Multicopter attitude control
`mc_pos_control`	Multicopter position control
`fw_att_control`	Fixed-wing attitude control
`vtol`	VTOL-specific logic
`actuators`	Mixer and actuator output
`battery`	Battery monitoring and estimation
`logger`	On-board logging
`param`	Parameter system
`simulation`	SITL, Gazebo, SIH
`ci`	Continuous integration and workflows
`docs`	Documentation
`build`	CMake, toolchain, build system
`uorb`	Inter-module messaging

For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: src/modules/ekf2/ uses ekf2, src/drivers/imu/ uses drivers/imu, .github/workflows/ uses ci.

Breaking changes

Append ! before the colon to indicate a breaking change:

feat(ekf2)!: remove deprecated height fusion API

Good commit messages

``` feat(ekf2): add height fusion timeout

File truncated at 100 lines see the full file

# Contributing to PX4-Autopilot We follow the [GitHub flow](https://guides.github.com/introduction/flow/) development model. ## Fork the project, then clone your repo First [fork and clone](https://help.github.com/articles/fork-a-repo) the project. ## Create a feature branch Always branch off `main` for new features. ``` git checkout -b mydescriptivebranchname ``` ## Edit and build the code The [developer guide](https://docs.px4.io/main/en/development/development.html) explains how to set up the development environment on Mac OS, Linux or Windows. ### Coding standards All C/C++ code must follow the [PX4 coding style](https://docs.px4.io/main/en/contribute/code.html). Formatting is enforced by [astyle](http://astyle.sourceforge.net/) in CI (`make check_format`). Code quality checks run via [clang-tidy](https://clang.llvm.org/extra/clang-tidy/). Pull requests that fail either check will not be merged. Python code is checked with [mypy](https://mypy-lang.org/) and [flake8](https://flake8.pycqa.org/). ## Commit message convention PX4 uses [conventional commits](https://www.conventionalcommits.org/) for all commit messages and PR titles. ### Format ``` type(scope): short description of the change ``` | Part | Rule | |------|------| | **type** | Category of change (see types table below) | | **scope** | The module, driver, board, or area of PX4 affected | | **`!`** (optional) | Append before `:` to mark a breaking change | | **description** | What the change does, at least 5 characters, written in imperative form | ### Types | Type | Description | |------|-------------| | `feat` | A new feature | | `fix` | A bug fix | | `docs` | Documentation only changes | | `style` | Formatting, whitespace, no code change | | `refactor` | Code change that neither fixes a bug nor adds a feature | | `perf` | Performance improvement | | `test` | Adding or correcting tests | | `build` | Build system or external dependencies | | `ci` | CI configuration files and scripts | | `chore` | Other changes that don't modify src or test files | | `revert` | Reverts a previous commit | ### Scopes The scope identifies which part of PX4 is affected. Common scopes: | Scope | Area | |-------|------| | `ekf2` | Extended Kalman Filter (state estimation) | | `mavlink` | MAVLink messaging protocol | | `commander` | Commander and mode management | | `navigator` | Mission, RTL, Land, and other navigation modes | | `sensors` | Sensor drivers and processing | | `drivers` | Hardware drivers | | `boards/px4_fmu-v6x` | Board-specific changes (use the board name) | | `mc_att_control` | Multicopter attitude control | | `mc_pos_control` | Multicopter position control | | `fw_att_control` | Fixed-wing attitude control | | `vtol` | VTOL-specific logic | | `actuators` | Mixer and actuator output | | `battery` | Battery monitoring and estimation | | `logger` | On-board logging | | `param` | Parameter system | | `simulation` | SITL, Gazebo, SIH | | `ci` | Continuous integration and workflows | | `docs` | Documentation | | `build` | CMake, toolchain, build system | | `uorb` | Inter-module messaging | For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: `src/modules/ekf2/` uses `ekf2`, `src/drivers/imu/` uses `drivers/imu`, `.github/workflows/` uses `ci`. ### Breaking changes Append `!` before the colon to indicate a breaking change: ``` feat(ekf2)!: remove deprecated height fusion API ``` ### Good commit messages ``` feat(ekf2): add height fusion timeout File truncated at 100 lines [see the full file](https://github.com/px4/px4-autopilot/tree/main/CONTRIBUTING.md)

No version for distro rolling showing github. Known supported distros are highlighted in the buttons above.

px4-autopilot repository

px4

ROS Distro
github

Repository Summary

Description
Checkout URI	https://github.com/px4/px4-autopilot.git
VCS Type	git
VCS Version	main
Last Updated	2026-03-16
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
px4	1.14.0

README

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.}

Quick Start

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.

File truncated at 100 lines see the full file

CONTRIBUTING

Contributing to PX4-Autopilot

We follow the GitHub flow development model.

Fork the project, then clone your repo

First fork and clone the project.

Create a feature branch

Always branch off main for new features.

git checkout -b mydescriptivebranchname

Edit and build the code

The developer guide explains how to set up the development environment on Mac OS, Linux or Windows.

Coding standards

All C/C++ code must follow the PX4 coding style. Formatting is enforced by astyle in CI (make check_format). Code quality checks run via clang-tidy. Pull requests that fail either check will not be merged.

Python code is checked with mypy and flake8.

Commit message convention

PX4 uses conventional commits for all commit messages and PR titles.

Format

type(scope): short description of the change

Part	Rule
type	Category of change (see types table below)
scope	The module, driver, board, or area of PX4 affected
`!` (optional)	Append before `:` to mark a breaking change
description	What the change does, at least 5 characters, written in imperative form

Types

Type	Description
`feat`	A new feature
`fix`	A bug fix
`docs`	Documentation only changes
`style`	Formatting, whitespace, no code change
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependencies
`ci`	CI configuration files and scripts
`chore`	Other changes that don’t modify src or test files
`revert`	Reverts a previous commit

Scopes

The scope identifies which part of PX4 is affected. Common scopes:

Scope	Area
`ekf2`	Extended Kalman Filter (state estimation)
`mavlink`	MAVLink messaging protocol
`commander`	Commander and mode management
`navigator`	Mission, RTL, Land, and other navigation modes
`sensors`	Sensor drivers and processing
`drivers`	Hardware drivers
`boards/px4_fmu-v6x`	Board-specific changes (use the board name)
`mc_att_control`	Multicopter attitude control
`mc_pos_control`	Multicopter position control
`fw_att_control`	Fixed-wing attitude control
`vtol`	VTOL-specific logic
`actuators`	Mixer and actuator output
`battery`	Battery monitoring and estimation
`logger`	On-board logging
`param`	Parameter system
`simulation`	SITL, Gazebo, SIH
`ci`	Continuous integration and workflows
`docs`	Documentation
`build`	CMake, toolchain, build system
`uorb`	Inter-module messaging

For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: src/modules/ekf2/ uses ekf2, src/drivers/imu/ uses drivers/imu, .github/workflows/ uses ci.

Breaking changes

Append ! before the colon to indicate a breaking change:

feat(ekf2)!: remove deprecated height fusion API

Good commit messages

``` feat(ekf2): add height fusion timeout

File truncated at 100 lines see the full file

# Contributing to PX4-Autopilot We follow the [GitHub flow](https://guides.github.com/introduction/flow/) development model. ## Fork the project, then clone your repo First [fork and clone](https://help.github.com/articles/fork-a-repo) the project. ## Create a feature branch Always branch off `main` for new features. ``` git checkout -b mydescriptivebranchname ``` ## Edit and build the code The [developer guide](https://docs.px4.io/main/en/development/development.html) explains how to set up the development environment on Mac OS, Linux or Windows. ### Coding standards All C/C++ code must follow the [PX4 coding style](https://docs.px4.io/main/en/contribute/code.html). Formatting is enforced by [astyle](http://astyle.sourceforge.net/) in CI (`make check_format`). Code quality checks run via [clang-tidy](https://clang.llvm.org/extra/clang-tidy/). Pull requests that fail either check will not be merged. Python code is checked with [mypy](https://mypy-lang.org/) and [flake8](https://flake8.pycqa.org/). ## Commit message convention PX4 uses [conventional commits](https://www.conventionalcommits.org/) for all commit messages and PR titles. ### Format ``` type(scope): short description of the change ``` | Part | Rule | |------|------| | **type** | Category of change (see types table below) | | **scope** | The module, driver, board, or area of PX4 affected | | **`!`** (optional) | Append before `:` to mark a breaking change | | **description** | What the change does, at least 5 characters, written in imperative form | ### Types | Type | Description | |------|-------------| | `feat` | A new feature | | `fix` | A bug fix | | `docs` | Documentation only changes | | `style` | Formatting, whitespace, no code change | | `refactor` | Code change that neither fixes a bug nor adds a feature | | `perf` | Performance improvement | | `test` | Adding or correcting tests | | `build` | Build system or external dependencies | | `ci` | CI configuration files and scripts | | `chore` | Other changes that don't modify src or test files | | `revert` | Reverts a previous commit | ### Scopes The scope identifies which part of PX4 is affected. Common scopes: | Scope | Area | |-------|------| | `ekf2` | Extended Kalman Filter (state estimation) | | `mavlink` | MAVLink messaging protocol | | `commander` | Commander and mode management | | `navigator` | Mission, RTL, Land, and other navigation modes | | `sensors` | Sensor drivers and processing | | `drivers` | Hardware drivers | | `boards/px4_fmu-v6x` | Board-specific changes (use the board name) | | `mc_att_control` | Multicopter attitude control | | `mc_pos_control` | Multicopter position control | | `fw_att_control` | Fixed-wing attitude control | | `vtol` | VTOL-specific logic | | `actuators` | Mixer and actuator output | | `battery` | Battery monitoring and estimation | | `logger` | On-board logging | | `param` | Parameter system | | `simulation` | SITL, Gazebo, SIH | | `ci` | Continuous integration and workflows | | `docs` | Documentation | | `build` | CMake, toolchain, build system | | `uorb` | Inter-module messaging | For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: `src/modules/ekf2/` uses `ekf2`, `src/drivers/imu/` uses `drivers/imu`, `.github/workflows/` uses `ci`. ### Breaking changes Append `!` before the colon to indicate a breaking change: ``` feat(ekf2)!: remove deprecated height fusion API ``` ### Good commit messages ``` feat(ekf2): add height fusion timeout File truncated at 100 lines [see the full file](https://github.com/px4/px4-autopilot/tree/main/CONTRIBUTING.md)

px4-autopilot repository

px4

ROS Distro
github

Repository Summary

Description
Checkout URI	https://github.com/px4/px4-autopilot.git
VCS Type	git
VCS Version	main
Last Updated	2026-03-16
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
px4	1.14.0

README

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.}

Quick Start

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.

File truncated at 100 lines see the full file

CONTRIBUTING

Contributing to PX4-Autopilot

We follow the GitHub flow development model.

Fork the project, then clone your repo

First fork and clone the project.

Create a feature branch

Always branch off main for new features.

git checkout -b mydescriptivebranchname

Edit and build the code

The developer guide explains how to set up the development environment on Mac OS, Linux or Windows.

Coding standards

All C/C++ code must follow the PX4 coding style. Formatting is enforced by astyle in CI (make check_format). Code quality checks run via clang-tidy. Pull requests that fail either check will not be merged.

Python code is checked with mypy and flake8.

Commit message convention

PX4 uses conventional commits for all commit messages and PR titles.

Format

type(scope): short description of the change

Part	Rule
type	Category of change (see types table below)
scope	The module, driver, board, or area of PX4 affected
`!` (optional)	Append before `:` to mark a breaking change
description	What the change does, at least 5 characters, written in imperative form

Types

Type	Description
`feat`	A new feature
`fix`	A bug fix
`docs`	Documentation only changes
`style`	Formatting, whitespace, no code change
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependencies
`ci`	CI configuration files and scripts
`chore`	Other changes that don’t modify src or test files
`revert`	Reverts a previous commit

Scopes

The scope identifies which part of PX4 is affected. Common scopes:

Scope	Area
`ekf2`	Extended Kalman Filter (state estimation)
`mavlink`	MAVLink messaging protocol
`commander`	Commander and mode management
`navigator`	Mission, RTL, Land, and other navigation modes
`sensors`	Sensor drivers and processing
`drivers`	Hardware drivers
`boards/px4_fmu-v6x`	Board-specific changes (use the board name)
`mc_att_control`	Multicopter attitude control
`mc_pos_control`	Multicopter position control
`fw_att_control`	Fixed-wing attitude control
`vtol`	VTOL-specific logic
`actuators`	Mixer and actuator output
`battery`	Battery monitoring and estimation
`logger`	On-board logging
`param`	Parameter system
`simulation`	SITL, Gazebo, SIH
`ci`	Continuous integration and workflows
`docs`	Documentation
`build`	CMake, toolchain, build system
`uorb`	Inter-module messaging

For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: src/modules/ekf2/ uses ekf2, src/drivers/imu/ uses drivers/imu, .github/workflows/ uses ci.

Breaking changes

Append ! before the colon to indicate a breaking change:

feat(ekf2)!: remove deprecated height fusion API

Good commit messages

``` feat(ekf2): add height fusion timeout

File truncated at 100 lines see the full file

# Contributing to PX4-Autopilot We follow the [GitHub flow](https://guides.github.com/introduction/flow/) development model. ## Fork the project, then clone your repo First [fork and clone](https://help.github.com/articles/fork-a-repo) the project. ## Create a feature branch Always branch off `main` for new features. ``` git checkout -b mydescriptivebranchname ``` ## Edit and build the code The [developer guide](https://docs.px4.io/main/en/development/development.html) explains how to set up the development environment on Mac OS, Linux or Windows. ### Coding standards All C/C++ code must follow the [PX4 coding style](https://docs.px4.io/main/en/contribute/code.html). Formatting is enforced by [astyle](http://astyle.sourceforge.net/) in CI (`make check_format`). Code quality checks run via [clang-tidy](https://clang.llvm.org/extra/clang-tidy/). Pull requests that fail either check will not be merged. Python code is checked with [mypy](https://mypy-lang.org/) and [flake8](https://flake8.pycqa.org/). ## Commit message convention PX4 uses [conventional commits](https://www.conventionalcommits.org/) for all commit messages and PR titles. ### Format ``` type(scope): short description of the change ``` | Part | Rule | |------|------| | **type** | Category of change (see types table below) | | **scope** | The module, driver, board, or area of PX4 affected | | **`!`** (optional) | Append before `:` to mark a breaking change | | **description** | What the change does, at least 5 characters, written in imperative form | ### Types | Type | Description | |------|-------------| | `feat` | A new feature | | `fix` | A bug fix | | `docs` | Documentation only changes | | `style` | Formatting, whitespace, no code change | | `refactor` | Code change that neither fixes a bug nor adds a feature | | `perf` | Performance improvement | | `test` | Adding or correcting tests | | `build` | Build system or external dependencies | | `ci` | CI configuration files and scripts | | `chore` | Other changes that don't modify src or test files | | `revert` | Reverts a previous commit | ### Scopes The scope identifies which part of PX4 is affected. Common scopes: | Scope | Area | |-------|------| | `ekf2` | Extended Kalman Filter (state estimation) | | `mavlink` | MAVLink messaging protocol | | `commander` | Commander and mode management | | `navigator` | Mission, RTL, Land, and other navigation modes | | `sensors` | Sensor drivers and processing | | `drivers` | Hardware drivers | | `boards/px4_fmu-v6x` | Board-specific changes (use the board name) | | `mc_att_control` | Multicopter attitude control | | `mc_pos_control` | Multicopter position control | | `fw_att_control` | Fixed-wing attitude control | | `vtol` | VTOL-specific logic | | `actuators` | Mixer and actuator output | | `battery` | Battery monitoring and estimation | | `logger` | On-board logging | | `param` | Parameter system | | `simulation` | SITL, Gazebo, SIH | | `ci` | Continuous integration and workflows | | `docs` | Documentation | | `build` | CMake, toolchain, build system | | `uorb` | Inter-module messaging | For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: `src/modules/ekf2/` uses `ekf2`, `src/drivers/imu/` uses `drivers/imu`, `.github/workflows/` uses `ci`. ### Breaking changes Append `!` before the colon to indicate a breaking change: ``` feat(ekf2)!: remove deprecated height fusion API ``` ### Good commit messages ``` feat(ekf2): add height fusion timeout File truncated at 100 lines [see the full file](https://github.com/px4/px4-autopilot/tree/main/CONTRIBUTING.md)

No version for distro galactic showing github. Known supported distros are highlighted in the buttons above.

px4-autopilot repository

px4

ROS Distro
github

Repository Summary

Description
Checkout URI	https://github.com/px4/px4-autopilot.git
VCS Type	git
VCS Version	main
Last Updated	2026-03-16
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
px4	1.14.0

README

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.}

Quick Start

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.

File truncated at 100 lines see the full file

CONTRIBUTING

Contributing to PX4-Autopilot

We follow the GitHub flow development model.

Fork the project, then clone your repo

First fork and clone the project.

Create a feature branch

Always branch off main for new features.

git checkout -b mydescriptivebranchname

Edit and build the code

The developer guide explains how to set up the development environment on Mac OS, Linux or Windows.

Coding standards

All C/C++ code must follow the PX4 coding style. Formatting is enforced by astyle in CI (make check_format). Code quality checks run via clang-tidy. Pull requests that fail either check will not be merged.

Python code is checked with mypy and flake8.

Commit message convention

PX4 uses conventional commits for all commit messages and PR titles.

Format

type(scope): short description of the change

Part	Rule
type	Category of change (see types table below)
scope	The module, driver, board, or area of PX4 affected
`!` (optional)	Append before `:` to mark a breaking change
description	What the change does, at least 5 characters, written in imperative form

Types

Type	Description
`feat`	A new feature
`fix`	A bug fix
`docs`	Documentation only changes
`style`	Formatting, whitespace, no code change
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependencies
`ci`	CI configuration files and scripts
`chore`	Other changes that don’t modify src or test files
`revert`	Reverts a previous commit

Scopes

The scope identifies which part of PX4 is affected. Common scopes:

Scope	Area
`ekf2`	Extended Kalman Filter (state estimation)
`mavlink`	MAVLink messaging protocol
`commander`	Commander and mode management
`navigator`	Mission, RTL, Land, and other navigation modes
`sensors`	Sensor drivers and processing
`drivers`	Hardware drivers
`boards/px4_fmu-v6x`	Board-specific changes (use the board name)
`mc_att_control`	Multicopter attitude control
`mc_pos_control`	Multicopter position control
`fw_att_control`	Fixed-wing attitude control
`vtol`	VTOL-specific logic
`actuators`	Mixer and actuator output
`battery`	Battery monitoring and estimation
`logger`	On-board logging
`param`	Parameter system
`simulation`	SITL, Gazebo, SIH
`ci`	Continuous integration and workflows
`docs`	Documentation
`build`	CMake, toolchain, build system
`uorb`	Inter-module messaging

For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: src/modules/ekf2/ uses ekf2, src/drivers/imu/ uses drivers/imu, .github/workflows/ uses ci.

Breaking changes

Append ! before the colon to indicate a breaking change:

feat(ekf2)!: remove deprecated height fusion API

Good commit messages

``` feat(ekf2): add height fusion timeout

File truncated at 100 lines see the full file

# Contributing to PX4-Autopilot We follow the [GitHub flow](https://guides.github.com/introduction/flow/) development model. ## Fork the project, then clone your repo First [fork and clone](https://help.github.com/articles/fork-a-repo) the project. ## Create a feature branch Always branch off `main` for new features. ``` git checkout -b mydescriptivebranchname ``` ## Edit and build the code The [developer guide](https://docs.px4.io/main/en/development/development.html) explains how to set up the development environment on Mac OS, Linux or Windows. ### Coding standards All C/C++ code must follow the [PX4 coding style](https://docs.px4.io/main/en/contribute/code.html). Formatting is enforced by [astyle](http://astyle.sourceforge.net/) in CI (`make check_format`). Code quality checks run via [clang-tidy](https://clang.llvm.org/extra/clang-tidy/). Pull requests that fail either check will not be merged. Python code is checked with [mypy](https://mypy-lang.org/) and [flake8](https://flake8.pycqa.org/). ## Commit message convention PX4 uses [conventional commits](https://www.conventionalcommits.org/) for all commit messages and PR titles. ### Format ``` type(scope): short description of the change ``` | Part | Rule | |------|------| | **type** | Category of change (see types table below) | | **scope** | The module, driver, board, or area of PX4 affected | | **`!`** (optional) | Append before `:` to mark a breaking change | | **description** | What the change does, at least 5 characters, written in imperative form | ### Types | Type | Description | |------|-------------| | `feat` | A new feature | | `fix` | A bug fix | | `docs` | Documentation only changes | | `style` | Formatting, whitespace, no code change | | `refactor` | Code change that neither fixes a bug nor adds a feature | | `perf` | Performance improvement | | `test` | Adding or correcting tests | | `build` | Build system or external dependencies | | `ci` | CI configuration files and scripts | | `chore` | Other changes that don't modify src or test files | | `revert` | Reverts a previous commit | ### Scopes The scope identifies which part of PX4 is affected. Common scopes: | Scope | Area | |-------|------| | `ekf2` | Extended Kalman Filter (state estimation) | | `mavlink` | MAVLink messaging protocol | | `commander` | Commander and mode management | | `navigator` | Mission, RTL, Land, and other navigation modes | | `sensors` | Sensor drivers and processing | | `drivers` | Hardware drivers | | `boards/px4_fmu-v6x` | Board-specific changes (use the board name) | | `mc_att_control` | Multicopter attitude control | | `mc_pos_control` | Multicopter position control | | `fw_att_control` | Fixed-wing attitude control | | `vtol` | VTOL-specific logic | | `actuators` | Mixer and actuator output | | `battery` | Battery monitoring and estimation | | `logger` | On-board logging | | `param` | Parameter system | | `simulation` | SITL, Gazebo, SIH | | `ci` | Continuous integration and workflows | | `docs` | Documentation | | `build` | CMake, toolchain, build system | | `uorb` | Inter-module messaging | For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: `src/modules/ekf2/` uses `ekf2`, `src/drivers/imu/` uses `drivers/imu`, `.github/workflows/` uses `ci`. ### Breaking changes Append `!` before the colon to indicate a breaking change: ``` feat(ekf2)!: remove deprecated height fusion API ``` ### Good commit messages ``` feat(ekf2): add height fusion timeout File truncated at 100 lines [see the full file](https://github.com/px4/px4-autopilot/tree/main/CONTRIBUTING.md)

No version for distro iron showing github. Known supported distros are highlighted in the buttons above.

px4-autopilot repository

px4

ROS Distro
github

Repository Summary

Description
Checkout URI	https://github.com/px4/px4-autopilot.git
VCS Type	git
VCS Version	main
Last Updated	2026-03-16
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
px4	1.14.0

README

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.}

Quick Start

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.

File truncated at 100 lines see the full file

CONTRIBUTING

Contributing to PX4-Autopilot

We follow the GitHub flow development model.

Fork the project, then clone your repo

First fork and clone the project.

Create a feature branch

Always branch off main for new features.

git checkout -b mydescriptivebranchname

Edit and build the code

The developer guide explains how to set up the development environment on Mac OS, Linux or Windows.

Coding standards

All C/C++ code must follow the PX4 coding style. Formatting is enforced by astyle in CI (make check_format). Code quality checks run via clang-tidy. Pull requests that fail either check will not be merged.

Python code is checked with mypy and flake8.

Commit message convention

PX4 uses conventional commits for all commit messages and PR titles.

Format

type(scope): short description of the change

Part	Rule
type	Category of change (see types table below)
scope	The module, driver, board, or area of PX4 affected
`!` (optional)	Append before `:` to mark a breaking change
description	What the change does, at least 5 characters, written in imperative form

Types

Type	Description
`feat`	A new feature
`fix`	A bug fix
`docs`	Documentation only changes
`style`	Formatting, whitespace, no code change
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependencies
`ci`	CI configuration files and scripts
`chore`	Other changes that don’t modify src or test files
`revert`	Reverts a previous commit

Scopes

The scope identifies which part of PX4 is affected. Common scopes:

Scope	Area
`ekf2`	Extended Kalman Filter (state estimation)
`mavlink`	MAVLink messaging protocol
`commander`	Commander and mode management
`navigator`	Mission, RTL, Land, and other navigation modes
`sensors`	Sensor drivers and processing
`drivers`	Hardware drivers
`boards/px4_fmu-v6x`	Board-specific changes (use the board name)
`mc_att_control`	Multicopter attitude control
`mc_pos_control`	Multicopter position control
`fw_att_control`	Fixed-wing attitude control
`vtol`	VTOL-specific logic
`actuators`	Mixer and actuator output
`battery`	Battery monitoring and estimation
`logger`	On-board logging
`param`	Parameter system
`simulation`	SITL, Gazebo, SIH
`ci`	Continuous integration and workflows
`docs`	Documentation
`build`	CMake, toolchain, build system
`uorb`	Inter-module messaging

For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: src/modules/ekf2/ uses ekf2, src/drivers/imu/ uses drivers/imu, .github/workflows/ uses ci.

Breaking changes

Append ! before the colon to indicate a breaking change:

feat(ekf2)!: remove deprecated height fusion API

Good commit messages

``` feat(ekf2): add height fusion timeout

File truncated at 100 lines see the full file

# Contributing to PX4-Autopilot We follow the [GitHub flow](https://guides.github.com/introduction/flow/) development model. ## Fork the project, then clone your repo First [fork and clone](https://help.github.com/articles/fork-a-repo) the project. ## Create a feature branch Always branch off `main` for new features. ``` git checkout -b mydescriptivebranchname ``` ## Edit and build the code The [developer guide](https://docs.px4.io/main/en/development/development.html) explains how to set up the development environment on Mac OS, Linux or Windows. ### Coding standards All C/C++ code must follow the [PX4 coding style](https://docs.px4.io/main/en/contribute/code.html). Formatting is enforced by [astyle](http://astyle.sourceforge.net/) in CI (`make check_format`). Code quality checks run via [clang-tidy](https://clang.llvm.org/extra/clang-tidy/). Pull requests that fail either check will not be merged. Python code is checked with [mypy](https://mypy-lang.org/) and [flake8](https://flake8.pycqa.org/). ## Commit message convention PX4 uses [conventional commits](https://www.conventionalcommits.org/) for all commit messages and PR titles. ### Format ``` type(scope): short description of the change ``` | Part | Rule | |------|------| | **type** | Category of change (see types table below) | | **scope** | The module, driver, board, or area of PX4 affected | | **`!`** (optional) | Append before `:` to mark a breaking change | | **description** | What the change does, at least 5 characters, written in imperative form | ### Types | Type | Description | |------|-------------| | `feat` | A new feature | | `fix` | A bug fix | | `docs` | Documentation only changes | | `style` | Formatting, whitespace, no code change | | `refactor` | Code change that neither fixes a bug nor adds a feature | | `perf` | Performance improvement | | `test` | Adding or correcting tests | | `build` | Build system or external dependencies | | `ci` | CI configuration files and scripts | | `chore` | Other changes that don't modify src or test files | | `revert` | Reverts a previous commit | ### Scopes The scope identifies which part of PX4 is affected. Common scopes: | Scope | Area | |-------|------| | `ekf2` | Extended Kalman Filter (state estimation) | | `mavlink` | MAVLink messaging protocol | | `commander` | Commander and mode management | | `navigator` | Mission, RTL, Land, and other navigation modes | | `sensors` | Sensor drivers and processing | | `drivers` | Hardware drivers | | `boards/px4_fmu-v6x` | Board-specific changes (use the board name) | | `mc_att_control` | Multicopter attitude control | | `mc_pos_control` | Multicopter position control | | `fw_att_control` | Fixed-wing attitude control | | `vtol` | VTOL-specific logic | | `actuators` | Mixer and actuator output | | `battery` | Battery monitoring and estimation | | `logger` | On-board logging | | `param` | Parameter system | | `simulation` | SITL, Gazebo, SIH | | `ci` | Continuous integration and workflows | | `docs` | Documentation | | `build` | CMake, toolchain, build system | | `uorb` | Inter-module messaging | For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: `src/modules/ekf2/` uses `ekf2`, `src/drivers/imu/` uses `drivers/imu`, `.github/workflows/` uses `ci`. ### Breaking changes Append `!` before the colon to indicate a breaking change: ``` feat(ekf2)!: remove deprecated height fusion API ``` ### Good commit messages ``` feat(ekf2): add height fusion timeout File truncated at 100 lines [see the full file](https://github.com/px4/px4-autopilot/tree/main/CONTRIBUTING.md)

No version for distro melodic showing github. Known supported distros are highlighted in the buttons above.

px4-autopilot repository

px4

ROS Distro
github

Repository Summary

Description
Checkout URI	https://github.com/px4/px4-autopilot.git
VCS Type	git
VCS Version	main
Last Updated	2026-03-16
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
px4	1.14.0

README

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.}

Quick Start

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.

File truncated at 100 lines see the full file

CONTRIBUTING

Contributing to PX4-Autopilot

We follow the GitHub flow development model.

Fork the project, then clone your repo

First fork and clone the project.

Create a feature branch

Always branch off main for new features.

git checkout -b mydescriptivebranchname

Edit and build the code

The developer guide explains how to set up the development environment on Mac OS, Linux or Windows.

Coding standards

All C/C++ code must follow the PX4 coding style. Formatting is enforced by astyle in CI (make check_format). Code quality checks run via clang-tidy. Pull requests that fail either check will not be merged.

Python code is checked with mypy and flake8.

Commit message convention

PX4 uses conventional commits for all commit messages and PR titles.

Format

type(scope): short description of the change

Part	Rule
type	Category of change (see types table below)
scope	The module, driver, board, or area of PX4 affected
`!` (optional)	Append before `:` to mark a breaking change
description	What the change does, at least 5 characters, written in imperative form

Types

Type	Description
`feat`	A new feature
`fix`	A bug fix
`docs`	Documentation only changes
`style`	Formatting, whitespace, no code change
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependencies
`ci`	CI configuration files and scripts
`chore`	Other changes that don’t modify src or test files
`revert`	Reverts a previous commit

Scopes

The scope identifies which part of PX4 is affected. Common scopes:

Scope	Area
`ekf2`	Extended Kalman Filter (state estimation)
`mavlink`	MAVLink messaging protocol
`commander`	Commander and mode management
`navigator`	Mission, RTL, Land, and other navigation modes
`sensors`	Sensor drivers and processing
`drivers`	Hardware drivers
`boards/px4_fmu-v6x`	Board-specific changes (use the board name)
`mc_att_control`	Multicopter attitude control
`mc_pos_control`	Multicopter position control
`fw_att_control`	Fixed-wing attitude control
`vtol`	VTOL-specific logic
`actuators`	Mixer and actuator output
`battery`	Battery monitoring and estimation
`logger`	On-board logging
`param`	Parameter system
`simulation`	SITL, Gazebo, SIH
`ci`	Continuous integration and workflows
`docs`	Documentation
`build`	CMake, toolchain, build system
`uorb`	Inter-module messaging

For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: src/modules/ekf2/ uses ekf2, src/drivers/imu/ uses drivers/imu, .github/workflows/ uses ci.

Breaking changes

Append ! before the colon to indicate a breaking change:

feat(ekf2)!: remove deprecated height fusion API

Good commit messages

``` feat(ekf2): add height fusion timeout

File truncated at 100 lines see the full file

# Contributing to PX4-Autopilot We follow the [GitHub flow](https://guides.github.com/introduction/flow/) development model. ## Fork the project, then clone your repo First [fork and clone](https://help.github.com/articles/fork-a-repo) the project. ## Create a feature branch Always branch off `main` for new features. ``` git checkout -b mydescriptivebranchname ``` ## Edit and build the code The [developer guide](https://docs.px4.io/main/en/development/development.html) explains how to set up the development environment on Mac OS, Linux or Windows. ### Coding standards All C/C++ code must follow the [PX4 coding style](https://docs.px4.io/main/en/contribute/code.html). Formatting is enforced by [astyle](http://astyle.sourceforge.net/) in CI (`make check_format`). Code quality checks run via [clang-tidy](https://clang.llvm.org/extra/clang-tidy/). Pull requests that fail either check will not be merged. Python code is checked with [mypy](https://mypy-lang.org/) and [flake8](https://flake8.pycqa.org/). ## Commit message convention PX4 uses [conventional commits](https://www.conventionalcommits.org/) for all commit messages and PR titles. ### Format ``` type(scope): short description of the change ``` | Part | Rule | |------|------| | **type** | Category of change (see types table below) | | **scope** | The module, driver, board, or area of PX4 affected | | **`!`** (optional) | Append before `:` to mark a breaking change | | **description** | What the change does, at least 5 characters, written in imperative form | ### Types | Type | Description | |------|-------------| | `feat` | A new feature | | `fix` | A bug fix | | `docs` | Documentation only changes | | `style` | Formatting, whitespace, no code change | | `refactor` | Code change that neither fixes a bug nor adds a feature | | `perf` | Performance improvement | | `test` | Adding or correcting tests | | `build` | Build system or external dependencies | | `ci` | CI configuration files and scripts | | `chore` | Other changes that don't modify src or test files | | `revert` | Reverts a previous commit | ### Scopes The scope identifies which part of PX4 is affected. Common scopes: | Scope | Area | |-------|------| | `ekf2` | Extended Kalman Filter (state estimation) | | `mavlink` | MAVLink messaging protocol | | `commander` | Commander and mode management | | `navigator` | Mission, RTL, Land, and other navigation modes | | `sensors` | Sensor drivers and processing | | `drivers` | Hardware drivers | | `boards/px4_fmu-v6x` | Board-specific changes (use the board name) | | `mc_att_control` | Multicopter attitude control | | `mc_pos_control` | Multicopter position control | | `fw_att_control` | Fixed-wing attitude control | | `vtol` | VTOL-specific logic | | `actuators` | Mixer and actuator output | | `battery` | Battery monitoring and estimation | | `logger` | On-board logging | | `param` | Parameter system | | `simulation` | SITL, Gazebo, SIH | | `ci` | Continuous integration and workflows | | `docs` | Documentation | | `build` | CMake, toolchain, build system | | `uorb` | Inter-module messaging | For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: `src/modules/ekf2/` uses `ekf2`, `src/drivers/imu/` uses `drivers/imu`, `.github/workflows/` uses `ci`. ### Breaking changes Append `!` before the colon to indicate a breaking change: ``` feat(ekf2)!: remove deprecated height fusion API ``` ### Good commit messages ``` feat(ekf2): add height fusion timeout File truncated at 100 lines [see the full file](https://github.com/px4/px4-autopilot/tree/main/CONTRIBUTING.md)

No version for distro noetic showing github. Known supported distros are highlighted in the buttons above.

px4-autopilot repository

px4

ROS Distro
github

Repository Summary

Description
Checkout URI	https://github.com/px4/px4-autopilot.git
VCS Type	git
VCS Version	main
Last Updated	2026-03-16
Dev Status	UNKNOWN
Released	UNRELEASED
Contributing	Help Wanted (-) Good First Issues (-) Pull Requests to Review (-)

Packages

Name	Version
px4	1.14.0

README

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.}

Quick Start

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.

File truncated at 100 lines see the full file

CONTRIBUTING

Contributing to PX4-Autopilot

We follow the GitHub flow development model.

Fork the project, then clone your repo

First fork and clone the project.

Create a feature branch

Always branch off main for new features.

git checkout -b mydescriptivebranchname

Edit and build the code

The developer guide explains how to set up the development environment on Mac OS, Linux or Windows.

Coding standards

All C/C++ code must follow the PX4 coding style. Formatting is enforced by astyle in CI (make check_format). Code quality checks run via clang-tidy. Pull requests that fail either check will not be merged.

Python code is checked with mypy and flake8.

Commit message convention

PX4 uses conventional commits for all commit messages and PR titles.

Format

type(scope): short description of the change

Part	Rule
type	Category of change (see types table below)
scope	The module, driver, board, or area of PX4 affected
`!` (optional)	Append before `:` to mark a breaking change
description	What the change does, at least 5 characters, written in imperative form

Types

Type	Description
`feat`	A new feature
`fix`	A bug fix
`docs`	Documentation only changes
`style`	Formatting, whitespace, no code change
`refactor`	Code change that neither fixes a bug nor adds a feature
`perf`	Performance improvement
`test`	Adding or correcting tests
`build`	Build system or external dependencies
`ci`	CI configuration files and scripts
`chore`	Other changes that don’t modify src or test files
`revert`	Reverts a previous commit

Scopes

The scope identifies which part of PX4 is affected. Common scopes:

Scope	Area
`ekf2`	Extended Kalman Filter (state estimation)
`mavlink`	MAVLink messaging protocol
`commander`	Commander and mode management
`navigator`	Mission, RTL, Land, and other navigation modes
`sensors`	Sensor drivers and processing
`drivers`	Hardware drivers
`boards/px4_fmu-v6x`	Board-specific changes (use the board name)
`mc_att_control`	Multicopter attitude control
`mc_pos_control`	Multicopter position control
`fw_att_control`	Fixed-wing attitude control
`vtol`	VTOL-specific logic
`actuators`	Mixer and actuator output
`battery`	Battery monitoring and estimation
`logger`	On-board logging
`param`	Parameter system
`simulation`	SITL, Gazebo, SIH
`ci`	Continuous integration and workflows
`docs`	Documentation
`build`	CMake, toolchain, build system
`uorb`	Inter-module messaging

For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: src/modules/ekf2/ uses ekf2, src/drivers/imu/ uses drivers/imu, .github/workflows/ uses ci.

Breaking changes

Append ! before the colon to indicate a breaking change:

feat(ekf2)!: remove deprecated height fusion API

Good commit messages

``` feat(ekf2): add height fusion timeout

File truncated at 100 lines see the full file

# Contributing to PX4-Autopilot We follow the [GitHub flow](https://guides.github.com/introduction/flow/) development model. ## Fork the project, then clone your repo First [fork and clone](https://help.github.com/articles/fork-a-repo) the project. ## Create a feature branch Always branch off `main` for new features. ``` git checkout -b mydescriptivebranchname ``` ## Edit and build the code The [developer guide](https://docs.px4.io/main/en/development/development.html) explains how to set up the development environment on Mac OS, Linux or Windows. ### Coding standards All C/C++ code must follow the [PX4 coding style](https://docs.px4.io/main/en/contribute/code.html). Formatting is enforced by [astyle](http://astyle.sourceforge.net/) in CI (`make check_format`). Code quality checks run via [clang-tidy](https://clang.llvm.org/extra/clang-tidy/). Pull requests that fail either check will not be merged. Python code is checked with [mypy](https://mypy-lang.org/) and [flake8](https://flake8.pycqa.org/). ## Commit message convention PX4 uses [conventional commits](https://www.conventionalcommits.org/) for all commit messages and PR titles. ### Format ``` type(scope): short description of the change ``` | Part | Rule | |------|------| | **type** | Category of change (see types table below) | | **scope** | The module, driver, board, or area of PX4 affected | | **`!`** (optional) | Append before `:` to mark a breaking change | | **description** | What the change does, at least 5 characters, written in imperative form | ### Types | Type | Description | |------|-------------| | `feat` | A new feature | | `fix` | A bug fix | | `docs` | Documentation only changes | | `style` | Formatting, whitespace, no code change | | `refactor` | Code change that neither fixes a bug nor adds a feature | | `perf` | Performance improvement | | `test` | Adding or correcting tests | | `build` | Build system or external dependencies | | `ci` | CI configuration files and scripts | | `chore` | Other changes that don't modify src or test files | | `revert` | Reverts a previous commit | ### Scopes The scope identifies which part of PX4 is affected. Common scopes: | Scope | Area | |-------|------| | `ekf2` | Extended Kalman Filter (state estimation) | | `mavlink` | MAVLink messaging protocol | | `commander` | Commander and mode management | | `navigator` | Mission, RTL, Land, and other navigation modes | | `sensors` | Sensor drivers and processing | | `drivers` | Hardware drivers | | `boards/px4_fmu-v6x` | Board-specific changes (use the board name) | | `mc_att_control` | Multicopter attitude control | | `mc_pos_control` | Multicopter position control | | `fw_att_control` | Fixed-wing attitude control | | `vtol` | VTOL-specific logic | | `actuators` | Mixer and actuator output | | `battery` | Battery monitoring and estimation | | `logger` | On-board logging | | `param` | Parameter system | | `simulation` | SITL, Gazebo, SIH | | `ci` | Continuous integration and workflows | | `docs` | Documentation | | `build` | CMake, toolchain, build system | | `uorb` | Inter-module messaging | For changes spanning multiple subsystems, use the primary one affected. Look at the directory path of the files you changed to find the right scope: `src/modules/ekf2/` uses `ekf2`, `src/drivers/imu/` uses `drivers/imu`, `.github/workflows/` uses `ci`. ### Breaking changes Append `!` before the colon to indicate a breaking change: ``` feat(ekf2)!: remove deprecated height fusion API ``` ### Good commit messages ``` feat(ekf2): add height fusion timeout File truncated at 100 lines [see the full file](https://github.com/px4/px4-autopilot/tree/main/CONTRIBUTING.md)

px4-autopilot repository

ROS Distrogithub

Repository Summary

Packages

README

About

Why PX4

Supported Vehicles

Quick Start

Documentation & Resources

Community

Contributing

CONTRIBUTING

Contributing to PX4-Autopilot

Fork the project, then clone your repo

Create a feature branch

Edit and build the code

Coding standards

Commit message convention

Format

Types

Scopes

Breaking changes

Good commit messages

px4-autopilot repository

ROS Distrogithub

Repository Summary

Packages

README

About

Why PX4

Supported Vehicles

Quick Start

Documentation & Resources

Community

Contributing

CONTRIBUTING

Contributing to PX4-Autopilot

Fork the project, then clone your repo

Create a feature branch

Edit and build the code

Coding standards

Commit message convention

Format

Types

Scopes

Breaking changes

Good commit messages

px4-autopilot repository

ROS Distrogithub

Repository Summary

Packages

README

About

Why PX4

Supported Vehicles

Quick Start

Documentation & Resources

Community

Contributing

CONTRIBUTING

Contributing to PX4-Autopilot

Fork the project, then clone your repo

Create a feature branch

Edit and build the code

Coding standards

Commit message convention

Format

Types

Scopes

Breaking changes

Good commit messages

px4-autopilot repository

ROS Distrogithub

Repository Summary

Packages

README

About

Why PX4

Supported Vehicles

ROS Distro
github

ROS Distro
github

ROS Distro
github

ROS Distro
github

ROS Distro
github

ROS Distro
github

ROS Distro
github