ArduPilot: what the repository actually contains, and how to build it for SITL

What ArduPilot actually ships, and who the repository is for

The README describes autopilot software that controls "almost any vehicle system imaginable," and the top-level directories back that up: ArduCopter, ArduPlane, Rover, ArduSub, AntennaTracker and Blimp each hold a vehicle implementation. This is firmware source. It is written in C++ and licensed GPL-3.0, with the full text in COPYING.txt.

The audience is narrower than the description suggests. Someone who wants to fly a quadcopter does not need this repository at all; they need a compiled firmware image and a ground station. The repository is for people building firmware, adding a board, porting a subsystem, or scripting against the vehicle code. The README points users to ardupilot.org for per-vehicle documentation and to discuss.ardupilot.org for support, which is a signal that the code and the user-facing product are deliberately separated.

One thing the README is explicit about is the development span: the project says it has been under development since 2010. The repository is not archived, and the most recent push recorded is 2026-07-27, matching the 4.7.0 releases for Tracker, Sub and Rover. That is recent enough that the tree is moving, but the README gives no release cadence and no support window, so do not infer one.

One repository, five vehicle binaries, and a shared library layer

The layout is the mechanism. Each vehicle directory under the repository root is a separate build target, and libraries/ holds the shared code that all of them link against. A change to a library touches every vehicle; a change inside ArduCopter touches only the copter binary. That is why the maintainer list in the README is organised by both vehicle and subsystem: Plane and AntennaTracker have one reviewer, Rover another, Sub another, and subsystems such as GPS, scripting, CAN, compass, DataFlash and the EKF variants have their own owners.

The build system is waf, vendored as a submodule. The Makefile is a thin wrapper: it defines VEHICLES as copter plane rover sub heli, resolves the waf binary at modules/waf/waf-light, and generates a target for every combination of board and vehicle. The Makefile's own help text says it is "intended to provide convenience for basic and common build tasks" and recommends using waf directly if you need more. That is an honest description of a wrapper, and the practical consequence is that anything unusual (a custom configuration, a partial build) means reading waf documentation rather than the Makefile.

Board support is data-driven. The Makefile obtains its board list by running waf list_boards, so the set of supported targets is whatever the build system reports at that moment, not a static list in the README. That also means the README cannot tell you whether a specific flight controller is supported. Only the build system can.

Installing the toolchain and building for SITL

There is no package to install and no binary release in this repository. You get the source and build it. The Dockerfile pins Ubuntu 24.04 as its default base image and copies Tools/environment_install/install-prereqs-ubuntu.sh into the image, which is the same prerequisite script used for a native Ubuntu setup. The Dockerfile also sets JAVA_HOME to Java 17 because, as its comment states, Ubuntu 24.04 defaults to Java 21 and Gradle 7.6 does not support it.

Start by cloning with submodules, since waf lives in modules/:

git clone https://github.com/ArduPilot/ardupilot.git
cd ardupilot
git submodule update --init --recursive

The Makefile initialises the submodule itself if modules/waf/waf-light is missing, but doing it up front avoids a surprise mid-build. Next, confirm which boards the build system knows about:

make list_boards

That runs waf list_boards and prints the supported targets. The Makefile takes the first line of that output as its board list, so a board missing here cannot be built by the wrapper. To configure and build a Linux SITL target, the Makefile accepts the board name as a target:

make linux

Because the Makefile's default rule is %-configure and it appends build, this configures for the linux board and builds it. The README's CI badges include test_sitl_copter, test_sitl_plane, test_sitl_rover, test_sitl_sub and test_sitl_tracker, which tells you SITL is exercised per vehicle in continuous integration. What the README does not give is a command to launch the simulated vehicle or connect a ground station; that lives in the developer wiki, not here.

Where the repository stops and the ground station begins

The most common mismatch between expectations and this repository concerns Mission Planner. Searches for it are frequent, but Mission Planner is not in this tree. The top-level entries are vehicle directories, libraries, modules, Tools, tests, benchmarks and docs. There is no ground control station source here. The README links to ardupilot.org and to the per-vehicle wikis for user documentation, and those are where the flight-side workflow lives.

The same boundary applies to firmware images. Nothing in the README describes a download of a prebuilt .apj or .px4 file. Releases exist (Tracker-4.7.0, Sub-4.7.0 and Rover-4.7.0 are listed with 2026-07-27 timestamps), but the README does not document how a user flashes them or where the binaries are hosted. If your goal is "install ArduPilot firmware on a flight controller," the repository is the wrong starting point; the wiki is.

A third boundary is hardware support. The README names maintainers associated with boards including Pixhawk, Pixhawk2, PixRacer, Cube, NavIO, BeagleBone Blue, PocketPilot, VRBrain, Bebop and Erle-Brain 2. That is a historical contributor list, not a compatibility matrix, and it does not tell you whether a current board works with a current release. Treat it as evidence that board ports are contributed by individuals, which has a maintenance consequence: a board whose maintainer stops contributing does not announce that fact in the README.

The GPL-3.0 question, and what it costs to stay current

ArduPilot is GPL-3.0. The README links both an overview page and the full text in COPYING.txt. The practical implication for a product team is that distributing a vehicle running modified ArduPilot firmware carries source-distribution obligations. None of that is spelled out in the README beyond the link, and the overview page is the document to read. This is not legal advice; the licence text governs.

Upgrade cost is dominated by the vehicle split. Because libraries/ is shared, a change there affects every vehicle at once, which is good for consistency and bad for isolating risk. The repository ships tests/ and benchmarks/ directories and CI workflows for each vehicle, plus test_chibios.yml, test_linux_sbc.yml, test_replay.yml, test_unit_tests.yml and test_size.yml. That is a substantial amount of machinery, and it exists because a shared library change has to be validated against multiple vehicle binaries and multiple board families. A fork that modifies a library inherits that validation burden.

There is also no versioned support policy in the README. Releases are tagged per vehicle (the 4.7.0 tags are separate for Tracker, Sub and Rover), which means "the current ArduPilot version" is not a single number. If your process assumes one upstream version, that assumption is wrong here.

ArduPilot versus PX4: the difference is the vehicle model

PX4 is the obvious comparison and it shows up directly in search data. The architectural difference visible from this repository is that ArduPilot is organised around vehicle types as first-class build targets. ArduCopter, ArduPlane, Rover, ArduSub, AntennaTracker and Blimp are separate programs sharing libraries. PX4's published architecture centres on a single middleware and module set with vehicle variants configured at runtime, which is a different way of drawing the same boundary.

The practical consequences run in both directions. ArduPilot's split means a rover fix cannot regress a plane binary through the vehicle layer, but it also means the maintainer list fragments: the README assigns Plane and AntennaTracker to one person, Rover to another, Sub to another, and TradHeli to yet another. PX4's unified module model makes cross-vehicle reuse more direct but concentrates change in shared code. Neither is strictly safer.

If your vehicle is a submarine or an antenna tracker, ArduPilot has a dedicated target and PX4's published scope is narrower, so the comparison is not symmetric. If your interest is the broader ecosystem of flight controllers and companion computers, both projects support comparable hardware classes and the choice usually comes down to which community's documentation and tooling you already know.

Editorial conclusion

Adopt ArduPilot if you are building or integrating a vehicle and want one codebase covering plane, copter, rover, sub, blimp and antenna tracker, with GPL-3.0 terms you have read. Do not adopt it if you need a desktop ground station: Mission Planner is a separate product and this repository does not contain it. Before committing, run make list_boards to confirm your target board is listed, and check the wiki for your specific frame because the README itself gives no tuning guidance.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes