Guardian drones: design and evaluation

Guardian drones help a station cope with an attack by another drone, or by a missile from far away, with mission control shared between the station, a command center and each drone's own autonomy. This page evaluates that idea, improves it twice, and records what was built and measured, in simulation. The replay is on the guardian page; the numbers are in the simulator results.

1. The idea, evaluated

What is strong. A fleet already flying around a station is a sensor network. Drones at altitude see low flyers that a ground sensor loses behind terrain and clutter, and they can be placed where attacks come from. Giving them a protective role, coordinated with the station and a command center, is the right instinct: the value is in the cooperation, not in any single drone.

What does not hold up.

What the guardian role should be. Sense and track; warn the station and the crew early; keep the fleet clear of threats; shelter or disperse; fall back safely when links fail; and hand every decision beyond protection to the center. Jamming and GNSS spoofing are the attacks drones meet most often, so they belong in scope.

2. First round of improvements: the mission

Idea as asked Improved Why
Fight the attacker Non-kinetic protection: sense, warn, keep clear, shelter, fall back Physically credible, legally clear, and it is where mission-computer design matters
Missile threat Early warning for fast threats, measured in seconds For fast threats the only lever is time; the simulator measures how much each design buys
Drone and missile only Add jamming, GNSS spoofing, loss of the center link, birds and clutter, swarms The realistic attack surface; false alarms matter as much as misses
"Cooperate with the station, the center or self-control" Three layers with explicit authority and time budgets Who may decide what, and what happens when the layer above is unreachable
Evaluate by watching Measure: warning time, separation, false alarms, detection latency, invariants over many seeded runs Claims backed by numbers, and regressions caught by tests

3. Second round of improvements: the engineering

  1. Authority by time budget. Onboard (under a second): keep clear of an imminent conflict, hold and then return when the uplink goes quiet. Station (seconds): fuse tracks, set the posture, order guardians, alert the crew, relocate. Center (tens of seconds): acknowledge, authorise recovery or resumption, anything beyond protection. The station's own actions are pre-delegated by the center; with the center unreachable it keeps protecting and may only land guardians after a timeout, never resume the mission.
  2. One decision module, two simulators. tools/guardian.py holds the tracker, threat assessment, posture, keep-clear, onboard fallbacks, the center model, the navigation integrity check and the authority table. The fast simulator and the PX4 nodes import the same code.
  3. Tracks, not detections. A constant-velocity Kalman filter per track, association in normalised residual, M-of-N confirmation, merging of duplicates, and a plausibility gate on how fast a young track may move.
  4. Classification before alarm. Guardian cameras label what they see; a track classed as a bird never raises RED and does not hold the posture at AMBER, and an unclassified slow track may raise RED only close in. Fast tracks with a steady speed raise RED at once.
  5. Invariants the tests enforce. A keep-clear or dispersal move, new or kept, opens the range along its whole straight path to every relevant track (not a bird and not a steady fast object, predicted to come near) and shortens no steady fast object's predicted miss, since a fast object is judged on its path rather than on where it is now; a guardian re-checks a station keep-clear or dispersal move against its own tracks before flying it; and every logged action is taken by a layer allowed to take it.
  6. Leaving an impact area comes first. Inside a fast object's predicted impact area, a guardian disperses whenever the dispersal move is itself a keep-clear move; otherwise keeping clear decides. A dispersal under way is kept while it still leads out, because a young track's impact estimate moves by metres between updates. The order carries the area, so a guardian that cannot fly the station's move re-plans its own way out.
  7. Cross-checks against spoofing. The station compares each guardian's reported GNSS position with an independent observation of it: its own sensor's track of that guardian in the fast simulator, a datalink fix in the PX4 flights. A slow drag-off passes the drone's own consistency checks but not this one. A flagged guardian navigates by the station's fixes (horizontal only; height stays barometric) and lands where it is if they stop.
  8. Layout is part of the design. The simulator tests where the posts are, not only what the software does.

4. Threats and scenarios

Scenario What happens What it tests
Low intruder One drone at 15–20 m/s and 30–50 m altitude, weaving, flies to the station from a random bearing Detection of low flyers, warning time, keeping clear, relocation
Fast inbound A 250 m/s object cruises at 150–250 m and dives on the station for its last 1.5 km The limit of what warning can do; confirmation latency; layout
Swarm Five low drones from two sectors, staggered over 30 s Multiple tracks, multi-threat keep-clear
Birds and clutter Eight slow birds circling 700–1500 m out, with five times the usual clutter False alarms
Jammed picket An intruder along one picket's sector; a jammer cuts that picket's link Onboard autonomy under jamming; loss of that picket's sensor data
GNSS drag-off One picket's reported position drifts at up to 3 m/s, ramped in over 30 s Navigation integrity through cooperation
No center link An intruder while the station cannot reach the center Delegated authority
Combined Three intruders, a jammed picket, birds and no center link Everything at once

5. Architecture

flowchart BT
    CENTER[Center: acknowledge, authorise recovery, anything beyond protection]
    STATION[Station on the carrier: fuse tracks, posture, orders, crew alert, relocation]
    subgraph GUARDIANS[Guardians]
        G1[Guardian: own sensor, onboard reflex, lost-link procedure, C++ supervisor, PX4]
        G2[Guardian: own sensor, onboard reflex, lost-link procedure, C++ supervisor, PX4]
    end
    CENTER -->|acknowledgements, decisions| STATION
    STATION -->|orders, clearances, station fixes| GUARDIANS
    STATION -->|posture reports, recovery requests| CENTER
    GUARDIANS -->|detections, position reports| STATION
Data-flow diagram — source is available below.
Mermaid source
flowchart BT
    CENTER[Center: acknowledge, authorise recovery, anything beyond protection]
    STATION[Station on the carrier: fuse tracks, posture, orders, crew alert, relocation]
    subgraph GUARDIANS[Guardians]
        G1[Guardian: own sensor, onboard reflex, lost-link procedure, C++ supervisor, PX4]
        G2[Guardian: own sensor, onboard reflex, lost-link procedure, C++ supervisor, PX4]
    end
    CENTER -->|acknowledgements, decisions| STATION
    STATION -->|orders, clearances, station fixes| GUARDIANS
    STATION -->|posture reports, recovery requests| CENTER
    GUARDIANS -->|detections, position reports| STATION
Layer Time budget Decides When the layer above is unreachable
Onboard Under a second Keep clear of a conflict predicted inside the reflex horizon; hold when the uplink goes quiet; return to the rally point if it stays quiet Its own sensor and the pre-briefed lost-link procedure
Station Seconds GREEN / AMBER / RED; crew alert; keep-clear, hold and disperse orders; relocation; switching a spoofed guardian to station fixes Keeps protecting; lands guardians under delegation after the center timeout; never resumes the mission alone
Center Tens of seconds Acknowledgement; recovery or resumption after an event; any response to the threat itself (outside this lab) Nothing crosses a dead link; decisions are retried when it returns

6. Evaluation method

tools/guardian_sim.py is a kinematic simulator. Five guardians (four pickets 900 m out at 80 m, one overwatch above the station at 60 m) fly at up to 12 m/s. The station's ground sensor sees 1200 m, but only 400 m for targets below 50 m; guardian sensors see 800 m in every direction and classify inside 500 m. Links have 0.2 s latency and 2% loss; the center answers after 1.5 s each way plus an 8–20 s operator decision. These are illustrative round numbers chosen to expose trade-offs, not the specification of any real sensor or aircraft.

Four designs run against the same seeded threats: station only (no drone sensing), onboard only (drones sense and protect themselves, no network), networked (drone sensing fused at the station, which gives every order; no onboard autonomy), and hybrid (networked plus onboard reflexes, lost-link procedures and the navigation cross-check). Each cell is many seeds; the results page lists medians and percentiles.

7. What the evaluation shows

The generated tables are in the simulator results. These are properties of the simulated designs under the illustrative numbers above, not of real sensors. In summary:

8. Lessons the simulator taught

Each of these was found in a failing run, traced, and fixed in the shared module:

Found Symptom Fix
Fixed-gain filter with a two-point velocity start An 18 m/s intruder read as 10–60 m/s; heading flipped; RED came seconds before arrival Constant-velocity Kalman filter weighted by each sensor's noise
Straight-line prediction against a weaving intruder At long range a 20° weave misses the station by hundreds of metres "Inbound" also means heading within 25° of the station
Friendly association by nearest report A threat passing close to a guardian was absorbed as that guardian and dropped from tracking; the same mistake raised a false spoofing alarm Each friendly claims only its nearest return; every other return is tracked
Clutter chains Random points lined up into "tracks" at hundreds of metres per second and raised false REDs A young track may only take detections reachable at a plausible speed; RED needs support beyond confirmation
Keep-clear chattering A guardian that moved far enough to clear the prediction was told to hold, stopped halfway and was back in conflict An episode latch: keep clear until the conflict has passed, re-planning but never dropping to hold
Lost-link return at ground level A jammed guardian flew home at the station's height, straight through the intruders' altitude band The rally point keeps cruise altitude
Too few escape options Two crossing intruders squeezed a guardian Half-length moves and a climb option under a ceiling
Overwatch above the protected point Unsavable against a fast inbound object Offset the overwatch (layout experiment)

9. Logic and code review

Two separate reviews, run by AI review agents, read the decision module, the fast simulator and the PX4 integration after the eight flights were built, and replayed their doubts in the simulator before reporting them. Every finding below was reproduced, fixed in the code, covered by a test, and the evidence was regenerated.

Found What it did Fix
The integrity check compared a stale or masked report with whatever return lay near it, and an alarm never cleared In 30 of 280 non-spoofing hybrid runs a healthy guardian was switched to station fixes of a bird or another guardian; errors reached 2 km The station keeps its own track of each guardian by continuity, gated by its sensor's accuracy, the guardian's reported velocity, its barometric height and the sensor's coverage; reports older than 2 s are not compared; an alarm clears after six consistent observations. Now 0 false alarms in 1280 runs
The switch to station fixes was sent once; nothing limited a fix's age One lost message left a flagged guardian on GNSS (dragged 603 m); if fixes stopped it flew on a frozen correction Every fix carries the switch and every order names the navigation source; after a fix timeout the guardian lands in place on its own authority
predicted_miss sampled 24 points in 60 s A 250 m/s object "missed" by 250 m a guardian it would hit Exact closest approach on each leg of the move
Assessment extrapolated a relocating station's velocity forever RED dropped seconds after relocation began, with the threat still inbound Threats are judged against where the station will stop
A late measurement was compared with the track's current state; class ties went to "bird" A 0.4 s-late detection moved a fast track by 32 m; a drone labelled 2:2 could never raise RED Late measurements are compared with where the track was; ties go to the class that needs more protection
A stale answer from the center was accepted A "recover" decided before a new event recalled guardians after it Each clear is a numbered request; only the answer to the open one counts, and only at GREEN
The station planned orders from stale guardian state A move computed from a jammed guardian's old position sent it back toward a threat Orders go only to guardians heard within three report periods, carried forward by their velocity; a silent one is told to hold; every guardian re-checks a station move against its own tracks
Dispersal skipped every guard and was centred on the moving station The PX4 fast-object dispersal pointed nearer the object and beside a cylinder Dispersal points are checked for free space and for opening the range, and centred on the predicted impact point
Keep-clear checked only the end point; kept orders were never re-checked A path could dip toward a threat; a kept target could end up nearer one The whole straight path must open the range, and a kept order is re-checked every cycle. Counting every track, distant birds included, then left an overwatch at its ceiling with no allowed move while an intruder passed beneath it; only relevant tracks count now
The rally point and the delegation rule used knowledge the station and guardians could not have A jammed guardian homed on the station's live position; delegation read the simulator's own flag The rally is the station's position as last heard; delegation follows the center's silence
Birds held the posture at AMBER; the PX4 birds flew faster than the slow-speed gate, one circling where the carrier relocates The quiet watch never ended; an unlabelled bird raised RED Birds do not hold AMBER; the PX4 birds were laid out and scaled like the fast simulator's
Relocation always drove to the same stop In the swarm the carrier drove toward the second intruder's path The stop is chosen from the tracked threats' predicted paths
The spoofer ran the gz command-line tool twice a second, and its comment had the drag direction reversed The load starved the simulation; the supervisors saw stale IMU data and landed two guardians An in-process Gazebo client, called only when the offset changes; the drag heads away from the cylinders
One guardian's route passed a metre under another holding its post 0.99 m separation in the fast-object flight Every route and move keeps out of the cells around the other posts
Metrics and checks were weaker than their names False REDs were forced to 0 in threat scenarios; "X% pass" was the worst cell; designs drew from one random stream; threat_confirmed passed on clutter; one track could count twice False REDs counted everywhere, exact shares, common random numbers per sensor and link, and truth-based PX4 checks

The review also questioned whether the invariants prove anything: checking a rule the code already enforces only catches a broken implementation. The results page now also measures the same property on truth. In some runs a move, planned on tracks, brought a guardian more than tracking error nearer a real threat, mostly a weaving one at long range: 13 of 40 hybrid runs in the combined scenario, 8 of 40 in the swarm. That is the price of straight-line prediction. No guardian lost its safe radius in those runs.

10. The same logic on real PX4

Eight flight scenarios, one per threat above, run the decision module on three real PX4 instances in Gazebo. The arena is 20 m across, so speeds, ranges and radii are the fast simulator's scaled down: intruders fly at 1.2 m/s, the fast object dives at 5.5 m/s, and the safe radius is 1.5 m. Guardians launch from the carrier one at a time, hold watch posts at their own altitude layers, and land back on it when the event is over. Each scenario adds its own threats and conditions: a low intruder, a fast object diving on the carrier, three intruders from two sectors, circling birds with sensor clutter, a jammer around one guardian's post, a GNSS drag-off on every receiver, a dead link to the center, and all of these at once. The environment (threats, sensors, jamming, spoofing) and the center are simulated; the guardians' adapters, supervisors and PX4 are the real flight stack. Separations, drift and landings are judged on Gazebo truth. The SITL guide lists the topics and acceptance checks, and the PX4 evidence the measured results.

In the 30 September 2026 matrix all eight passed every check, 332 in all:

Flight Checks What the evidence shows
guardian_intruder 42 / 42 RED 12.1 simulated seconds before the intruder reached the carrier's parking spot; the carrier relocated and stayed 10.0 m clear; closest guardian 4.77 m; recovery on the center's decision
guardian_fast 41 / 41 RED 1.9 s before impact; the guardian nearest the impact point dispersed from 3.6 m to 5.9 m away before impact; closest guardian 3.84 m
guardian_swarm 42 / 42 Three distinct tracks confirmed; closest guardian 4.39 m
guardian_birds 39 / 39 No RED, and every guardian held its post; the quiet watch ended by asking the center
guardian_jamming 43 / 43 The jammed guardian kept clear on its own, 5.44 m from the intruder at the closest, and regained its link after leaving the zone; filmed from both cameras
guardian_spoofing 41 / 41 The station flagged all three receivers 10 s after the drag-off began; each flew on station fixes and none strayed more than 1.41 m from its post
guardian_center_loss 41 / 41 With the center unreachable, the station recovered the guardians under delegation, 20 s after its request (timeout 20 s)
guardian_combined 43 / 43 Two intruders, two birds, clutter, the jammer and no center at once; closest guardian 1.93 m; recovery under delegation

11. Limits

Reproduce

python3 tools/guardian_sim.py --seeds 40 --workers 8 --output artifacts/guardian
python3 -m unittest tests.test_guardian
bash scripts/run_sitl.sh --scenario guardian_jamming --video --output ~/work/mission-computer-lab/retests/guardian-001