The AI-native ground control station: seven problems drone engineers face, and how UXDuck solves them

An AI-native ground control station (GCS) lets an AI agent work with a drone the way an engineer does. It can read live telemetry, parameters and vehicle messages with their units and sources, replay flights and start simulations, and every command or parameter change it asks for waits for the operator's approval before it reaches the vehicle. UXDuck is a ground control station for ArduPilot built this way: its MCP server, uxduck mcp, connects Claude Code, Claude Desktop, Codex and Cursor, and it runs on macOS, Windows, Linux, Raspberry Pi and in the browser, alongside Mission Planner or QGroundControl.

Mission Planner and QGroundControl are the reason so many ArduPilot and PX4 vehicles fly today. They are mature, free and maintained in the open. This post is not about replacing them. It is about the problems engineers keep reporting in public when they build, test and debug vehicles, and what changes when the ground station is designed for both the engineer and the engineer's coding agent.

Ben, UXDuck's founder, describes how the product is built: "I'm a product engineer. I've travelled to train drone operators and worked closely with pilots and hardware engineers. What they need in the field decides what UXDuck does next, and it ships several releases a week."

Ben adds: "I've seen drones crash because of a combination of human error and bad software. I've also seen software bugs spiral into cancelled test flights and weeks of delays. I've seen users suffer with proprietary and free software. I've also seen feedback get lost between flight testing teams and developers. This massively costs companies and hurts their growth and success. I can fix this by focusing on software for drones."

What is an AI-native ground control station?

A ground control station connects to the autopilot over MAVLink, shows what the vehicle is doing and sends it commands, missions and parameter changes. An AI-native one adds three things:

1. Vehicle context an agent can read. Telemetry with units and timestamps, parameters with descriptions from the firmware the vehicle actually runs, the vehicle's own messages, and its flight history.
2. Tools an agent can call. Starting a simulation, reading a window of telemetry, inspecting raw MAVLink, diagnosing a link, listing flights.
3. A safety model that keeps the operator in charge. Reading is open, and anything that changes the vehicle waits for a person to approve it.

In Ben's words: "An AI agent takes on the tedious work. You save your time for the critical decisions."

The seven problems below come from ArduPilot Discourse, PX4 Discuss, GitHub issues on Mission Planner and QGroundControl, and the tools engineers build for themselves. Each one links to its source and to the UXDuck guide that covers it.

Why is ArduPilot setup and configuration so hard?

ArduPilot's flexibility lives in its parameters, and there are a lot of them. Asked how many parameters Copter has, ArduPilot developer Amilcar Lucas answered "about 1200, but only 300 are required to be configured for proper operation" (ArduPilot Discourse). A thread on parameter naming opens with "the best thing about ArduPilot is there are a thousand+ parameters and the worst thing about ArduPilot is there are a thousand+ parameters" (ArduPilot Discourse). A Copter user asked for a simple mode for people "not interested in parameter tweaking for days" (ArduPilot Discourse). When the vehicle refuses to arm, the reason arrives as a short pre-arm message, one of the many listed on ArduPilot's pre-arm safety checks page.

How UXDuck handles it. The Parameters tab shows each value with its description from the matching Plane, Copter, Rover or Sub release, groups parameters by name (BATT_FS_LOW_ACT sits under BATT_, then BATT_FS_) and marks every value changed from its default. You stage related changes, give a reason and write them together, and UXDuck writes each change only if the vehicle still has the value you started from. Every change goes into the vehicle's History with who made it and why: you, the agent, another ground station or the vehicle itself. Saved parameter sets and imported .param files are compared with the vehicle before anything is written. The Messages tab keeps every PreArm: message in the order it came, and the Cockpit shows a readiness summary beside the arming state with the full checklist, warnings and fixes (Telemetry, Cockpit and Messages). Your agent can do the reading for you: "Why won't this vehicle arm? Read its latest pre-arm messages and relevant parameters; explain the evidence before proposing a change" is one of the example prompts in the MCP guide.

How do you test a change before the next flight?

