FPV Drone Fleet Manager

active

2026-06 · drones · fpv · betaflight · ardupilot · typescript · mcp

Plug in a drone, identify it, diff its config against fleet spec, and fix the drift.

Dark dashboard showing an identity card with an "AP" firmware badge, a green READY readiness verdict, health and video-transmitter panels, and a co-pilot chat pane. — Bench view, night mode — mock ArduPilot flight controller connected

Light dashboard with identity, readiness, health, video-transmitter, and co-pilot panels for a recognized ArduPilot drone. — The same bench session in day mode — hue for status where night mode uses glyphs

Dark table of demo airframes marked READY, ATTN, or DOWN, badged BF or AP, beside a radio/video-channel assignment table. — Fleet overview — airframes grouped by build configuration, with firmware badges and a channel map

Dark checklist showing DRIFT rows for firmware target, arming flags, video-transmitter band/channel/power/pit frequency, and craft name, plus a passing GPS row. — A "bring to spec" run — one pass, six drifts, each with expected vs. actual values

20-second tour — identity resolve, day/night flip, fleet overview, status check

What it is

Keeping a fleet of first-person-view (FPV) quadcopters consistently configured is slow and error-prone: each drone gets plugged into a configurator and checked field by field, by hand, with no record of what changed. This is a workbench app that turns that into one fast loop — plug the drone in over USB (Universal Serial Bus), auto-identify the flight controller, see readiness at a glance, diff settings against the fleet spec, and apply fixes with confirmation. It speaks both Betaflight and ArduPilot firmware through the same interface.

Why it exists

Servicing a shared fleet before an event meant hours in a configurator, one drone at a time, and no answer to “who changed this and when.” The goal is plug → check → fix → unplug → next, in seconds per drone, with every change logged.

What it does today

Identifies a plugged-in flight controller by protocol probe — MultiWii Serial Protocol (MSP) for Betaflight first, then a MAVLink v2 heartbeat for ArduPilot — and keys all history on the microcontroller’s hardware unique identifier (UID). Airframes and flight controllers are separate entities, so board swaps and harvested boards resolve instead of corrupting history.
Reads identity, arming readiness, battery, radio-control (RC) link, and video transmitter (VTX) settings live. Every VTX write is verified by reading the value back; nothing is blind-written.
A “bring to spec” checker diffs a drone against a per-firmware fleet baseline and reports pass/drift per item — VTX band and channel, power level, pit-mode frequency, craft name — with expected vs. actual values.
Every hardware action is one of 32 Model Context Protocol (MCP) tools exposed by a local agent. The dashboard buttons and the built-in artificial- intelligence co-pilot call the same tools; writes require explicit confirmation, and the co-pilot’s API key never reaches the browser.
Configuration history is an append-only change log in Postgres; current state is a projection over it.
The whole app runs against mock flight controllers with no hardware attached: 706 tests, 250 UI unit tests, and 16 Playwright end-to-end tests across mobile and desktop viewports.

Under the hood

TypeScript monorepo: a React + Vite dashboard, a local Node agent that is the only process allowed to touch serial hardware (exposing the MCP tools over a WebSocket), and a Postgres server holding canonical fleet state. A driver seam lets the Betaflight/MSP and ArduPilot/MAVLink implementations pass one shared behavioral contract suite, so both firmwares get the same user experience.

State & direction