Every experienced drone operator runs a pre-flight checklist. Some do it in their head, some on a clipboard, some in the drone's own app. Overwatch now does it in the ground station, above the Launch button, updating in real time from live telemetry, with Overwatch AI reading the results and giving a go / caution / hold recommendation in plain English.

The problem with clipboard checklists

Paper checklists work fine in theory. Operators who never skip a step, who always measure, who always wait for the reading to settle, and who never fly when they're tired or rushed. In practice, pre-flight is the most-skipped phase of drone operations. The checklist takes five minutes. The mission is already late. The weather is turning. The operator flips one switch instead of three.

The usual response is to enforce the checklist with a safety officer. That works when a safety officer is present. For operators working solo — a coastguard UAS operator on a boat, a fire chief at an incident, a police UAS pilot dispatched alone — enforcement has to come from the system.

The pre-flight health panel is that enforcement. It's always visible while a mission is scoped. It's populated in real time from MAVLink telemetry. It blocks the Launch button when something is red. The operator doesn't need to remember the checklist; the panel shows it automatically and doesn't let them skip it.

The eight checks

Per drone, the panel shows:

  1. Battery — live percentage from SYS_STATUS. Green above 70%, yellow 25–70% (with "not fresh" labelling), red below 25% ("swap before launch").
  2. Cell balance — per-cell voltage spread from BATTERY_STATUS. Green below 0.08 V delta, yellow 0.08–0.15 V, red above 0.15 V ("swap battery"). This catches dying cells that pack voltage doesn't reveal.
  3. GPS fix — fix type + satellite count from GPS_RAW_INT. Green on 3D fix with ≥10 sats, yellow on 3D fix with <10 sats, red on 2D or no fix.
  4. Compass — health bit from the SYS_STATUS sensors-health bitfield. Green if healthy, red if recalibration is needed.
  5. Failsafes — verification that the PX4 failsafe parameters (NAV_DLL_ACT, NAV_RCL_ACT, COM_BAT_ACT, GF_ACTION) are set correctly. Currently a manual tick pending full PARAM_REQUEST_LIST parsing; the operator confirms from the paper checklist.
  6. Geofence — GF_MAX_HOR_DIST and GF_MAX_VER_DIST set. Same manual-tick pattern while the full param parse is being wired.
  7. Telemetry heartbeat — age of last HEARTBEAT from this drone. Green if <2 seconds, yellow 2–5 seconds, red if stale beyond 5 seconds.
  8. Remote ID — Operator ID configured in Settings. Red (regulatory blocker) until configured; green once set. This is the A5 regulatory compliance check wired into the pre-flight surface.

The aggregated summary at the top reads "Fleet ready 3/3 ✓" when all drones are green, "Fleet ready 2/3 — drone-2 needs attention" when one drone has issues, and so on. A click on a drone row expands per-check detail — individual cell voltages, satellite IDs, compass offset values — for operators who want to dig in.

The AI recommendation

Reading eight checks across up to twenty drones is a lot for an operator glancing at the screen before launch. Overwatch AI (formerly Fleet Advisor — see the rename post) reads all of it, plus the live wind speed and 1-hour forecast gust, and produces a one-sentence recommendation:

  • Green: "Green light — all checks passing."
  • Yellow: "Proceed with caution — Wind 7.2 m/s, conservative mission envelope."
  • Red: "Hold launch — drone-2: Battery 22% — swap before launch; Forecast gust 11.3 m/s within 1h — abort risk."

The recommendation comes from the same pipeline that produces Orchestrate's runtime Fleet Advisor decisions — local physics engine first, optional cloud refinement (Anthropic / OpenAI / Gemini failover), always validated by the Safety Gate before it reaches the UI. The source badge shows LOCAL, CLAUDE, GPT, or GEMINI so the operator always knows which engine made the call.

Launch gating and the override

The Launch button (Core) and Deploy Mission button (Orchestrate) are disabled while the aggregated status is red. This isn't a warning the operator can scroll past; the click target itself is inactive.

Operators can override — there are real situations where a mission has to fly despite a yellow or red check (a SAR operation where a life is at stake, a missing-person search where the failed compass recalibration is survivable for the mission profile). The override is deliberately more friction than a click: an input field appears, the operator types OVERRIDE (case-sensitive), the button unblocks. The failing check names, operator ID, timestamp, and override flag are written to the audit log.

That matters for the after-action review. If the mission goes well, the override is a recorded operational decision. If the mission doesn't, the investigation has a timestamped record of which checks were red, which were overridden, and by whom.

Demo, SITL, and real hardware

The panel works identically across three environments:

  • Demo mode — drone values come from the simulator. Useful for training, demos to prospects, and operator drill.
  • SITL — PX4 Software-In-The-Loop simulation feeds real MAVLink telemetry to the panel. Useful for development and verifying configuration before real-hardware flight.
  • Real hardware — X500 V2 drones on the WiFi hotspot, ESP32 telemetry modules streaming to the ground station. Panel reads from live MAVLink.

On AirSDK (ANAFI) the panel is degraded to a manual-tick checklist — AirSDK doesn't expose live telemetry to the ground station, so the operator confirms each check from the drone's own app or from visual inspection. Same discipline, degraded signal source.

Why we built it this way

The failure mode we're defending against is a rushed operator launching a drone that shouldn't have been launched. The panel doesn't prevent that with a dialog ("are you sure?"), it prevents it by making the bad state visible before they reach for the button and by making the button itself inactive when the state is bad. The AI recommendation isn't for the experienced operator who knows what the numbers mean; it's for the stressed operator who needs one sentence that tells them what to do.

Pre-flight is also the right place for an operator's first AI interaction on Core. The drone is on the ground. The stakes of the recommendation being wrong are low (a delayed launch, not a crashed drone). Operators build trust with Overwatch AI's judgement on these low-stakes decisions before it's ever asked to do something consequential in the air.

What's next

The manual-tick checks for PX4 failsafe params and geofence configuration will move to automated parsing once the full PARAM_REQUEST_LIST support lands in the MAVLink bridge. Compass health bit interpretation is the same — SYS_STATUS sensors-health bitfield parsing is a short follow-on.

Further out, the pre-flight panel is the template for an in-flight health panel (the same 8 checks, same AI recommendation, live while the drone is flying) and a post-flight debrief (the AI reads the mission log and produces an after-action summary). Both are on the backlog for phases beyond the current Ground Station launch.