The Problem with Fixed Parameters

SAR runs drone relay handoffs on a set of configurable parameters — swap threshold, patrol speed, transit speed, relay overlap. Out of the box, these defaults work. A 20% swap threshold gives the standby drone enough time to reach the handoff point. A patrol speed of 5 m/s balances coverage quality against battery endurance. Reasonable numbers for a reasonable day.

But days are not reasonable. Wind at 6 m/s increases battery drain by roughly 30%. That 20% swap threshold that gave you comfortable margins on a calm morning now leaves the active drone fighting headwind on its return leg with 12% remaining. A fleet of three drones with one in maintenance rotation means your standby pool is exactly one deep — and a 20% threshold that assumes two standbys ready to go is spending battery you cannot afford to spend.

Fixed parameters optimise for average conditions. Operations do not happen in average conditions.

What SAR AI Does

SAR AI is a decision engine built into the SAR ground station that dynamically tunes fleet-mode parameters every 30 seconds based on live fleet telemetry. It is not a chatbot. It is not a dashboard with recommendations. It is a system that reads battery state, wind conditions, fleet depth, and detection activity, then writes updated parameters directly into the fleet configuration.

The engine models the real physics of the active airframe — battery discharge curves, wind drag penalties, transit power consumption, charge times. It knows that a drone at 25% SOC in 7 m/s wind does not have the same endurance margin as a drone at 25% in still air. It adjusts accordingly, every 30 seconds, for every drone in the fleet. Battery profiles for Freefly Astro Max, Quantum Systems Trinity Pro, and X500 4S LiPo are all first-class in the model. Reference implementation runs on the X500 V2 dev fleet; production deployments are on Astro Max and Trinity Pro.

The Decisions It Makes

Swap threshold (15–30%). When to trigger the relay handoff. On a calm day with three standbys charged, the engine pushes this down toward 15% — extracting maximum flight time from each battery cycle. In 6 m/s wind with one standby available, it pulls up to 25% or higher. The margin expands to match the risk. Higher wind means earlier swap. Thin fleet means more conservative thresholds.

Relay overlap (0–30%). How much of the previous drone's route the incoming drone re-covers after handoff. In normal conditions, overlap is zero — the new drone picks up at the exact handoff waypoint and continues forward. When the active drone has flagged a detection event near the handoff zone, the engine increases overlap so the incoming drone re-sweeps that segment. A person in the water does not stay in one place. Re-covering 200 metres of route costs 90 seconds of flight time but catches drift.

Transit speed (1.0–2.0x). How fast the standby drone flies from the launch point to the handoff waypoint. The default is 1.5x patrol speed — fast enough to close the gap quickly, slow enough to preserve battery for the patrol leg. In high wind, the engine reduces transit speed. Fighting a headwind at 2.0x burns battery at 1.4x the normal transit rate. The engine knows the heading to the handoff point, knows the wind vector, and adjusts transit speed to keep total mission energy within the battery budget.

Patrol speed (2–8 m/s). Cruise speed during the patrol leg. Slower speed extends endurance — a drone at 3 m/s in 5 m/s wind lasts longer than the same drone at 6 m/s in the same wind, because the power curve is not linear. The engine reduces patrol speed in sustained wind to stretch each sortie. It increases speed when fleet depth is high and coverage tempo matters more than individual endurance.

Dispatch priority. Which standby drone to send next. The engine selects the drone with the highest state of charge. If two standbys are at 98% and 85%, the 98% drone dispatches. If a drone has been sitting on standby for 40 minutes and its battery has cooled, the engine accounts for the temperature-adjusted capacity. Simple rule, but it requires knowing the actual SOC of every drone in the fleet in real time.

The Physics Model

SAR AI does not guess. It models the real performance envelope of every airframe in the fleet — Freefly Astro Max and Quantum Systems Trinity Pro for production deployments, X500 V2 for dev. Same physics, same wind and transit math, different endurance numbers per airframe.

Wind drain multiplier. Battery drain increases by approximately 10% for every metre per second of wind above the 3 m/s baseline. A drone in 7 m/s wind burns battery 40% faster than in still air. This is the single largest variable in relay timing. On a Freefly Astro Max battery, a 37-minute calm-air sortie drops to ~26 minutes in moderate wind; on an X500 V2 with a 4S 5200 mAh pack, a 20-minute calm-air sortie drops to ~14 minutes. The engine reads the wind estimate from the active drone's telemetry and applies the multiplier to every endurance calculation, regardless of platform.

