What a robot does after something goes wrong. Most papers cover detecting the fault. Few cover recovering from it so the robot keeps doing useful work, and most robots stop and wait for a person.
Detection
- Residuals against a model. Predict what a sensor should read and flag disagreement (Bezzo). A fault the motion never excites leaves no residual (Hausman).
- Invariants. Physical rules the process must obey, written from the design (Adepu and Mathur), mined from logs (Umer), or drafted by an LLM from documents (INVARLLM: 29 of 36 attacks caught, but 42.54% precision per sample). My years on the SWaT testbed were mostly spent here.
- Learned detectors on the policy itself. SAFE reads a VLA’s internal features, FAIL-Detect treats failure as out-of-distribution detection without any failure data, and Hide-and-Seek uses contrastive trajectory signals. All three use conformal prediction to set the alarm threshold.
- Outside judges. A VLM watching the robot. FailBench found the best of 13 VLM detectors reaches 0.77 balanced accuracy, fine-tuned ones do worse than general ones, and all of them lean towards calling ambiguous attempts a success. No Free Checker puts it generally: the cheaper and earlier a verdict, the less it tells you.
Every detector here depends on a witness the faulty part doesn’t control: a second sensor, a second network path, the physics of radio, a design document.
Recovery
Mostly stopping, or handing control to something conservative:
- Simplex switches to a verified safe controller. SOTER adds the switch back: its advanced controller ran more than 96% of 104 simulated hours, and all 34 crashes came from the safe controller not being scheduled in time.
- Shields allow a few steps to recover, then drop into a fail-safe.
- Control barrier filters keep the robot safe by giving up progress, and their multi-robot version admits deadlock in crowds.
- ROSMonitoring’s only built-in reaction is dropping a message. Caldas and others found no guidelines for anything richer.
Swarms recover by exclusion: Strobel’s token economy starves bad robots, the blocklist protocol cuts off both ends of an accusation, honest accusers included. Real repair is rare. O’Keeffe sends a flagged robot home before it fails, Oğuz reroutes traffic until an intermittent fault clears, Mayya reallocates tasks, and Pant schedules trips to recharge.
Stopping
A robot that always stops when unsure is safe and useless, and an easy target. Steinberg and Gal halt an LLM-controlled robot in up to 98.3% of multi-turn runs with one to five spoken safety phrases. In the field, a robot that latches into a state no command can clear needs a person to power-cycle it, which can mean a boat trip. My workshop paper Safe but Stuck is about this.
Faults and attacks
Most papers don’t separate a teammate that is broken from one that lies. Fault papers assume random, independent faults; security papers assume a bounded number of worst-case robots with trusted identities. The case in between, a real robot with its own identity and a broken sensor, falls through both. Luckcuck and others quote Winfield and Nembrini: a robot with dead wheels and a working radio hurt the swarm more than a dead one. The two need different recoveries: a broken robot can be repaired or given another job, and a liar has to be cut off.
Questions
- How long does a robot stay useful after its safety layer acts? Almost nobody measures it.
- What does recovery look like for a team, when the robot that failed is the one that was relaying for the others?
- Can a robot tell its teammates “I’m degraded, here’s what I can still do”?
Related: runtime monitoring, safe control, robust robotics, long-term autonomy.