ArduPilot is not a normal app to self-host.

It is autopilot firmware: C++ control code that can run on flight controllers, Linux boards, simulation targets, rovers, boats, aircraft, submarines, and antenna trackers.

That makes it one of the more serious open-source robotics projects you can study from a software architecture point of view.

What is ArduPilot?

ArduPilot is an open-source autopilot project for autonomous and remotely operated vehicles.

The repository description names ArduPlane, ArduCopter, ArduRover, and ArduSub as source code in the project. GitHub currently reports the repository as C++, GPL-3.0 licensed, and using master as the default branch. It is a large public project with thousands of forks and many active issues, which is exactly what you would expect from mature robotics infrastructure. Source

I inspected commit:

9165d22419406556fc9815d9f4e3e299e13713a8

The checked-in release notes visible in this tree include 4.7.1, dated 31-August-2026.

What Can It Control?

The main vehicle stacks are:

  • ArduCopter: multirotors, helicopters, and related copter frames.
  • ArduPlane: fixed-wing aircraft and QuadPlane/VTOL configurations.
  • Rover: ground rovers, boats, balance bots, and surface vehicles.
  • ArduSub: underwater vehicles.
  • Blimp: lighter-than-air vehicles.
  • AntennaTracker: tracking antennas.

This is why the repo feels different from a single-purpose firmware project. The vehicle directories are important, but much of the engineering weight is in the shared libraries/ layer.

Architecture

The simplest way to understand ArduPilot is:

Vehicle app -> shared vehicle framework -> libraries -> HAL -> board or simulator

Top-level vehicle directories provide the vehicle-specific behavior:

ArduCopter/
ArduPlane/
Rover/
ArduSub/
Blimp/
AntennaTracker/

Shared systems live under libraries/:

  • AP_Vehicle handles the common vehicle lifecycle and mode interface.
  • AP_HAL defines the hardware abstraction boundary.
  • AP_HAL_ChibiOS, AP_HAL_Linux, and AP_HAL_SITL provide concrete platform layers.
  • AP_Scheduler runs the main cooperative task loop.
  • AP_Param defines the parameter system used by firmware and ground-control tools.
  • GCS_MAVLink handles MAVLink ground-control communication.
  • AP_NavEKF2 and AP_NavEKF3 handle navigation estimation.
  • AP_Scripting adds Lua scripting.
  • AP_DDS and Tools/ros2 support ROS 2/DDS workflows.
  • SITL contains simulator models and virtual sensor plumbing.

For example, Copter declares a task table with fast tasks for inertial sensor updates, rate control, motor output, AHRS/EKF reads, flight mode updates, land/crash detection, and slower periodic tasks for GPS, RC input, rangefinders, battery/compass checks, logging, and MAVLink send/receive.

That task table tells you a lot about ArduPilot’s design: deterministic periodic work, explicit timing budgets, and vehicle-specific scheduling on top of shared libraries.

SITL: The Best Way to Try It

SITL means software-in-the-loop.

The official ArduPilot developer docs describe SITL as a way to run Plane, Copter, or Rover without hardware by building the autopilot code with a normal C++ compiler into a native executable. The docs also describe SITL as using simulated sensor data from flight dynamics models and supporting vehicle types such as multirotors, fixed-wing aircraft, ground vehicles, underwater vehicles, camera gimbals, antenna trackers, and optional sensors. ArduPilot SITL Docs

That is the right starting point for most readers.

You can study behavior, inspect MAVLink messages, run missions, attach debuggers, and test changes without putting hardware in the loop.

Building the Code

ArduPilot uses Waf.

The official build docs point developers to platform setup guides and then to Waf-based builds for Linux, macOS, and Windows/WSL. They also explicitly warn not to use sudo for Waf builds unless the docs say to. ArduPilot Build Docs

The basic shape is:

git clone --recurse-submodules https://github.com/ArduPilot/ardupilot.git
cd ardupilot
./waf configure --board sitl
./waf copter

To list supported boards:

./waf list_boards

To build for a hardware target:

./waf configure --board CubeBlack
./waf copter

The repo also documents a Docker-based development image:

