# Building PX4 Software
PX4 can be built on the console or in an IDE, for both simulated and hardware targets.
Before following these instructions you must first install the Developer Toolchain for your host operating system and target hardware.
For solutions to common build problems see Troubleshooting below.
# Download the PX4 Source Code
The PX4 source code is stored on Github in the PX4/PX4-Autopilot (opens new window) repository. To get the very latest version onto your computer, enter the following command into a terminal:
git clone https://github.com/PX4/PX4-Autopilot.git --recursive
This is all you need to do just to build the latest code. GIT Examples > Contributing code to PX4 provides a lot more information about using git to contribute to PX4.
# First Build (Using the jMAVSim Simulator)
First we'll build a simulated target using a console environment. This allows us to validate the system setup before moving on to real hardware and an IDE.
Navigate into the PX4-Autopilot directory and start jMAVSim using the following command:
make px4_sitl jmavsim
This will bring up the PX4 console below:
You may need to start QGroundControl before proceeding, as the default PX4 configuration requires a ground control connection before takeoff. This can be downloaded from here (opens new window).
The drone can be flown by typing:
pxh> commander takeoff
The drone can be landed by typing
commander land and the whole simulation can be stopped by doing CTRL+C (or by entering
Flying the simulation with the ground control station is closer to the real operation of the vehicle. Click on a location in the map while the vehicle is flying (takeoff flight mode) and enable the slider. This will reposition the vehicle.
make px4_sitl gazebo
# NuttX / Pixhawk Based Boards
# Building for NuttX
To build for NuttX- or Pixhawk- based boards, navigate into the PX4-Autopilot directory and then call
make with the build target for your board.
For example, to build for Pixhawk 4 hardware you could use the following command:
cd PX4-Autopilot make px4_fmu-v5_default
A successful run will end with similar output to:
-- Build files have been written to: /home/youruser/src/PX4-Autopilot/build/px4_fmu-v4_default [954/954] Creating /home/youruser/src/PX4-Autopilot/build/px4_fmu-v4_default/px4_fmu-v4_default.px4
The first part of the build target
px4_fmu-v4 indicates the firmware for a particular flight controller hardware.
The following list shows the build commands for the Pixhawk standard boards:
- Pixhawk 4:
- Pixhawk 4 Mini:
- CUAV V5+:
- CUAV V5 nano:
- Pixhawk 3 Pro:
- Pixhawk Mini:
- Pixhawk 2 (Cube Black):
- mRo Pixhawk:
make px4_fmu-v3_default(supports 2MB Flash)
- Holybro pix32:
- Pixhawk 1:
You must use a supported version of GCC to build this board (e.g. the same as used by CI/docker) or remove modules from the build. Building with an unsupported GCC may fail, as PX4 is close to the board's 1MB flash limit.
- Pixhawk 1 with 2 MB flash:
Build commands for non-Pixhawk NuttX fight controllers (and for all other-boards) are provided in the documentation for the individual flight controller boards.
_default suffix is the firmware configuration.
This is optional (i.e. you can also build using
make bitcraze_crazyflie, etc.).
# Uploading Firmware (Flashing the board)
upload to the make commands to upload the compiled binary to the autopilot hardware via USB.
make px4_fmu-v4_default upload
A successful run will end with this output:
Erase : [====================] 100.0% Program: [====================] 100.0% Verify : [====================] 100.0% Rebooting. [100%] Built target upload
# Other Boards
Build commands for other boards are given the board-specific flight controller pages (usually under a heading Building Firmware).
You can also list all configuration targets using the command:
# Compiling in a Graphical IDE
VSCode is the officially supported (and recommended) IDE for PX4 development. It is easy to set up and can be used to compile PX4 for both simulation and hardware environments.
# General Build Errors
Many build problems are caused by either mismatching submodules or an incompletely cleaned-up build environment.
Updating the submodules and doing a
distclean can fix these kinds of errors:
git submodule update --recursive make distclean
# Flash overflowed by XXX bytes
region 'flash' overflowed by XXXX bytes error indicates that the firmware is too large for the target hardware platform.
This is common for
make px4_fmu-v2_default builds, where the flash size is limited to 1MB.
If you're building the vanilla master branch, the most likely cause is using an unsupported version of GCC. In this case, install the version specified in the Developer Toolchain instructions.
If building your own branch, it is possibly you have increased the firmware size over the 1MB limit. In this case you will need to remove any drivers/modules that you don't need from the build.
# macOS: Too many open files error
MacOS allows a default maximum of 256 open files in all running processes. The PX4 build system opens a large number of files, so you may exceed this number.
The build toolchain will then report
Too many open files for many files, as shown below:
/usr/local/Cellar/gcc-arm-none-eabi/20171218/bin/../lib/gcc/arm-none-eabi/7.2.1/../../../../arm-none-eabi/bin/ld: cannot find NuttX/nuttx/fs/libfs.a: Too many open files
The solution is to increase the maximum allowed number of open files (e.g. to 300). You can do this in the macOS Terminal for each session:
- Run this script Tools/mac_set_ulimit.sh (opens new window), or
- Enter this command:
ulimit -S -n 300
# macOS Catalina: Problem running cmake
As of macOS Catalina 10.15.1 there may be problems when trying to build the simulator with cmake. If you have build problems on this platform then try run the following command in your terminal:
xcode-select --install sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* /usr/local/include/
# Ubuntu 18.04: Compile errors involving arm_none_eabi_gcc
Build issues related to
arm_none_eabi_gccmay be due to a broken g++ toolchain installation.
You can verify that this is the case by checking for missing dependencies using:
arm-none-eabi-gcc --version arm-none-eabi-g++ --version arm-none-eabi-gdb --version arm-none-eabi-size --version
Example of bash output with missing dependencies:
arm-none-eabi-gdb --version arm-none-eabi-gdb: command not found
This can be resolved by removing and reinstalling the compiler (opens new window).
# Ubuntu 18.04: Visual Studio Code is unable to watch for file changes in this large workspace
# Failed to import Python packages
"Failed to import" errors when running the
make px4_sitl jmavsim command indicates that some Python packages are not installed (where expected).
Failed to import jinja2: No module named 'jinja2' You may need to install it using: pip3 install --user jinja2
If you have already installed these dependencies this may be because there is more than one Python version on the computer (e.g. Python 2.7.16 Python 3.8.3), and the module is not present in the version used by the build toolchain.
You should be able to fix this by explicitly installing the dependencies as shown:
pip3 install --user pyserial empy toml numpy pandas jinja2 pyyaml pyros-genmsg packaging
# PX4 Make Build Targets
The previous sections showed how you can call make to build a number of different targets, start simulators, use IDEs etc. This section shows how make options are constructed and how to find the available choices.
The full syntax to call make with a particular configuration and initialization file is:
make [VENDOR_][MODEL][_VARIANT] [VIEWER_MODEL_DEBUGGER_WORLD]
VENDOR_MODEL_VARIANT: (also known as
- VENDOR: The manufacturer of the board:
nxp, etc. The vendor name for Pixhawk series boards is
- MODEL: The board model "model":
- VARIANT: Indicates particular configurations: e.g.
lpe, which contain components that are not present in the
defaultconfiguration. Most commonly this is
default, and may be omitted.
You can get a list of all available
CONFIGURATION_TARGET options using the command below:
VIEWER: This is the simulator ("viewer") to launch and connect:
nonecan be used if you want to launch PX4 and wait for a simulator (jmavsim, gazebo, or some other simulator). For example,
make px4_sitl none_irislaunches PX4 without a simulator (but with the iris airframe).
MODEL: The vehicle model to use (e.g.
tailsitter, etc), which will be loaded by the simulator. The environment variable
PX4_SIM_MODELwill be set to the selected model, which is then used in the startup script to select appropriate parameters.
DEBUGGER: Debugger to use:
callgrind. For more information see Simulation Debugging.
WORLD: (Gazebo only). Set a the world (PX4/sitl_gazebo/worlds (opens new window)) that is loaded. Default is empty.world (opens new window). For more information see Gazebo > Loading a Specific World.
You can get a list of all available
VIEWER_MODEL_DEBUGGER_WORLD options using the command below:
make px4_sitl list_vmd_make_targets
- Most of the values in the
VIEWER_MODEL_DEBUGGERhave defaults, and are hence optional. For example,
gazebois equivalent to
- You can use three underscores if you want to specify a default value between two other settings.
gazebo___gdbis equivalent to
- You can use a
VIEWER_MODEL_DEBUGGERto start PX4 and wait for a simulator. For example start PX4 using
make px4_sitl_default noneand jMAVSim using
VENDOR_MODEL_VARIANT options map to particular px4board configuration files in the PX4 source tree under the /boards (opens new window) directory.
VENDOR_MODEL_VARIANT maps to a configuration file boards/VENDOR/MODEL/VARIANT.px4board
px4_fmu-v5_default corresponds to boards/px4/fmu-v5/default.px4board (opens new window)).
Additional make targets are discussed in relevant sections:
bloaty_compare_master: Binary Size Profiling
# Firmware Version & Git Tags
The PX4 Firmware Version and Custom Firmware Version are published using the MAVLink AUTOPILOT_VERSION (opens new window) message, and displayed in the QGroundControl Setup > Summary airframe panel:
These are extracted at build time from the active git tag for your repo tree.
The git tag should be formatted as
<PX4-version>-<vendor-version> (e.g. the tag in the image above was set to
If you use a different git tag format, versions information may not be displayed properly.