How Long Can a Drone Controller Fly Blind? Measuring Recovery From Sensor Outages

Download technical figure · PNG · 1200 × 630

250 ms

Pass

3/3 missions

3/3 paired checks

6/6 recovery windows

500 ms

Pass

3/3 missions

3/3 paired checks

6/6 recovery windows

1 s

Mixed

2/3 missions

0/3 paired checks

3/6 recovery windows

2 s

Fail

0/3 missions

0/3 paired checks

0/6 recovery windows

Held-feedback baseline, seeds 0/1/2. Mixed means some mission passes; all one-second paired checks fail. This is not a safe-duration limit.

Download retained JSON · Source and criteria ↗

The useful answer is a set of measured outcomes, not a safe number. In AeroLoop's outage-duration study, all three 500 ms missions pass their original gates. So do their paired comparisons and all six recovery windows. At one second, one mission fails and every paired comparison fails. At two seconds, all three missions fail. The complete study deliberately retains accepted: false.

“Fly blind” is shorthand here for missing synthetic position and velocity captures. Attitude, angular rates, acceleration, mission supervision and contact sensing remain ideal. These are Isaac Sim PhysX experiments, not physical flight tests or a qualification of a flight controller for hardware.

Hold the comparison still

The retained AL-018 protocol and validation ↗ (opens in a new tab) keep the native controller, gains, mission gates, simulator and 200 Hz physics/control cadence unchanged. Position and velocity are captured at 50 Hz. Between successful captures, the controller receives the last available values.

Fifteen final flights cover five profiles across wind seeds 0, 1 and 2: a no-outage reference, then 250 ms, 500 ms, one-second and two-second gaps. Each outage profile has two missing-capture windows, starting at 18 and 40 seconds. The reference uses the same capture cadence. That matters: comparing an outage flight with an ideal-feedback flight would mix the effect of missing captures with the effect of capture cadence.

Each flight retains 10,001 control samples. The public JSON is a full-rate summary, not the raw local recordings. The comparison above reads its duration results directly; the portfolio does not rerun the simulator.

Three gates answer three questions

A mission gate asks whether the flight satisfies its original tracking, landing and final-state criteria. A paired comparison asks how much the outage flight departs from its corresponding no-outage reference. Sustained recovery asks whether the difference returns within a 50 mm band in time and stays there.

For recovery, an early crossing is insufficient. The study requires the final uninterrupted return to the band, at least one second of dwell, and a five-second deadline. A later excursion invalidates an earlier apparent recovery. An eventual return can therefore fail the recovery check, and a completed mission can fail the paired check.

At 500 ms, three of six windows actually leave the band. Their final returns begin 0.870, 0.965 and 1.125 seconds after outage end. The other three stay within the band throughout. Reporting six “recoveries” without that distinction would imply that all six had a disturbance to recover from.

Keep the failure visible

At one second, seed 0 exceeds the final horizontal-position limit: about 0.360 m against 0.350 m. All three seeds exceed the 0.15 m paired peak-separation bound. One first-window return takes 5.245 seconds, missing the deadline, and two seeds never establish the required final in-band suffix after the landing outage.

At two seconds, every mission exceeds the 0.5 m/s touchdown horizontal-speed limit. All first-window returns are late, and none establishes the required final landing-window return. The result is not “outage tolerant” without qualification. It is evidence of which tested profiles recover and where this controller fails under unchanged gates.

Three seeds and four discrete outage durations cannot establish a monotonic boundary, stability proof or general safe duration. In particular, a 500 ms pass does not make every shorter gap safe under arbitrary timing, wind or sensing assumptions.

Test the next idea against the same failures

The next predictive-feedback study ↗ (opens in a new tab) adds opt-in prediction. One-second mission passes improve from two to three, but every one-second paired check still fails. Two-second missions still all fail, and prediction worsens feedback error in one retained case. The overall stress result remains false.

The latest capture-aware landing study ↗ (opens in a new tab), merged in PR #21, tests an opt-in descent guard with separate regression and previously unseen cohorts. It adds 24 fresh flights and 240,024 new control samples. Guarded missions pass 9/12 regression and 2/6 unseen cases, matching the baseline pass counts. All two-second missions still fail.

Some touchdown speeds improve. Other outcomes worsen, miss the deadline or never touch down within the recording. The guard changes commanded altitude, while scoring retains the original mission target. It does not earn a pass by changing the question after measurement. Neither prediction nor the guard becomes the default, and the independent yaw-refinement gate remains open.

Make the boundary useful

The engineering decision is to retain the failures as regression evidence and keep both mitigations opt-in. A future candidate needs to improve the relevant gates without losing the existing short-outage results, under a comparison fixed before measurement. This is a proposed evaluation direction, not a claim that a later controller already satisfies it.

Start with the AeroLoop case study, inspect the latest experiment note, or follow the source's paired landing demonstration workflow ↗ (opens in a new tab). Its recorded 3D export is produced locally; the portfolio's earlier turbulent-flight replay remains a separate experiment.