Battery profiles. Three airframes in the dropdown: Freefly Astro Max (37 min flight, ~90s hot-swap), Quantum Systems Trinity Pro (90 min VTOL, ~90 min recharge), and X500 V2 with 4S 5200 mAh (20 min flight, 1 h charge). The engine knows which profile is selected and adjusts all timing accordingly. A fleet running Trinity Pro VTOL has fundamentally different relay dynamics than a multirotor Astro Max fleet — longer sorties, longer recharges, different fleet-size math for continuous coverage.

Transit drain. Flying to the handoff point at 1.5x speed costs 1.4x the power per kilometre compared to patrol speed. At 2.0x, the penalty is closer to 1.8x. The engine calculates the transit distance, applies the speed-dependent drain rate, and subtracts the transit energy budget from the total available for patrol. The remaining energy determines how long the drone can stay on station before the next handoff.

The Safety Boundary

Every parameter adjustment passes through a Safety Gate before it reaches the fleet. The gate enforces hard limits that the engine cannot override.

Critical battery threshold is fixed. The minimum SOC required for a drone to return home is calculated from distance, wind, and altitude — and the engine cannot set the swap threshold below it. If the calculated return energy is 14%, the swap threshold will never go below 15% regardless of what the optimisation logic suggests.

Geofence boundaries are immutable. No parameter adjustment can cause a drone to exit the defined operational area. Transit routes to handoff points are checked against the geofence before dispatch.

Wind critical is a hard gate. When sustained wind exceeds 8 m/s, the Safety Gate forces conservative parameters across the board — high swap threshold, reduced transit speed, reduced patrol speed. The engine's optimisation is overridden in favour of maximum safety margin.

Every decision the engine makes is logged with a full audit trail — the input telemetry, the calculated parameters, the Safety Gate result, and the final values written to the fleet configuration. The operator can review exactly why every parameter changed and when.

Offline-First

SAR AI runs entirely on the operator's laptop. The decision engine, the physics model, the Safety Gate — all local computation. Zero internet required. The system works identically on a clifftop with no cellular coverage as it does in a connected operations centre.

When connectivity exists — Starlink, cellular, field Wi-Fi — the engine can optionally hand decisions to Claude AI running in the cloud. The AI layer adds contextual reasoning that the local physics model cannot provide: weather forecast integration (wind increasing in 2 hours, front the swap threshold now), mission-specific pattern recognition, and natural language explanations of parameter changes for the operator log.

The UI shows the current decision source clearly: LOCAL or CLOUD. The operator always knows whether parameters are being set by the onboard physics engine or by the cloud-assisted AI. If connectivity drops mid-mission, the system falls back to LOCAL seamlessly. No degradation, no interruption, no operator action required.

What It Does Not Do

SAR AI does not modify the active flight plan of an airborne drone, even though the MAVLink channel supports it (PARAM_SET and mission-item re-upload are available at any point during a flight). This is a deliberate design choice, not a platform limitation.

SAR AI operates at the dispatch boundary. In a relay operation, that decision point comes every 16 to 56 minutes depending on battery profile — each time a new standby drone is prepared for launch. The engine calculates the optimal parameters for the next sortie based on current conditions, writes them into the mission package, and the fleet layer dispatches the drone with those parameters baked in. A drone already airborne continues its sortie on the plan it launched with, while the adjustments apply to whatever takes off next.

Why operate at the dispatch boundary on MAVLink when mid-flight tuning is physically available? A drone in flight is a system executing a validated plan. Changing parameters mid-flight introduces failure modes — communication latency, partial updates, conflicting commands, and a much harder audit trail. Dispatch-boundary adjustment preserves the "validated plan per sortie" invariant across both platforms, which simplifies the Safety Gate, the audit log, and what operators can reason about at 0300. The mid-flight channel is reserved for Safety Gate actions — RTH commands under weather abort, kill-from-GS, and dynamic geofence enforcement — where the risk of inaction outweighs the risk of modification.

Try It

SAR AI ships as part of SAR's fleet patrol mode. If you already run fleet patrols, SAR AI is in your ground station software — enable it in the fleet configuration panel. If you are evaluating SAR for continuous patrol operations, request a demo and we will walk through the decision logic on a live fleet.