Most fixes start in simulation, and ArduPilot's SITL is excellent once it runs. Getting it running is the hard part for many engineers, especially on Windows, where ArduPilot's own guide goes through WSL or Cygwin. One newcomer wrote "I tried to do full install two times and have no luck" (ArduPilot Discourse), and a thread about SITL under Cygwin on Windows 10 has been viewed 3,000 times (ArduPilot Discourse). The slower the loop between a change and a test, the more problems reach the flight line. From Ben's notes: "I saw irreproducible conditions and bugs, wrongly built features and issues closed without enough information, which got worse as we scaled deployment and split team into R&D and operations."

How UXDuck handles it. Open app.uxduck.com in Chrome, Firefox or Safari and choose Start flying: real ArduPilot runs in your browser, with nothing to install and no account. From the homepage's Try link, the simulated VTOL is climbing about 3 seconds after the page opens. You can simulate eight vehicle types: multicopter, plane, jet, VTOL, rover, boat, submarine and blimp. You can run several simulations side by side, pause one with Shift+P, or save a snapshot and start from it again (Try it in the browser). To test your own firmware, start it from New simulation › Advanced › Your own build. uxduck sim build path/to/your/ardupilot builds your checked-out commit for it on macOS or Linux, with a patch that keeps the simulator local to your computer, or you can point any ArduPilot SITL, PX4 SITL or MAVProxy at UXDuck's UDP port (Your own simulator). An agent can set up the test too: "Find Queenstown in New Zealand and start a simulated VTOL there" makes it look up the place and its terrain height, then ask your approval to start the simulation.

How do you analyse an ArduPilot log?

ArduPilot's log documentation lists several good tools, and engineers still end up writing their own. The author of ArduPilotTools wrote that UAV Log Viewer "is very useful for visually exploring a flight", but that "MAVLink messages/events aren't exposed alongside the plotted data, and once I had more than about three parameters on a plot it became increasingly difficult to correlate what was happening" (ArduPilot Discourse). The author of ardupilot-mcp started his project after he'd "spent too many evenings scrolling through .bin logs by hand trying to work out why something fell out of the sky" (ArduPilot Discourse). On PX4 Discuss, a user who posted both a flight log and a screen recording still couldn't tell whether a strange arming state came from QGroundControl or the firmware, until a maintainer explained that the firmware decides (PX4 Discuss).

How UXDuck handles it. Replay plays a flight back on both maps and in every tab, as it was, with the camera's recordings in step. Open a .tlog or a DataFlash .bin log, drop one on the window, copy logs from the vehicle's SD card, or run uxduck replay flight.tlog --play --speed 5. Telemetry logs from Mission Planner, QGroundControl and MAVProxy all open, and UXDuck Desktop lists the flights in Mission Planner's and QGroundControl's log folders without copying them. The bar marks arming, time in the air, mode changes, warnings, settings changed and where there is video. The Parameters tab shows the values as they were at the replay's time, with each change in the log and who made it, and an agent reads the same values and calls param_changes to list what changed. An operation's flights replay together on one clock.

Is there a modern ground control station for Mac, Linux and the browser?

Mission Planner's own overview says it "is compatible with Windows only" (Mission Planner docs), and a January 2026 issue reports it crashing at startup on macOS Tahoe (MissionPlanner #3658). QGroundControl runs everywhere, and large desktop apps still have bad days: on a v5.0 build, after a USB cable was pulled, clicking Disconnect closed the window but left QGroundControl running in the background until it was ended in Task Manager. Its maintainers traced the cause within a day (QGroundControl #12858). These are ordinary bugs, reported and handled in the open. They still cost time at the field, where the laptop you have is the laptop you fly with.

How UXDuck handles it. UXDuck runs on macOS, Windows, Linux, Raspberry Pi and in the browser (Install, Compatibility). On Linux it can run with no window, which suits a Pi beside a radio. It connects over USB, telemetry radio, UDP and TCP, finds flight controllers and simulators on its own, and its links reconnect by themselves when a cable or radio drops (Connect a vehicle). Every command shows a receipt that says whether UXDuck refused it, the vehicle rejected it or the vehicle acknowledged it. Arming, disarming and rebooting are pressed and held, so a stray click does nothing (Confirmations). If you know Mission Planner's flight display, Instruments (classic) draws the vehicle's instruments the way Mission Planner does.

