Why We Built SAR

SAR is a complete ground station, purpose-built for search-and-rescue and 24/7 multi-drone patrol. Not a plugin on top of someone else's mission planner. Not a sidecar to a general-purpose flight app. The whole stack — mission planning, fleet relay, onboard detection, exception alerting, safety supervision — designed around one mission profile, then scaled from a single-drone search up to a 100-drone patrol. We built it that way because the customers we wanted to serve couldn't run the missions on what already existed. Here's the gap we saw and the answer we landed on.

What we tried first

The right way to start a software project is to find out who already solved the problem. We looked.

QGroundControl is the open-source default for PX4 and ArduPilot. It's the thing every drone hobbyist, every PX4 development team, and most industrial-drone evaluators use first. Mission Planner is the ArduPilot equivalent. Both are excellent ground-station-and-mission-planner tools for general-purpose UAV missions: waypoint navigation, parameter tuning, log review, telemetry display.

Auterion Mission Control is the commercial answer that ships with the Astro Max airframe. It's polished, it's enterprise, it's well-supported. It's built around the broad set of industrial use cases Auterion's customers care about — inspection, mapping, public-safety photography, search-and-rescue as one item on a list of many.

DJI's apps are the most polished in the industry. They're built around DJI's locked stack and what DJI's product strategy wants the customer to do, which works very well if your mission profile fits DJI's roadmap and not at all if it doesn't.

All of these are good at what they're built for. None of them are built for SAR.

What SAR specifically demands

Run a coastguard search for a vessel-overdue alert. Run a fire-brigade ground search for a missing person at 03:00. Run 24/7 perimeter patrol on a coastal AOI for an island authority. The set of capabilities the operator actually needs is specific:

• Boustrophedon search-pattern generation from an operator-drawn polygon. Draw an AOI on a map, get a grid search pattern out, fly it. For larger AOIs, automatic partitioning into sectors so a multi-drone fleet covers in parallel. General-purpose mission planners ask the operator to drop waypoints; SAR wants the planner to generate them.
• Multi-drone fleet relay with battery-aware handoff. A real SAR mission may need to run for hours; a single industrial drone has 18–90 minutes of endurance. Continuous coverage requires a fleet rotating through battery cycles. The handoff has to be seamless and safe — same waypoint resume, no gap in coverage, no airspace conflict between the inbound and outbound drone. How that works in detail is its own engineering problem.
• Exception-only alerting. A control-room operator on a 12-hour shift cannot watch every telemetry stream from every drone every second. The ground station has to surface only what the operator needs to act on — battery anomalies, GPS dropouts, weather thresholds, detections, handoff conflicts. Everything else stays quiet.
• Onboard human and vessel detection with operator notifications. Live video downlink from a drone is not a SAR detection system; it's a video stream. Detection requires onboard inference on a companion computer (the bandwidth to stream HD video from every drone in a fleet to a ground station does not exist on the long-range datalinks SAR uses), and the ground station has to be the detection-and-alerting layer that turns inferences into operator notifications, with full evidence trails for evidential review.
• Weather-aware safety gate. Wind thresholds that trigger automatic abort and return-to-launch. Weather-driven re-planning of patrol parameters mid-flight. Hard stops at conditions where any drone in the fleet shouldn't be flying.
• GPS-denied resilience. SAR happens in canopy, in urban canyons, in environments with deliberate or accidental GPS denial. The autonomy stack has to keep flying when satellites stop working.
• Mid-flight re-planning. The search expands. The target moves. New evidence narrows the AOI. The mission cannot be a fixed waypoint list uploaded once and flown blind; it has to be re-uploadable mid-flight without restart, with the fleet adopting the new plan in flight.
• Air-gapped operation. Several of our target customers operate in jurisdictions or contexts where the ground station cannot phone home, and where cloud AI is a non-starter. The whole stack has to work offline.

This is not a list a general-purpose ground station can satisfy with a plugin. It's the shape of the application.

Why we built a complete stack, not a plugin

We considered plugins. We looked at building autonomy as a layer on top of QGroundControl and on top of Auterion's host application. Two things make the plugin path the wrong path for SAR.

The first is interaction model. Drawing an AOI and getting a fleet-distributed grid search out is not a "mission" in the general-purpose-ground-station sense — it's a different primary metaphor. The cursor wants to draw a polygon, not drop waypoints. The fleet view wants to show drones-by-sector, not drones-by-system-ID. The alert overlay wants to show events the operator should respond to, not telemetry the operator should monitor. Trying to bend a host application's UI to those metaphors fights the host more than it cooperates with it. Every plugin we sketched needed the host to behave in ways the host wasn't designed for, and every workaround had a "well, you click here first, then" caveat that broke the 30-second test (more on that below).

The second is safety architecture. SAR's three layers of safety — ground-station kill button, autopilot-onboard failsafes, RC-transmitter kill switch — cross-cut every flight. The host application's safety model usually centres on the autopilot's failsafes alone. Bolting a second and third layer on top of someone else's safety model is fragile; the operator's muscle memory has to live somewhere coherent, and the layer that can yank a fleet of drones out of the sky on a single click can't be a plugin to an application that wasn't designed to support it.

