Mission Planner: the ArduPilot ground station that still assumes Windows

What Mission Planner is for, and who actually needs it

Mission Planner is a ground control station: the desktop program an operator runs on a laptop to talk to an ArduPilot flight controller over a telemetry link or USB. It is not the autopilot. ArduPilot runs on the vehicle; Mission Planner runs on the ground and gives you the views and controls for that vehicle. The README points to the project site at ardupilot.org/planner and a forum category specifically for ground control software, which tells you the intended audience is people flying ArduPilot hardware rather than developers of other autopilots.

The repository layout shows the scope. There are folders for GCSViews, Log, LogAnalyzer, Antenna, Joystick, NoFly, Grid, GeoRef and MagCalib, plus a ParameterFactMetaData.xml at the top level. That is a program that does flight view, log analysis, antenna tracking, joystick input, no-fly zone handling, survey grid generation, georeferencing and compass calibration. If you only need to upload a mission and watch a map, you are using a fraction of it.

It is also a Windows program in C#. The README is blunt: building on other systems is not supported. The Android build is on the Play Store, and Linux runs through Mono with the caveat that not all functions are available. Native macOS and iOS support is labelled experimental and not recommended for inexperienced users.

How Mission Planner talks to a vehicle and to the network

The connection model is conventional for a GCS. Mission Planner opens a link to the autopilot (serial, UDP or TCP depending on your telemetry hardware), then exchanges MAVLink messages: parameter reads and writes, mission upload and download, and telemetry streams for the flight data screen. The parameter side is backed by metadata. The top-level ParameterFactMetaData.xml and the caches under the Mission Planner data directory exist so the configuration screens can show human-readable names, ranges and units instead of raw parameter indices.

The external services table in the README is the most informative part of the documentation, and it is worth reading before you deploy this anywhere with a restrictive firewall. Mission Planner contacts firmware.ardupilot.org for stable updates, firmware metadata, firmware itself, user alerts, gstreamer, SRTM elevation data and SITL. It contacts raw.githubusercontent.com for old parameter metadata and SITL config files, api.github.com for ArduPilot preload parameter files, and autotest.ardupilot.org for dataflash log metadata and parameter metadata. For those four, the README says disabling is not possible. A separate CDN at firmware.oborne.me is checked once per day at startup for Mission Planner updates, and that one can be disabled by editing missionplanner.exe.config.

Telemetry is not the only data leaving the machine. Google Analytics is used for anonymous statistics covering screen loads, exceptions and crashes, connect events, startup timing and firmware uploads, and it is disabled under Config > Planner > OptOut Anon Stats. Cloudflare is used for geolocation, for no-fly zone selection, and the README lists it as not possible to disable. Several other integrations (Altitude Angel UTM data, CubePilot SB2 reporting, Hong Kong no-fly zones, RFDesign firmware) only fire when the user enables them or enters details.

Installing Mission Planner and connecting to a vehicle for the first time

For most users the install is a single MSI from the ArduPilot firmware server. The README gives the stable download link directly, and the repository also publishes a latest zip for the Mono path.

On Windows, download and run the installer from the URL in the README:

# stable Windows installer
http://firmware.ardupilot.org/Tools/MissionPlanner/MissionPlanner-latest.msi

After installation, launch Mission Planner and pick your connection in the link selector. The README does not walk through the connection dialog, so treat the link type and port as hardware-specific: USB for a direct board connection, or the UDP/TCP endpoint your telemetry radio exposes.

On Ubuntu, the README's tested path is Mono, not a native build. It was tested on Ubuntu 20.04. Install the Mono packages it lists:

sudo apt install mono-complete mono-runtime libmono-system-windows-forms4.0-cil libmono-system-core4.0-cil libmono-winforms4.0-cil libmono-corlib4.0-cil libmono-system-management4.0-cil libmono-system-xml-linq4.0-cil

Then download the zip build, unzip it, change into that directory and start the executable through Mono:

https://firmware.ardupilot.org/Tools/MissionPlanner/MissionPlanner-latest.zip
mono MissionPlanner.exe

If the program starts and then fails in a way you cannot read from the UI, the README offers a debugging route: set MONO_LOG_LEVEL to debug before launching.

MONO_LOG_LEVEL=debug mono MissionPlanner.exe

Expect missing features on Linux. The README states plainly that not all functions are available there, and it does not enumerate which ones, so you find out by trying.

Offline operation, and where the caches live

