PROTOCOLS

One ground station, every flight controller

Mission Control speaks MAVLink and MSP natively, with support for ArduPilot, PX4, Betaflight, and iNav. A protocol-agnostic architecture means adding a firmware is one adapter, not a rewrite.
Launch Mission ControlSee configuration
4
Flight stacks
2
Protocols: MAVLink v2, MSP v1/v2
5,000+
Parameters per ArduPilot vehicle
78
Config panels

Firmware

Four flight stacks, two protocols

ArduPilot and PX4 over MAVLink v2. Betaflight and iNav over MSP. All from one ground station.

ArduPilotMAVLink v2
PX4MAVLink v2
BetaflightMSP v1/v2
iNavMSP v1/v2

Parity

What each firmware supports

The ground station gates features by what the connected firmware can do. All four get live parameter editing with offline metadata, flight modes and arming, calibration, and a configuration panel set. Here is where they differ.

  • ArduPilot

    Protocol (MAVLink v2), Missions, Geofence, Return points (Rally points), On-screen display, Flashing

    No blackbox

  • PX4

    Protocol (MAVLink v2), Missions, Geofence, Flashing

    No return points or on-screen display or blackbox

  • Betaflight

    Protocol (MSP v1/v2), On-screen display, Blackbox, Flashing

    No missions or geofence or return points

  • iNav

    Protocol (MSP v1/v2), Missions, Geofence (Geozones), Return points (Safehomes), On-screen display, Blackbox, Flashing (Custom file)

Parameter registry

Complete metadata, offline

Every parameter carries its enum values, bitmask flags, ranges, units, and defaults, bundled so the editors work with no network.

A first-party parameter registry ships metadata for all four firmwares, so a bitmask field renders as labeled checkboxes and an enum renders as a named dropdown instead of a raw number. Undocumented bits are preserved on write, so an editor never silently zeroes a value it does not recognize. The registry loads from a bundled floor first, then overlays a version-matched copy and, on PX4, the metadata the flight controller serves itself.

command.altnautica.com
The Mission Control parameter editor with named enum and bitmask fieldsThe Mission Control parameter editor with named enum and bitmask fields

Architecture

One adapter per firmware

Every protocol adapter implements one unified interface, so the UI queries capabilities instead of hard-coding a firmware.

Panels to firmware
Mission Control panelsread a capability type
show or hide per firmware
Adapter contractone interface
params, missions, modesarm, disarm, RC override
MAVLink v2 adapterArduPilot, PX4
MSP adapterBetaflight, iNav
Connection, heartbeat, identification, parameters, missions, RC override, mode switching, and arm and disarm all sit behind one adapter contract. Adding a protocol means writing one adapter, not rewriting the app.

Configure

A panel for every subsystem

A representative selection across the four firmwares. The panels you see depend on what the connected firmware supports.

Outputs
Receiver
Flight Modes
Aux Modes
Motors & ESC
Frame
VTOL
Failsafe
Geofence
Safehome
Calibration
Sensors
Power
GPS
EKF3
Gimbal
Camera
Airspeed
Harmonic Notch
ADS-B & Avoidance
PID Tuning
Rate Profiles
OSD Editor
LED Strip
VTX
Ports
Stream Rates
Radio Config
MAVLink Signing
Blackbox
Scripts
CLI

Related

Explore the stack

Flight ComputerAI compute, flight control, video, and 4G LTE on one boardLearn moreExtension SystemThe extension platform: signed agent plugins and sandboxed GCS panelsLearn more

Connect your flight controller

Plug in over USB or connect over the air, and configure any of the four firmwares in your browser.

Launch Mission Control
Get Early Access