So we built the whole ground station. Mission planner, fleet view, alerts, telemetry, video, detection, safety gate, mid-flight commands, MAVLink bridge, simulator. One application, one mental model, one safety architecture. The technical case for that decision is in Why Software Is the Hard Part of SAR Autonomy; the customer-experience case is the 30-second test.

The 30-second test

There is one user-experience metric that catches all of this: how fast can a SAR operator go from "we have a callout" to "drones are searching"?

If the answer is more than a minute, you've lost. Real callouts come in noisy, chaotic moments — radio chatter, partial briefs, family members on the phone with the duty officer, dispatchers triaging concurrent incidents. The operator who has to remember nine button-clicks and a parameter-tuning sequence will not, under stress, remember nine button-clicks and a parameter-tuning sequence. They will fall back on what they already knew, which is calling for the helicopter or sending the volunteer team in by foot.

So the test is: open the app, draw the polygon, hit go. Under one minute. Every UI decision in SAR is filtered through that test. Every parameter that can be auto-defaulted is auto-defaulted — sector count, altitude, scan resolution, swap thresholds, fleet sufficiency. Every advanced control lives behind a disclosure for the operators who do want to tune it. Every alert is exception-only.

The corollary is that a great ground station for SAR looks pared-down compared to a great ground station for general missions. Auterion Mission Control has more buttons. SAR has fewer. That's not because SAR is less capable; it's because the capabilities a SAR operator needs sit on a different surface than the capabilities a general-purpose pilot needs, and the difference between the two is the difference between getting drones airborne in 45 seconds and getting them airborne in five minutes. In SAR, that difference is the mission.

What stays the same across airframes

Everything above — the boustrophedon planner, the fleet relay, the exception alerts, the detection pipeline, the safety architecture, the 30-second compose — runs identically on every airframe SAR supports. Our turnkey Drone One bundle. Freefly Astro Max for NDAA / Blue UAS customers. Quantum Systems Trinity Pro for EU-sovereign procurement and long-endurance VTOL coverage. Our internal Holybro X500 V2 workshop fleet. Any other PX4 / ArduPilot MAVLink-compatible industrial drone we add to the supported list.

This portability is deliberate. We built SAR on open MAVLink not because MAVLink is fashionable but because it's the protocol that survives airframe-replacement cycles. Drone One v1, Drone One v2 (the future EU-sovereign chassis variant), Astro Max for NDAA customers, Trinity Pro for VTOL endurance, future MAVLink airframes that don't exist yet — same SAR ground station, same operator workflow, same training, same evidence trail. The customer's investment in the autonomy layer is the part that compounds; the airframe is the part that gets replaced.

That portability is also why "is this a SAR feature, or is this an airframe feature?" is a useful filter when designing the product. The airframe choice belongs to the customer's procurement (NDAA constraints, EU sovereignty, endurance class, payload requirements, budget). The autonomy layer above it should be the same regardless. SAR is the autonomy layer.

Why software-first was the right call

We started software-first because the gap was software. The drones existed; the autonomy layer didn't. Building hardware to run software that didn't yet exist would have been the wrong order — both as engineering discipline and as customer-development discipline.

That sequence held for the development of the autonomy stack on the workshop X500 fleet. The stack matured against real airframes, with real failure modes, in real wind. Multi-drone relay handoffs got tested on hardware that crashed cheaply; GPS-denied transitions got tested in environments where simulator results would have been suspect; safety supervision got drilled until the muscle memory was correct. By the time we were ready to talk to customers seriously, the software had hours of real flight time on it, not just simulator runs.

The hardware story came later, and it came when the software was ready to ship and the customer segment we wanted to serve couldn't afford the airframes we'd been recommending. That's Why We Built Drone One — Part 3.

What we ship today

SAR is a production ground station running on:

• Our turnkey Drone One bundle — the airframe we sell, from €11,000 per drone with thermal included, integration and training included
• Any MAVLink-compatible industrial drone via the software-licence tier from €3,000 per drone per year
• Example compatible airframes: Freefly Astro Max (NDAA / Blue UAS), Quantum Systems Trinity Pro (EU sovereignty), and any other PX4 / ArduPilot industrial drone we add to the supported list

The autonomy stack is identical regardless of airframe. Mission planning, fleet relay, detection, alerting, safety supervision — same software, same operator workflow, same training. The airframe is the customer's choice; the SAR layer is what makes the airframe actually run a search.

Next

If you want to feel the 30-second test for yourself, run the demo. It runs the full SAR Ground Station against a simulated Curacao coastal patrol — same software an operator would use to compose a real mission.

If you want to talk through whether SAR fits your operation, get in touch.

For the full company story, read the trilogy:

• Part 1: Our First Fleet — how three Holybro X500 V2 kits in a Belgium workshop turned into a software-and-hardware company
• Part 2: Why we built SAR (this post)
• Part 3: Why We Built Drone One — why the software company added hardware

Companion piece: Why Software Is the Hard Part of SAR Autonomy — the technical argument behind the SAR-specific stack.