Mission Analyzer: Why Python, Not C++

[Mission-analyzer]

Two Different Worlds: The Aircraft and the Ground

ArduPilot as an ecosystem consists of two fundamentally different parts. The firmware — the code that actually runs on board, on the flight controller itself (Pixhawk and similar) — is written in C++. Mission Planner, the ground control station with its map, HUD, and parameter settings, is written in C# and .NET (Windows Forms). These are two separate projects from the same team, in different languages, because they solve fundamentally different problems.

The autopilot firmware has to:

• run in real time, with hard, predictable latency (milliseconds matter here — not as a figure of speech, but literally as a matter of flight stability);
• fit within a microcontroller's limited memory;
• run without a general-purpose operating system, or with a minimal RTOS at most;
• be as predictable as possible in its resource consumption.

For that kind of task, C++ isn't just a reasonable choice — it's practically the only realistic one: direct control over memory, no garbage collector that could introduce an unpredictable pause at the worst possible moment, compilation straight to native code for a specific microcontroller.

A ground station or mission-analysis tool — which is exactly what both Mission Planner and our own Mission Analyzer are — is a fundamentally different job:

• it runs on an ordinary desktop computer with an ordinary OS;
• it has none of the real-time requirements the aircraft has — a half-second delay while recalculating a route is annoying, it doesn't bring the plane down;
• what matters most is development and iteration speed, not microseconds of execution time.

That's exactly why the ArduPilot team itself chose C#, not C++, for the ground station — a language with managed memory, a rich GUI library out of the box, and a considerably faster development cycle than C++.

Why Python, Then, and Not C# — Mission Analyzer's Choice

If C# was already the established answer for this class of task — Mission Planner itself is proof of that — why did Mission Analyzer end up on Python instead? A few concrete reasons, specific to how this particular project was actually built:

Iteration speed, taken even further. The whole development path of Mission Analyzer has been dozens of consecutive sessions of continuous changes — reworking the altitude optimization algorithm, the obstacle-avoidance geometry, adding new tabs (simulation, joystick support). Python needs no compilation step at all: change the code, restart, see the result. Mission Analyzer grew through a steady stream of small iterations and experiments rather than one big, carefully planned release — and here Python is noticeably faster than even C#'s compile cycle.

A rich ecosystem for exactly this class of task, without unnecessary weight. Working with geometry, mission files, maps, and HTTP requests to tile servers — all of this is compact, readable code in Mission Analyzer, using Python's standard library or a couple of small packages. There's no need to drag in a heavy GUI framework — Tkinter ships with the language itself.

A lower barrier to entry and better readability. Mission Analyzer's Python code, written for one specific task rather than as a general-purpose library, tends to be shorter and clearer than the equivalent C#/C++ — less boilerplate, less explicit typing where it doesn't actually add value.

The final deliverable is still a self-contained .exe either way. PyInstaller solves the same problem for Mission Analyzer that publishing a .NET application solves for Mission Planner — it turns interpreted code into a portable executable that can be distributed and run on a machine without Python installed, exactly the way a .NET application can be distributed without a separate runtime installation.

Being Honest About the Cost of This Choice

Python's advantages aren't free. An interpreted, dynamically typed language has a real cost, and Mission Analyzer has felt it too:

• on genuinely heavy, compute-intensive work, Python is objectively slower than compiled code — for instance, image operations (compositing and rotating map tiles for the simulation tab) had to be moved onto a background thread specifically so they wouldn't freeze the interface;
• the lack of static typing means some errors a C#/C++ compiler would catch at build time here only surface at runtime — which is exactly why so much of Mission Analyzer's bug-finding happened after the code was written, through testing, rather than before.

This is a deliberate trade-off: for a tool of this scope and pace of development, the gain in iteration speed outweighs the loss in raw execution performance.

Bottom Line

Mission Analyzer solves a fundamentally different class of problem than onboard firmware, and it deserves a different language. C++ belongs where C++ is genuinely needed: on board, in real time, under tight resource constraints. Python belongs where development and iteration speed matter more than microseconds of execution — and that's exactly Mission Analyzer's case.

Libraries Mission Analyzer Already Uses

Library	What it's for
Tkinter	The GUI framework behind Mission Analyzer's entire interface — ships with Python's standard library, no separate install needed
Pillow (PIL)	Decoding map tile images, compositing several tiles into one image, and rotating it to match the aircraft's heading (simulating a camera fixed to the airframe, in the simulation tab) — an optional dependency; without it, Mission Analyzer falls back to a simpler display mode on its own
pymavlink	The MAVLink protocol for Mission Analyzer's real connection to an autopilot (Cube+ and similar) — telemetry, mission upload/download, file transfer over MAVLink FTP
pyserial	Low-level USB-serial port handling, which pymavlink uses to physically talk to the flight controller
pygame-ce	Reading a USB joystick/transmitter (RadioMaster Boxer) in Mission Analyzer's simulation mode — axis calibration, manual control in MANUAL/FBWA