Why does every drone team end up building its own tooling?

When a team needs its own panels, messages or workflows, the usual route is a custom QGroundControl build. QGroundControl's own guide says "it is important to keep your custom master up to date with QGC master. If you lag behind you may be surprised by upstream features which require some effort to integrate with your build" (QGC dev guide). Qt Group, whose framework QGroundControl is built on, puts the cost of a fork plainly: "Every subsequent release becomes a merge effort, upgrades are deferred, and security fixes are backported by hand" (Qt). Others write scripts and analysis tools from scratch, like the two log projects above. From Ben's notes on talking to drone teams: "People are stuck with Mission Planner, QGC or a half baked internal solution because they focus more on the use case and user facing software, not the software infrastructure."

How UXDuck handles it. UXDuck reads your fork as it is. Add your fork's MAVLink XML with the commits that have it, and every vehicle running those builds decodes your messages; generate parameter descriptions from the checkout that built your firmware, or add the URL your CI publishes them at (Parameters). The command line and RPC script everything from a terminal or CI. uxduck forward turns a Raspberry Pi into a headless MAVLink bridge, and with --onboard it also reports the Pi's CPU temperature, memory and storage over MAVLink. MCP lets your coding agent build on UXDuck instead of on a fork. UXDuck Core is open source under Apache 2.0 (GitHub).

Can Claude or Codex work with an ArduPilot vehicle?

Engineers clearly want this. GitHub has at least six independent MCP servers for MAVLink and ArduPilot, such as mavlink-mcp, ardupilot-mcp, droneserver, uav_mcp, MAVLinkMCP and ardupilot-mcp-server. A 2025 Google Summer of Code project built an AI chat tool for ArduPilot that turns text or voice commands into MAVLink through Mission Planner. ArduPilot itself now has an AGENTS.md for AI-assisted contributions, which starts from the fact that it is "safety-critical autopilot software controlling real vehicles". The hard part is not connecting a model to MAVLink. It is giving the agent context it can trust, such as the right parameter descriptions for this firmware, units and the age of each value, and a safety layer that holds back anything that changes the vehicle. The ardupilot-mcp author designed his tool specifically "to NOT let an LLM hallucinate numbers". Each of these projects builds the connection and safety layer again on its own.

How UXDuck handles it. Install UXDuck, keep it running, and add it to your agent (Use with AI agents):

claude mcp add uxduck -- uxduck mcp
codex mcp add uxduck -- uxduck mcp

Claude Desktop and Cursor take the same command in their MCP config. uxduck mcp offers two tools when the agent connects, one to find vehicle tools and one to call them, so the agent loads only the schemas it needs; uxduck mcp --all-tools lists every tool for clients that want per-tool rules. The agent gets the same view of the vehicle that you have:

• vehicle_list, telemetry_get, vehicle_messages and vehicle_history for what the vehicle is doing now and what changed.
• param_get, with describedBy saying which firmware's description explains the value.
• telemetry_window for up to five minutes of selected signals, with coverage and missing keys, to compare a voltage dip or a GPS change with the vehicle's messages.
• mavlink_inspect and mavlink_history for raw message rates and retained packets, and link_diagnose, router_events, socket_inspect and daemon_logs for forwarding and connection problems.
• flight_list, sim_start, place_search and terrain_at for the logbook and for setting up simulations.

Reading vehicles, telemetry, parameters and history needs no approval. Commands and changes wait for your approval in UXDuck, with Allow once, Allow for this connection, Always allow and Deny, and an unanswered request is denied after 60 seconds. You can answer from a terminal with uxduck approvals. The agent runs on your own Claude or Codex account, and UXDuck keeps the vehicle connections on your computer.

How do you work with several vehicles from one ground station?