Mission Planner is usable without a live internet connection, but only for the data you have already cached. The README lists four cache locations under C:\ProgramData\Mission Planner\: gmapcache for map tiles, srtm for elevation data, *.pdef.xml for parameter cache, and LogMessages*.xml for dataflash log metadata. On Linux the same data sits under /home/<user>/.local/share/Mission Planner/. All four are described as transferable between PCs, which is the practical way to prepare a field laptop: populate the caches on a machine with connectivity, then copy the directory.

For elevation, the README says SRTM cache, GeoTiff files in WGS84/EGM96, and DTED are supported. For imagery it lists map cache, WMS, WMTS and GDAL. That is a broader set of offline imagery sources than many ground stations expose, and it matters for survey work where you want your own orthomosaic behind the flight view rather than a tile service.

The caveat is that offline mode is partial. Parameter metadata and log metadata have network sources that cannot be disabled, so a fully air-gapped machine will rely entirely on the cached XML files and will not pick up newer metadata. The README does not document a supported procedure for refreshing those caches without internet access.

The cross-platform story is the real limitation

The README's own wording is the strongest signal here. Building Mission Planner on systems other than Windows is not supported. VSCode with the C# plugin can parse the code but cannot build it. The recommended development environment is Visual Studio 2022 on Windows, with an importable vs2022.vsconfig to get the right workloads.

That produces a split experience. Windows users get the maintained path. Ubuntu users get Mono, which the README says was tested on 20.04 and which leaves some functions unavailable. macOS users get an osxlatest development build that the README describes as experimental and not recommended for inexperienced users, and it explicitly recommends running the Windows version through Boot Camp or Parallels instead. The Android build is a Play Store application, which is a different product surface, not the desktop GCS on a phone.

If your team is standardized on Linux workstations, this is the wrong tool unless you accept Mono and the feature gaps that come with it. That is not a packaging oversight you can fix with a container; it is the shape of a WinForms .NET application. The README offers no supported alternative build path, and the repository has no Dockerfile or Linux packaging entry at the top level.

Mission Planner against QGroundControl

The obvious comparison is QGroundControl, which is the ground station most commonly discussed alongside Mission Planner. The difference in approach is architectural rather than cosmetic. Mission Planner is a C# .NET WinForms application that grew around ArduPilot's parameter and log formats, with a Windows-first distribution and Mono as the escape hatch. QGroundControl is a Qt application built for cross-platform deployment from the start, which is why it is the usual recommendation when someone needs a native Linux or macOS ground station.

What Mission Planner gives you in exchange is depth on ArduPilot specifics. The repository contains ParameterFactMetaData.xml, ArduCopterConfig.xml, LogAnalyzer, MagCalib, NoFly and Grid as first-class components. Those are ArduPilot-shaped tools. A cross-platform ground station has to abstract over multiple autopilot families, and that abstraction costs you the tightest integration with any single one.

The practical decision rule: if you fly ArduPilot and your operators use Windows, Mission Planner is the better fit. If your operators do not use Windows, or you need one ground station for mixed autopilot fleets, the cross-platform option avoids the Mono caveats entirely.

Licence, maintenance and what upgrading costs you

Mission Planner is GPL-3.0. The repository carries COPYING.txt at the top level and the README links to it. For end users running the binary this changes nothing. For anyone embedding Mission Planner code, linking against it, or shipping a modified build, the GPL-3.0 obligations apply to the combined work. That is a real constraint for commercial products that want to keep their own code closed, and it is worth raising with whoever handles licensing before you build on the source rather than after.

The repository is not archived, and the last push was on 2026-09-28, so the project is receiving commits. Releases are published on three channels: latest (Android development build), osxlatest (macOS development build), and betarelease (beta build). The README also points to ChangeLog.txt for the change history and to the ArduPilot firmware server for the stable MSI and zip.

Upgrade cost is mostly on the development side. If you only run the MSI, upgrading is reinstalling. If you build from source, the README's requirement is Visual Studio 2022 plus the vs2022.vsconfig components, and the repository uses git submodules, so a fresh clone needs git submodule update --init before the solution will build. The README does not document a rollback procedure for a bad upgrade, and it does not describe version pinning for the stable channel beyond the latest MSI link.

Editorial conclusion

Adopt Mission Planner if your fleet is ArduPilot, your ground station runs Windows, and you want parameter metadata, log analysis and offline map caches in one GPL-3.0 application. Do not adopt it if you need a first-class Linux or macOS build, since the README states that building on other systems is not supported and the native macOS and iOS support is described as experimental. Before committing, verify that the external services you cannot disable (firmware.ardupilot.org, raw.githubusercontent.com, api.github.com, autotest.ardupilot.org, Cloudflare) are reachable from your network, because the README lists no way to turn those off.

Frequently asked questions

Official sources

1. ArduPilot/MissionPlanner on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases