M6-T2: Introduction to ArduPilot

Learning objectives

After this lesson, you should be able to:

• Describe ArduPilot’s structure (vehicle code, libraries, HAL) and its vehicle types.
• Compare ArduPilot and PX4 on licence, architecture, interfaces and tooling.
• Map concepts between the two (modes, parameters, logs, companion links).
• Choose between them with a documented, testable rationale.

Conceptual explanation

Implementation-specific Both projects change often and each has strengths in different areas. Statements here are general and based on the public documentation at the time of writing; check the current documentation of both projects before deciding. No performance ranking is claimed.

ArduPilot is an open-source autopilot with separate vehicle codebases (ArduCopter, ArduPlane, Rover, ArduSub, Blimp, Antenna Tracker) built on shared libraries and a hardware abstraction layer (AP_HAL) supporting several operating-system back ends (ChibiOS on most flight controllers, and Linux and others). It is licensed under the GPLv3, whereas PX4 uses a permissive BSD 3-clause licence. The licence matters if you plan to ship modified firmware in a closed product.

Differences that commonly matter in a project:

Engineering intuition

The two projects arrived at similar solutions to the same problems: an EKF estimator, a cascaded controller, MAVLink, modes and failsafes. The practical differences are in the surroundings: licensing, the way the code is organised, how you script or extend it, and which hardware and tools your supplier supports. A team that has strong experience with one will be more effective with it than the ideal choice on paper.

For an autonomy project the stronger question is the interface to your software. Check, for the specific versions you will use, how setpoints are sent, how external position is fed in, what timestamps are expected and how failsafes behave when the companion goes silent. The details differ, and the safe integration depends on them.

Mathematical formulation

No new mathematics: both use the same estimation and control theory. A useful quantitative step is a decision matrix with weighted criteria, which makes the rationale explicit and reviewable:

The weights $w_{i}$ encode project priorities (licence constraints can be a hard gate rather than a weighted criterion), and each score $s_{i}$ should cite evidence: a documentation page, a simulation result or a test. A sensitivity check, varying each weight by ±20 %, shows whether the ranking is robust or an artefact of one assumption.

Architecture and data flow

The companion-computer data flow is the same shape for both: sensors → autopilot estimator → state out (MAVLink or DDS) → companion perception and planning → setpoints in (MAVLink or DDS) → autopilot controller. The differences are the message sets and conventions: for example the frame (ENU in ROS, NED in the autopilot) conversions, the message that carries external odometry, and the mode in which external setpoints are accepted (PX4 offboard; ArduPilot guided). Document these in the interface control document.

Real-world UAV applications

• Selecting an autopilot for a new platform and recording the decision.
• Porting a companion-computer application between the two.
• Using ArduPilot’s Lua scripting for small on-board behaviours.
• Comparing the two in SITL on the same mission as a sanity check.

Implementation example

A decision matrix as a small script so the weights and scores are versioned with the project. The numbers below are placeholders to show the mechanics, not a statement about either autopilot: fill in your own evidence.

import numpy as np
criteria = ['licence fits product', 'vehicle type supported', 'companion interface fit', 'team experience', 'supplier hardware support', 'tooling for tests']
w = np.array([0.25, 0.20, 0.20, 0.15, 0.10, 0.10])            # project priorities (sum to 1)
scores = {'option A': np.array([5, 4, 4, 3, 4, 4]), 'option B': np.array([3, 4, 5, 4, 4, 4])}   # PLACEHOLDERS: replace with evidence-based scores
for name, s in scores.items(): print(name, round(float(w @ s), 2))
rng = np.random.default_rng(0); wins = {k: 0 for k in scores}
for _ in range(2000):                                         # sensitivity: perturb weights by up to +-20 %
    wp = w * (1 + rng.uniform(-0.2, 0.2, w.size)); wp /= wp.sum()
    best = max(scores, key=lambda k: wp @ scores[k]); wins[best] += 1
print('ranking stability:', {k: v / 2000 for k, v in wins.items()})
assert abs(w.sum() - 1) < 1e-12

Common engineering mistakes

Failure modes

Debugging approach

1. Reproduce the same mission in SITL on both before deciding.
2. Diff the parameter sets and failsafe behaviours for the same scenario.
3. Check the exact firmware version against the documentation version.
4. Keep a mapping table of concepts and parameter names for your project.

Practical exercises

1. Make a decision matrix for a hypothetical inspection quadrotor with a ROS 2 companion, citing the documentation for each score.
2. List the failsafe behaviours of both for loss of the companion link and compare them (read both documents).
3. Write the interface description for external odometry for each autopilot.
4. Identify the licence obligations for shipping a modified firmware under each.

Interview questions

Write an answer in your own words, then reveal the model answer. Nothing is sent anywhere.

References and further reading

Primary papers, official documentation and standards. Each claim above that is specific to a tool or version points here.

• ArduPilot Copter documentation
• ArduPilot developer documentation
• PX4 User and Developer Guide
• GNU General Public License v3
• BSD 3-Clause License (Open Source Initiative)

What’s next