Multi-vehicle work is where today's tools show their age. Mission Planner's swarming interface is, in its own documentation's words, "an experimental beta implementation, which is admittedly neither easy to use nor 100% reliable" (Mission Planner docs). A QGroundControl contributor proposed an overhaul of its multi-vehicle panel because its widgets "are prone to breaking" and its actions "execute without confirmation, which can lead to accidental commands" (QGroundControl #11693). On PX4 Discuss, a user reported that with more than three vehicles on one QGroundControl, some kept flipping between Ready and Not Ready with repeated connection lost and regained messages (PX4 Discuss).

How UXDuck handles it. Every vehicle UXDuck hears, real or simulated, has its own colour on the map, in the sidebar and on its mission. A TCP listener link takes each incoming connection as its own vehicle; each link can be switched off or edited on its own on Fleet, and any of them can be forwarded to another program (Connect a vehicle). Press-and-hold confirmations apply to every vehicle. On a shared laptop, each operator keeps their own settings, and every flight, parameter change and command records who did it (Shared computers). Afterwards, an operation's flights replay together on one clock (Replay). Your agent sees the whole fleet through vehicle_list.

Does UXDuck replace Mission Planner or QGroundControl?

It doesn't have to. UXDuck works alongside your current GCS. A Forward to a program link sends the same MAVLink to Mission Planner on 127.0.0.1:14550, or to QGroundControl, while UXDuck stays connected (Connect a vehicle). UXDuck opens their telemetry logs, lists the flights in their log folders, and exports parameters in Mission Planner's .param format. Keep the tools your team trusts for the jobs they do well, and use UXDuck for simulation, replay and agent work. The comparison page sets the three side by side.

Seven problems and where UXDuck covers them

Try it

1. Open app.uxduck.com and choose Start flying. A simulated VTOL takes off in your browser.
2. To connect a real vehicle or your agent, download UXDuck for macOS, Windows, Linux or Raspberry Pi.
3. Add it to Claude Code with claude mcp add uxduck -- uxduck mcp, or to Codex with codex mcp add uxduck -- uxduck mcp.
4. Ask: "List the vehicles UXDuck can hear, and show the running version and link status."

Frequently asked questions

What is an AI-native ground control station?

It is a ground control station designed so that an AI agent can read the vehicle's telemetry, parameters, messages and history, and call tools such as simulations and diagnostics, while every command and parameter change it asks for waits for the operator's approval. UXDuck does this for ArduPilot through its MCP server, uxduck mcp.

Does UXDuck replace Mission Planner or QGroundControl?

No. UXDuck works alongside them. It forwards MAVLink to Mission Planner or QGroundControl, opens their telemetry logs and exports parameters in Mission Planner's format, so you can use both at once.

Which AI agents work with UXDuck?

Claude Code, Claude Desktop, Codex and Cursor connect through MCP with uxduck mcp. Any other MCP client that runs a server over standard input and output can use the same command.

Can an AI agent arm or fly my drone without my approval?

Not unless you allow it. Reading telemetry, parameters and history needs no approval. Commands and parameter changes wait for your approval in UXDuck, where you choose Allow once, Allow for this connection, Always allow or Deny, and an unanswered request is denied after 60 seconds. Settings › Agents and tools sets each tool's permissions.

Does UXDuck work with PX4?

UXDuck supports ArduPilot today, and PX4 support is planned. A PX4 SITL can already send its MAVLink to UXDuck through mavlink-router, but PX4 parameter descriptions are not supported yet.

Which vehicles can I simulate?

Eight types: multicopter, plane, jet, VTOL, rover, boat, submarine and blimp. They run real ArduPilot in Chrome, Firefox or Safari with nothing to install, and you can run several at once.

Can UXDuck replay Mission Planner and QGroundControl logs?

Yes. UXDuck replays telemetry logs (.tlog) from Mission Planner, QGroundControl and MAVProxy, and DataFlash logs (.bin) from the vehicle or its SD card, on both maps and in every tab, with the flight's video when there is one.

How much does UXDuck cost?

UXDuck is free for personal, non-commercial use and non-commercial academic use. For business or government use, contact us for pricing.