docker build --rm -t ardupilot-dev .
docker run --rm -it -v "$PWD:/ardupilot" ardupilot-dev ./waf configure --board=sitl
docker run --rm -it -v "$PWD:/ardupilot" ardupilot-dev ./waf copter

That Dockerfile is a clean build environment. It is not a server deployment.

Local Field Test

I cloned the repository and ran a bounded local check.

Environment:

Python 3.12.3
g++ 13.3.0
cmake not installed

Commands:

./waf --version
./waf list_boards
./waf configure --board=sitl
timeout 180 ./waf --targets bin/arducopter
python3 Tools/autotest/sim_vehicle.py --help

Results:

  • ./waf --version initialized the Waf submodule and reported Waf 2.0.27.
  • ./waf list_boards completed and returned a large supported-board matrix.
  • ./waf configure --board=sitl completed successfully with the native compiler.
  • The targeted ArduCopter SITL build stopped because the Python package empy==3.3.4 was missing.
  • sim_vehicle.py --help stopped because pymavlink was missing.

That is a fair result for a clean workstation that has compilers but not the ArduPilot developer Python environment. I did not run the Ubuntu prereq installer because it would install system packages.

For a proper setup, use the project installer:

Tools/environment_install/install-prereqs-ubuntu.sh -y

Then restart the shell so the environment changes are loaded.

Why Developers Study ArduPilot

There are several patterns worth studying even if you are not building drones:

  • HAL boundary: one codebase targets real boards, Linux boards, and SITL.
  • Cooperative scheduling: task tables make timing visible.
  • Parameter metadata: configuration is strongly tied to firmware behavior and ground-control UX.
  • Simulation-first development: SITL lets developers test behavior without hardware.
  • Protocol maturity: MAVLink support is central, not bolted on.
  • Vehicle reuse: Copter, Plane, Rover, and Sub share many primitives without becoming the same application.
  • Safety culture: arming checks, failsafes, flight modes, logging, and release procedures are part of the core engineering surface.

Release Notes Snapshot

The checked-in 4.7.1 release notes list changes across boards, Plane/QuadPlane, Copter, libraries, drivers, and tools.

Highlights include:

  • added or updated board support for ARKV6S, CORVON_V5, DAKEFPV boards, FlywooF405S, KakuteH7-Wing, and ORBITH743v2;
  • Plane/QuadPlane parameter and TECS throttle behavior changes;
  • Copter fixes around Auto mode arc waypoint behavior, RTL continuation, Circle mode entry, Simple mode, and jerk parameter naming;
  • library/driver fixes in AC_WPNAV, AP_Filesystem, AP_FlashStorage, AP_GPS, AP_Mount, AP_NavEKF, AP_OSD, AP_RangeFinder, ChibiOS, GCS_MAVLink, and gimbal handling.

FAQ

Is ArduPilot self-hosted software?
Not in the usual web-app sense. ArduPilot is firmware and simulation software. You can run SITL locally, build firmware, and use ground-control tools, but there is no always-on web service to deploy with Docker Compose.
Does ArduPilot have a UI?
The firmware repo itself is not a UI app. Operators usually interact with ArduPilot through ground-control software such as Mission Planner, MAVProxy, QGroundControl-compatible MAVLink tooling, or vehicle-specific setup pages in the ArduPilot docs.
Can I try ArduPilot without hardware?
Yes. Use SITL. It builds a native executable and connects it to simulated vehicle dynamics and sensors. That is the safest way to learn, test parameters, inspect MAVLink, or work on code changes.
Should I flash custom builds to a real drone?
Only if you know what changed, have a safe test plan, and understand the hardware. Autopilot firmware is safety-critical. For real vehicles, use stable releases unless you have a specific reason to test custom firmware.
What language is ArduPilot written in?
The core firmware is C++. The tooling and test ecosystem includes a lot of Python, and Lua is used for onboard scripting examples and applets.

Conclusion

ArduPilot is worth writing about because it is real open-source robotics infrastructure.

The codebase shows what happens when a project has to support many vehicle types, many boards, real-time-ish control loops, simulation, logging, safety checks, field upgrades, and a large user community.

For most developers, the right first step is not buying hardware. It is getting SITL running, watching MAVLink traffic, changing parameters, and reading the scheduler tables. That gives you a much better feel for the system before any motors are involved.