How to Contribute Code to the ArduPilot Project

ArduPilot is safety-critical autopilot software used in real vehicles. Every contribution must be correct, well-tested, and clearly explained so that human maintainers can review and trust it. This page walks through the full contribution process — from forking to merge — and covers the coding style and CI checks your pull request must pass.

Before you start

For any non-trivial change, open a discussion on discuss.ardupilot.org or the ArduPilot Discord before writing code. This is especially important if your change affects flight safety, refactors a core library, or touches a subsystem you are unfamiliar with. Maintainers may know of existing work or have opinions on the approach.

Never submit code that supports weaponisation, autonomously controls aircraft carrying humans, or is solely intended as a portfolio piece with no real benefit to the project. Such contributions will be closed without review.

Contribution workflow

Fork and clone

Fork the repository on GitHub, then clone your fork with all submodules:

git clone --recurse-submodules https://github.com/YOUR_USERNAME/ardupilot.git
cd ardupilot

Create a feature branch

Always work on a named branch, never directly on master. Use a short descriptive name:

git checkout -b ap-terrain-cache-size

Write and format your code

Follow the coding style rules below. Run astyle on the files you modified (not the entire project) before committing.

astyle --options=Tools/CodeStyle/astylerc MyLibrary.cpp MyLibrary.h

Build and test locally

Configure for SITL and build the affected vehicle. For a board-specific change, configure for that board instead.

./waf configure --board sitl
./waf copter   # or plane, rover, sub, etc.

Then run the relevant SITL autotest suite:

Tools/autotest/autotest.py build.Copter test.Copter

Commit with a well-formed message

Write a commit message in Subsystem: short description format (see below). One logical change per commit.

git add libraries/AP_Terrain/AP_Terrain.cpp
git commit -m "AP_Terrain: add configurable cache size parameter"

Push and open a pull request

Push your branch to your fork and open a PR against ArduPilot/ardupilot master. Fill in the PR template — describe what changed, why, and how you tested it. If AI tools assisted you, say so explicitly in the PR description.

git push origin ap-terrain-cache-size

Commit message format

ArduPilot’s CI rejects commits that do not follow the subsystem-prefix convention. Every first line must contain a colon:

Subsystem: short description of the change

Keep the first line under 72 characters. An optional body paragraph can explain motivation, background, or testing details.

Examples

AP_Terrain: add configurable cache size parameter

Adds SCR_CACHE_SIZE parameter so operators can tune memory usage on
boards with limited RAM. Default keeps existing behaviour.

Copter: fix altitude hold in guided mode

Tools: improve autotest terrain data handling

libraries: fix typo in AP_GPS backend selection

Use the library or vehicle directory name as the subsystem prefix. When in doubt, check git log on the file you changed to see what prefix existing commits use.

No merge commits. Always rebase onto master before opening a PR: git rebase upstream/master. Squash fixup! commits before requesting review.

Coding style

ArduPilot enforces C++ style via astyle with the config in Tools/CodeStyle/astylerc.

Rule	Convention
Indentation	4 spaces, no tabs
Braces	Linux/K&R — opening brace on same line
Line endings	LF only, no CRLF
Header guards	`#pragma once` (never `#ifndef`)
Single-line `if`/`for`	Always add braces
Class names	`AP_` or `AC_` prefix, PascalCase: `AP_GPS`, `AC_PID`
Method names	`snake_case`: `get_altitude()`, `update_state()`
Constants	`UPPER_SNAKE_CASE`: `AP_MOTORS_MOT_1`
Feature guards	`#if AP_<NAME>_ENABLED` / `#endif // AP_<NAME>_ENABLED`

Additional conventions from AGENTS.md:

Use extern const AP_HAL::HAL& hal; in .cpp files that need hardware access.
Prefer is_zero(), is_positive(), is_negative() over direct float comparisons.
Use GCS_SEND_TEXT() for user-visible messages, not printf.
Use AP_HAL::millis() / AP_HAL::micros() instead of platform-specific time functions.
Do not introduce platform-specific code in shared libraries — use the HAL.
Never modify the modules/ submodule directory.

Python files in Tools/autotest/ and similar locations must pass flake8 (max line 127) and include the # AP_FLAKE8_CLEAN marker at the top of new files.

Testing

All changes must be tested. ArduPilot has three complementary test layers:

SITL autotest
GTest unit tests
Python tests

The primary integration test system. Tests launch a simulated vehicle, execute flight scenarios, and assert correct behaviour.

# Run all tests for a vehicle (with rebuild)
Tools/autotest/autotest.py build.Copter test.Copter

# Run a single named test
Tools/autotest/autotest.py build.Copter test.Copter.RTLYaw

# Run plane tests
Tools/autotest/autotest.py build.Plane test.Plane

Test suites are Python files in Tools/autotest/: arducopter.py, arduplane.py, rover.py, ardusub.py.

C++ unit tests for library-level logic. Located in libraries/<lib>/tests/ and use AP_gtest.h.

#include <AP_gtest.h>

TEST(TerrainTest, CacheSize) {
    AP_Terrain terrain;
    EXPECT_EQ(terrain.get_cache_size(), DEFAULT_CACHE_SIZE);
}

Build and run a specific test:

./waf configure --board sitl
./waf --targets tests/test_math
build/sitl/tests/test_math

Located in Tools/autotest/unittest/ and tests/. Run with pytest:

pytest Tools/autotest/unittest/

Never fabricate test results, log snippets, or claim testing that was not actually performed. Maintainers will ask for evidence, and falsified testing is grounds for immediate rejection.

CI checks

Every PR triggers the following automated checks. Run CI against your own fork first (push to your fork and check the Actions tab) before opening a PR against the main repository.

SITL vehicle tests

Full autotest suites for ArduCopter, ArduPlane, Rover, ArduSub, AntennaTracker, and Blimp. A failure here means the change broke existing vehicle behaviour.

C++ unit tests (GCC + Clang)

All GTest tests in libraries/*/tests/ compiled with both GCC and Clang. Catches type errors and logic bugs.

ChibiOS hardware board builds

Builds for a matrix of real flight controller boards. Ensures the code compiles in a resource-constrained embedded environment.

astyle formatting check

Verifies C++ style matches Tools/CodeStyle/astylerc. Even a single misplaced brace will fail this check.

flake8 Python linting

Runs on all Python files marked AP_FLAKE8_CLEAN. Max line length is 127 characters.

Commit message format

Rejects any commit missing a : subsystem prefix, any merge commit, and any fixup! commit.

Binary size tracking

Records the compiled binary size for key boards. Large unexpected increases will be flagged.

Pre-commit hooks

Checks for CRLF line endings, spelling errors (codespell), files larger than a threshold, and XML/YAML validity.

What not to do

Do not change parameter index numbers in AP_GROUPINFO macros. The index is baked into user EEPROM and changing it silently corrupts stored configurations.
Do not modify the modules/ directory. Submodules are managed as separate upstream projects.
Do not add unnecessary dependencies. Every extra byte of RAM and flash affects the smallest supported boards.
Do not generate speculative refactors. Keep changes minimal and targeted. Large restructuring PRs are difficult to review and are often closed.
Do not remove or weaken existing tests without a documented reason.
Do not move code without a reason. Preserve file structure to keep git blame history useful.

Getting help

Channel	Purpose
GitHub Issues	Bug reports and feature requests
GitHub Pull Requests	Code review and submission
Discord `#dev` channel	Real-time developer chat
Discourse — Development	Longer design discussions

ArduPilot is maintained by volunteers. Reviews can take days or weeks. Respond to all reviewer comments promptly and concisely. If CI fails, investigate and fix it — do not ask maintainers to merge with a failing build.

Get Started

Vehicles

Core Concepts

Development

How to Contribute Code to the ArduPilot Project

Before you start

Contribution workflow

Commit message format

Examples

Coding style

Testing

CI checks

What not to do

Getting help

Build docs developers (and LLMs) love

Get Started

Vehicles

Core Concepts

Development

Documentation Index

​Before you start

​Contribution workflow

​Commit message format

​Examples

​Coding style

​Testing

​CI checks

​What not to do

​Getting help

Build docs developers (and LLMs) love

Before you start

Contribution workflow

Commit message format

Examples

Coding style

Testing

CI checks

What not to do

Getting help