APM Planner 2.0 is the Qt ground control station for ArduPilot

What APM Planner is in the ArduPilot stack

APM Planner 2.0 is the ArduPilot ground control station, and the repository description puts it as APM Planner Ground Control Station (Qt).

That sits inside a larger ecosystem, and the topic list names the parts: apm-planner, arducopter, ardupilot, arduplane, ardurover, autonomous-vehicles, autopilot, copter, gcs, ground-control-station, open-source, pixhawk, plane, robot-operating-system and ros. The three vehicle families are the important part, because a ground control station that only flew multirotors would be a different project.

The primary language is C++, and the interface is QML, with a qml/ directory at the root alongside src/. The homepage is ardupilot.org and the documentation for this tool is at ardupilot.org/planner2.

There is more than one ground control station in the ArduPilot world, and the repository does not pretend otherwise. The root contains apm_planner.pro and qgroundcontrol.qrc, and the file naming in the tree shows the lineage: the project descends from the QGroundControl codebase, which is why the QGC-prefixed configuration files are still there. The README points at the credits and contributors page at ardupilot.org/planner2/docs/credits-and-contributors.html, with Bill Bonney as maintainer and contributors including Michael Carpenter and Arne-W.

The support arrangement is also stated. Support is handled in the forum, with the README pointing at the APM Planner 2.0 category on the ArduPilot discussion forum, and it says explicitly that the issues tracker here is kept for known problems and enhancements. There are two Discord channels linked, one for APM Planner 2 and the general ArduPilot server.

The licence is recorded as a custom one that GitHub cannot classify, with license.txt at the root, so the terms for redistribution are worth reading before you assume they are permissive.

Building on macOS

The macOS instructions are the most complete in the README, and they start with the Qt dependency.

Preferred using homebrew to install, and the command is:

brew install qt@5 cmake ninja sdl2
brew link qt5 --force

The note that follows matters on a machine with both Qt versions installed: you may need to unlink qt6 with brew unlink qt6. The linking of qt5 is forced for the same reason, since a machine that has Homebrew's qt6 present will have the wrong Qt active by default.

The README then lists the alternatives for getting Qt 5.15.x, in a collapsed section. There is the TARBALL option, downloading the source from the Qt download site for the 5.15 releases. There are the Qt Offline Installers, with the note that the last one available is stuck at Qt5.15.2. And there is using the aqt installer, which is also stuck at 5.15.2. The author's own preference is stated plainly: I suggest using the internet if you want to install this way. Brew is easyist IMHO!

The build is then given twice, once for CMake and once for QMake.

The CMake route clones the repository, creates a build directory and points CMake at the Homebrew Qt prefix:

cd $HOME
git clone https://github.com/ArduPilot/apm_planner.git
cd apm_planner
mkdir build
cd build
cmake cmake -G Ninja .. -DCMAKE_PREFIX_PATH="/opt/homebrew/Cellar/qt@5/5.15.16_2;/opt/homebrew"

The CMAKE_PREFIX_PATH points at a specific Homebrew Cellar version, qt@5/5.15.16_2, which is the kind of detail that saves an afternoon on an Apple Silicon machine where the version directory name is not what you would guess.

The QMake route is shorter and ends with launching the app:

qmake -spec macx-clang apm_planner.pro
make -j$(nproc)
open ./release/apmplanner2.app

The macx-clang specifier is required, because the default spec on a modern macOS is not the one that produces a working build of this project.

Building on Linux, and the Ubuntu version trap

The Linux section is a list of package sets for several distributions, hidden in collapsible sections, and the differences between them are not cosmetic.

For Ubuntu 25.04 the package list is:

sudo apt-get update
sudo apt-get install git build-essential
sudo apt-get install qt5-qmake qtbase5-dev qtscript5-dev libqt5serialport5-dev libqt5svg5-dev \
    libqt5opengl5-dev qml-module-qtquick-controls libsdl1.2-dev libsndfile1-dev flite1-dev libssl-dev \
	libudev-dev libsdl2-dev

For Ubuntu 22.04 LTS the set is close to identical but adds libqt5webkit5-dev, which is absent from the 25.04 list, and the reason is given in a note above the block. On Ubuntu 22.04 use only the native (ubuntu) Qt version 5.15.3, because the official Qt 5.15.2 which comes with the Qt Maintenance tool only supports OpenSSL 1.1.1, which is not supported by Ubuntu 22.04 anymore.

That note is the single most useful piece of the Linux documentation. The failure it prevents is an OpenSSL version mismatch deep inside a Qt build, which presents as a link error rather than as a package problem, and the fix is not to install a different OpenSSL but to use the distribution's Qt.

The Ubuntu 18.04 LTS list adds qt5-default, the qtdeclarative5-qtquick2-plugin and the Python packages python-serial and python-pexpect, and the Fedora list is a yum variant with qt-devel and the matching qt5-qtscript-devel, qt5-qtwebkit-devel, qt5-qtserialport-devel, qt5-qtsvg-devel, qt5-qtdeclarative-devel and qt5-qtquick1-devel packages, plus pyserial, python-pexpect, SDL-devel, libsndfile-devel, flite-devel, openssl-devel, libudev-devel and SDL2-devel.

The SDL, flite, sndfile and OpenSSL entries are not for the GUI alone. SDL is used for video streaming, flite for the text-to-speech voice output, sndfile for audio handling and OpenSSL for the encrypted link to the vehicle.

The build itself is the same two routes as on macOS, and the CMake variant ends with running the binary directly:

cmake cmake -G Ninja .. 
./apmplanner2 # Runs the application

Windows, and a README that says so

The Windows section is short, and the reason is stated in the heading itself.

NOTE: Needs Updating

What follows describes a build environment from a previous era of the project, with Visual Studio 2013 as Option 1 for a native compile and MinGW cross-compile as Option 2, and the Qt online installer instructions naming Qt 5.5 MSVC2013 and MinGW 4.9.2 options.

The detail is included in the README as it stands, and the walkthrough of configuring QtCreator is worth noting for what it says about the era. You set the Compilers tab and the Qt Versions tab under Auto-detected, then add a kit pairing the desired compiler with the matching Qt version, and if your desired Qt version is not listed, or you installed one after the initial setup, you click Add and point at the qmake.exe. The example paths given are c:/Qt/5.5/msvc2013/bin/qmake.exe and c:/Qt/5.5/mingw492_32/bin/qmake.exe.

That is a workflow from 2014, and the section header warns the reader that it is out of date. The honest reading is that the macOS and Linux build paths are the maintained ones and that a Windows developer should expect to do their own work, whether with a newer Qt or with the Visual Studio versions the current Qt releases support.

The rest of the repository shows how much of the tooling is conventional Qt project machinery. There is apm_planner.pro for QMake, CMakeLists.txt for the CMake build, QGCSetup.pri and QGCExternalLibs.pri for the shared configuration, qgroundcontrol.qrc and qgroundcontrol.rc for resources, a qgcunittest.pro and a qgcvideo.pro for the unit test and video subprojects, and user_config.pri.dist as the template for local build settings. There is also a Vagrantfile with .vagrantconfig.yml, a debian/ directory and a redhat/ directory for packaging, a docker/ directory, a packaging/ directory and a deploy/ directory.

The dist file naming is itself informative, because a .dist suffix is the convention for a file that is copied rather than edited, so the local build configuration is expected to diverge from the repository's.

The pieces around the application

The top-level entries show the parts of the project that are not the application itself, and several of them are directly relevant to what a user does with it.

The Drivers/ directory and the avrdude/ directory together are the firmware upload path. This is a ground control station for autopilot hardware, and the ability to flash firmware to supported boards over the USB connection is part of that job, which is why uploader tools like avrdude are vendored rather than assumed to be on the path. The sik_uploader/ directory is the Silabs-based uploader used with some boards.

The uploader/ directory is the companion piece for other board types.

The config.tests/ directory holds configuration tests, and apm_planner_version.json at the root is how the application learns its own version, which is what lets the tool report a version to the vehicle and to the user.

The doc/ directory, along with the common/, libs/, files/ and data/ directories hold the shared code, third-party libraries, resources and data files.

The tools/ directory holds supporting tooling, and the scripts/ directory holds build and release scripts. There is a release_notes.txt, an Installation instructions.rtf at the root for the Windows installer path, and a CONTRIBUTING.md for contributors.

The.travis.yml at the root points at Travis CI as the build system, and the README carries a Travis CI build status badge for the master branch.

Taken together, the tree is that of a mature, long-lived desktop application with a firmware flasher, several build systems, several packaging targets and a large amount of vendored third-party code. That is the profile of a tool that has been maintained across a decade of hardware generations, and it is also why the README's Windows gap matters.

Where APM Planner fits, and where it stops

The comparison worth making is with QGroundControl, and with the fact that most new ArduPilot users will be pointed at the other tool.

The lineage makes the comparison unavoidable. APM Planner descends from the QGroundControl codebase and shares its file naming, its QML interface structure and much of its C++ core. What differs is where each project has gone since: QGroundControl has taken its own path since the projects diverged, while APM Planner remains a Qt and QML application in the older tradition.

The argument for APM Planner is that it is a mature, self-consistent desktop application with a long history of supporting Pixhawk hardware, and that the build instructions for macOS and Linux are complete and current enough to be followed. The argument against it is the README's own Windows note and the release cadence, with 2.0.30 Stable dated 2025-07-02 and the last push on 2026-04-18.

The limits are worth stating plainly. The project targets Qt 5 and has to work around the OpenSSL and Qt packaging changes in current distributions, which is the tax you pay for a codebase that predates Qt 6. The Windows build path is explicitly out of date. The build from source assumes you are willing to install a specific Qt version, and on some distributions that means using the distribution's Qt rather than the official one.

There is also a scope point. This is a ground control station, not an autopilot. It configures, monitors and plans for vehicles running ArduPilot firmware, and it can flash firmware to the board, but the flight controller itself lives in a different repository.

The licence situation deserves a look too. It is recorded as a custom one that GitHub cannot classify, with license.txt at the root, and for an application that people install to fly real vehicles, the terms are worth reading rather than assuming they are BSD or GPL.

The last push was on 2026-04-18 and the repository is not archived, so the project is still being touched, and the support arrangement through the forum and Discord means an active community sits around the code even where the release cadence is slow.

Editorial conclusion

APM Planner 2.0 suits a user of Pixhawk hardware who wants a ground control station in the Qt tradition rather than the newer QGroundControl, since it drives the same ArduPilot firmware across ArduCopter, ArduPlane and ArduRover and its build instructions are complete for macOS and Linux. It is the wrong tool if you are starting a new project, because the README's Windows section is explicitly marked as needing updating and the last stable release is 2.0.30 from July 2025. Before you build on Linux, read the note on Ubuntu 22.04, which explains why the native Qt 5.15.3 is used there instead of the official Qt 5.15.2.

Frequently asked questions

Official sources

1. ArduPilot/apm_planner on GitHub
2. Issues
3. Project website
4. README
5. Releases