Clone the project from GitHub:
git clone --recursive https://github.com/ArduPilot/ardupilot.git
cd ardupilot
You can also read more about the build system in the Waf Book.
waf should always be called from the locally cloned ardupilot root directory for the local branch you are trying to build from.
Note
Do not run waf
with sudo
! This leads to permission and environment problems.
There are several commands in the build system for advanced usage, but here we list some basic and more used commands as example.
-
Build ArduCopter
Below shows how to build ArduCopter for the Pixhawk2/Cube. Many other boards are supported and the next section shows how to get a full list of them.
./waf configure --board CubeBlack ./waf copter
The first command should be called only once or when you want to change a configuration option. One configuration often used is the
--board
option to switch from one board to another one. For example we could switch to SkyViper GPS drone and build again:./waf configure --board skyviper-v2450 ./waf copter
If building for the bebop2 the binary must be built statically:
./waf configure --board bebop --static ./waf copter
The "arducopter" binary should appear in the
build/<board-name>/bin
directory. -
List available boards
It's possible to get a list of supported boards on ArduPilot with the command below
./waf list_boards
Here are some commands to configure waf for commonly used boards:
./waf configure --board bebop --static # Bebop or Bebop2 ./waf configure --board edge # emlid edge ./waf configure --board fmuv3 # 3DR Pixhawk 2 boards ./waf configure --board navio2 # emlid navio2 ./waf configure --board Pixhawk1 # Pixhawk1 ./waf configure --board CubeBlack # Hex/ProfiCNC Cube Black (formerly known as Pixhawk 2.1) ./waf configure --board Pixracer # Pixracer ./waf configure --board skyviper-v2450 # SkyRocket's SkyViper GPS drone using ChibiOS ./waf configure --board sitl # software-in-the-loop simulator ./waf configure --board sitl --debug # software-in-the-loop simulator with debug symbols
-
List of available vehicle types
Here is a list of the most common vehicle build targets:
./waf copter # All multirotor types ./waf heli # Helicopter types ./waf plane # Fixed wing airplanes including VTOL ./waf rover # Ground-based rovers and surface boats ./waf sub # ROV and other submarines ./waf antennatracker # Antenna trackers ./waf AP_Periph # AP Peripheral
-
Clean the build
Commands
clean
anddistclean
can be used to clean the objects produced by the build. The first keeps theconfigure
information, cleaning only the objects for the current board. The second cleans everything for every board, including the savedconfigure
information.Cleaning the build is very often not necessary and discouraged. We do incremental builds reducing the build time by orders of magnitude.
If submodules are failing to be synchronized,
submodulesync
may be used to resync the submodules. This is usually necessary when shifting development between stable releases or a stable release and the master branch.In some some cases
submodule_force_clean
may be necessary. This removes all submodules and then performs asubmodulesync
. (Note whitelisted modules like esp_idf is not removed.) -
Upload or install
Build commands have a
--upload
option in order to upload the binary built to a connected board. This option is supported by Pixhawk and Linux-based boards. The command below uses the--targets
option that is explained in the next item../waf --targets bin/arducopter --upload
For Linux boards you need first to configure the IP of the board you are going to upload to. This is done on configure phase with:
./waf configure --board <board> --rsync-dest <destination>
The commands below give a concrete example (board and destination IP will change according to the board used):
./waf configure --board navio2 --rsync-dest root@192.168.1.2:/ ./waf --target bin/arducopter --upload
This allows to set a destination to which the
--upload
option will upload the binary. Under the hood it installs to a temporary location and callsrsync <temp_install_location>/ <destination>
.On Linux boards there's also an install command, which will install to a certain directory, just like the temporary install above does. This can be used by distributors to create .deb, .rpm or other package types:
./waf copter DESTDIR=/my/temporary/location ./waf install
-
Use different targets
The build commands in the items above use
copter
as argument. This builds all binaries that fall under the "copter" group. See the section Advanced usage below for more details regarding groups.This shows a list of all possible targets:
./waf list
For example, to build only a single binary:
# Quad frame of ArduCopter ./waf --targets bin/arducopter # unit test of our math functions ./waf --targets tests/test_math
-
Use clang instead of gcc
Currently, gcc is the default on linux, and clang is used for MacOS. Building with clang on linux can be accomplished by setting the CXX environment variables during the configure step, e.g.:
CXX=clang++ CC=clang ./waf configure --board=sitl
Note: Your clang binary names may differ.
-
Other options
It's possible to see all available commands and options:
./waf -h
Also, take a look on the Advanced section below.
This section contains some explanations on how the Waf build system works and how you can use more advanced features.
Waf build system is composed of commands. For example, the command below
(configure
) is for configuring the build with all the options used by this
particular build.
# Configure the Linux board
./waf configure --board=linux
Consequently, in order to build, a "build" command is issued, thus waf build
.
That is the default command, so calling just waf
is enough:
# Build programs from bin group
./waf
# Waf also accepts '-j' option to parallelize the build.
./waf -j8
By default waf tries to parallelize the build automatically to all processors
so the -j
option is usually not needed, unless you are using icecc (thus
you want a bigger value) or you don't want to stress your machine with
the build.
Program groups are used to represent a class of programs. They can be used to build all programs of a certain class without having to specify each program. It's possible for two groups to overlap, except when both groups are main groups. In other words, a program can belong to more than one group, but only to one main group.
There's a special group, called "all", that comprises all programs.
The main groups form a partition of all programs. Besides separating the programs logically, they also define where they are built.
The main groups are:
- bin: the main binaries, that is, ardupilot's main products - the vehicles and Antenna Tracker
- tools
- examples: programs that show how certain libraries are used or to simply test their operation
- benchmarks: requires
--enable-benchmarks
during configurarion - tests: basically unit tests to ensure changes don't break the system's logic
All build files are placed under build/<board>/
, where <board>
represents
the board/platform you selected during configuration. Each main program group
has a folder with its name directly under build/<board>/
. Thus, a program
will be stored in build/<board>/<main_group>/
, where <main_group>
is the
main group the program belongs to. For example, for a linux build, arduplane,
which belongs to the main group "bin", will be located at
build/linux/bin/arduplane
.
Those are groups for ardupilot's main products. They contain programs for the product they represent. Currently only the "copter" group has more than one program - one for each frame type.
The main product groups are:
- antennatracker
- copter
- plane
- rover
Ardupilot adds to waf an option called --program-group
, which receives as
argument the group you want it to build. For a build command, if you don't pass
any of --targets
or --program-group
, then the group "bin" is selected by
default. The option --program-group
can be passed multiple times.
Examples:
# Group bin is the default one
./waf
# Build all vehicles and Antenna Tracker
./waf --program-group bin
# Build all benchmarks and tests
./waf --program-group benchmarks --program-group tests
For less typing, you can use the group name as the command to waf. Examples:
# Build all vehicles and Antenna Tracker
./waf bin
# Build all examples
./waf examples
# Build arducopter binaries
./waf copter
In order to build a specific program, you just need to pass its path relative
to build/<board>/
to the option --targets
. Example:
# Build arducopter for quad frame
./waf --targets bin/arducopter
# Build vectors unit test
./waf --targets tests/test_vectors
The command check
builds all programs and then executes the relevant tests.
In that context, a relevant test is a program from the group "tests" that makes
one of the following statements true:
- it's the first time the test is built since the last cleanup or when the project was cloned.
- the program had to be rebuilt (due to modifications in the code or dependencies, for example)
- the test program failed in the previous check.
That is, the tests are run only if necessary. If you want waf to run all tests,
then you can use either option --alltests
or the shortcut command
check-all
.
Examples:
# Build everything and run relevant tests
./waf check
# Build everything and run all tests
./waf check --alltests
# Build everything and run all tests
./waf check-all
It's possible to pass the option --debug
to the configure
command. That
will set compiler flags to store debugging information in the binaries so that
you can use them with gdb
, for example. That option might come handy when using SITL.
The waf
binary on root tree is actually a wrapper to the real waf
that's
maintained in its own submodule. It's possible to call the latter directly via
./modules/waf/waf-light
or to use an alias if you prefer typing waf
over
./waf
.
alias waf="<ardupilot-directory>/modules/waf/waf-light"
There's also a make wrapper called Makefile.waf
. You can use
make -f Makefile.waf help
for instructions on how to use it.
You can use waf --help
to see information about commands and options built-in
to waf as well as some quick help on those added by ardupilot.