VLA · Phase 9 · VLA Deployment and Robot Integration
9.7 — Safety Monitors and Fallback Behavior
Detecting problems at run time and stopping or falling back safely.
Assume the policy will sometimes be wrong, and build the system so that this does not matter. This lesson covers monitors, a small state machine, the arithmetic of stopping and how to choose a fallback.
Claims about papers, models and textbooks carry numbered references, listed with what each one is cited for in the References. Code marked “Toy model” is our own illustration, not the cited system.
Learning objectives
After this lesson, you should be able to:
- Build a bank of simple monitors that report all reasons.
- Write a safety state machine with explicit transitions.
- Compute stopping distance from speed, reaction time and deceleration.
- List fallback behaviours and how to choose between them.
- The policy proposes an action
- Independent monitors check inputs, commands and health
- The state machine decides: normal, degraded or stopped
- A fallback runs if needed
- Only a person restarts after a stop
The one-sentence idea
Independent, simple monitors that do not trust the policy.
Decide the fallback in advance, and test it.
Assume the policy will sometimes be wrong
A learned policy can fail in ways its designers did not foresee (lessons 3.5 and 8.4). A safe system is therefore built so that a wrong action does not become an accident: independent monitors watch the robot and the policy, and when something is off they move the system to a safer state. The monitors must not depend on the policy being right; ideally they are simple, separate and checkable. Industrial standards formalise parts of this. As summarised in secondary sources (I did not read the standards themselves, and editions have changed, so use the current texts for any compliance work), they describe four kinds of collaborative operation: safety-rated monitored stop, hand guiding, speed and separation monitoring, and power and force limiting.[1]
A bank of simple monitors
Each monitor checks one thing and returns “ok” or a reason. Typical ones: input freshness (lesson 9.1), command validity and limits (9.4), heartbeat (9.1), and task-level checks such as “the gripper is closed but the object is not lifted”. Collect them in one place and report all reasons:
def check_all(state):
reasons = []
if state["image_age_s"] > 0.3: reasons.append("camera input stale")
if state["rejected_commands_last_10"] >= 3: reasons.append("too many rejected commands")
if state["joint_speed_ratio"] > 1.0: reasons.append("joint speed above limit")
if state["seconds_since_heartbeat"] > 0.5: reasons.append("policy heartbeat lost")
return reasons
situations = {
"normal": {"image_age_s": 0.05, "rejected_commands_last_10": 0, "joint_speed_ratio": 0.4, "seconds_since_heartbeat": 0.1},
"camera stalls": {"image_age_s": 0.9, "rejected_commands_last_10": 0, "joint_speed_ratio": 0.4, "seconds_since_heartbeat": 0.1},
"policy confused": {"image_age_s": 0.05, "rejected_commands_last_10": 5, "joint_speed_ratio": 1.2, "seconds_since_heartbeat": 0.1},
}
for name, s in situations.items():
print(f"{name:<16} ->", check_all(s) or "all ok")Output:
normal -> all ok camera stalls -> ['camera input stale'] policy confused -> ['too many rejected commands', 'joint speed above limit']
Toy model. Invented thresholds. Real thresholds come from the robot’s specification, a risk assessment and testing.
Report every reason, not just the first: when two fire together, that is information.
A small state machine: normal, degraded, stopped
What the system does when a monitor fires should be decided in advance and written as a small state machine, not improvised in code. Three states are a good start: NORMAL (the policy drives), DEGRADED (slow down, ask for help, maybe retry) and STOPPED (hold safely; a person must restart). Transitions are explicit:
class Safety:
def __init__(self): self.state, self.bad_ticks = "NORMAL", 0
def update(self, reasons, hard_fault=False):
if hard_fault: # e.g. limit violated, heartbeat lost: stop at once
self.state = "STOPPED"
elif self.state == "STOPPED":
pass # stays stopped until a person resets it
elif reasons:
self.bad_ticks += 1
self.state = "STOPPED" if self.bad_ticks >= 3 else "DEGRADED"
else:
self.bad_ticks = 0
self.state = "NORMAL"
return self.state
s = Safety()
timeline = [([], False), (["camera input stale"], False), ([], False), (["camera input stale"], False), (["camera input stale"], False),
(["camera input stale"], False), ([], False), ([], False)]
for t, (reasons, hard) in enumerate(timeline):
print(f"tick {t}: reasons {reasons or '-'} -> {s.update(reasons, hard)}")Output:
tick 0: reasons - -> NORMAL tick 1: reasons ['camera input stale'] -> DEGRADED tick 2: reasons - -> NORMAL tick 3: reasons ['camera input stale'] -> DEGRADED tick 4: reasons ['camera input stale'] -> DEGRADED tick 5: reasons ['camera input stale'] -> STOPPED tick 6: reasons - -> STOPPED tick 7: reasons - -> STOPPED
A brief glitch (tick 1) only degrades the system, which recovers (tick 2). Three bad ticks in a row stop it (tick 5), and it stays stopped even when the monitors clear: restarting is a human decision.
Stopping takes distance
“Stop” is not instant. A robot moving at speed v that begins to brake with deceleration a needs a distance v²/(2a), and the reaction time before braking begins adds v × reaction time. The speed-and-separation concept in the collaborative-robot standards builds on exactly such terms: the protective separation distance is computed from the positions and speeds of the person and robot, the robot's stopping distance, measurement uncertainty, system latency and control frequency, and the robot is stopped if the actual separation is below it.[1] A deliberately simplified calculation of the robot's own part:
def stopping_distance(speed, reaction_s, decel):
return speed * reaction_s + speed ** 2 / (2 * decel)
reaction = 0.15 # seconds: monitor detects the problem and the stop command takes effect (assumed)
decel = 5.0 # m/s^2, an assumed braking deceleration
for speed in (0.1, 0.25, 0.5, 1.0):
print(f"hand speed {speed:4.2f} m/s -> travels {stopping_distance(speed, reaction, decel) * 100:5.1f} cm before stopping")Output:
hand speed 0.10 m/s -> travels 1.6 cm before stopping hand speed 0.25 m/s -> travels 4.4 cm before stopping hand speed 0.50 m/s -> travels 10.0 cm before stopping hand speed 1.00 m/s -> travels 25.0 cm before stopping
Toy model. A simplified formula with assumed numbers, not the standards’ full calculation, which also includes the person’s motion and uncertainties.
Doubling the speed roughly quadruples the braking part. A learned policy that is allowed to move fast leaves less room for monitors to act: speed limits are a safety measure in their own right, and latency (lesson 8.6) directly lengthens the reaction term.
Choosing the fallback
Possible fallbacks, from mild to strong: hold the last position; slow down; retreat to a safe pose; hand over to a person (teleoperation); protective stop with power removed or brakes on. The right one depends on the task: holding an open container above a table is not safe; dropping a heavy object is not safe either. Decide per task, in advance, with a risk assessment, and test every fallback by deliberately triggering the fault. A fallback that has never been tested is a hope.
Common misconceptions
Misconception 1 “A well-tested policy does not need monitors.”
Correction Distribution shift can appear at any time.
Misconception 2 “Stopping is instant.”
Correction It takes reaction time and braking distance, growing with the square of speed.
Misconception 3 “The policy can monitor itself.”
Correction Monitors should be independent of the thing they watch.
Engineering takeaways
- Simple independent monitors.
- Explicit state machine.
- Stopping distance = v·t + v²/2a.
- Test fallbacks.
Plan for the wrong action.
Knowledge check
Try each question first, then reveal the explanation.
Question 1
Speed doubles. What happens to the braking part of the stopping distance?
Explanation
It roughly quadruples.
Question 2
Who should restart the robot after a STOPPED state?
Explanation
A person.
Question 3
Why test fallbacks by triggering faults?
Explanation
An untested fallback may not work.
References
Numbered notes in the text, like [1], point here. Each entry says what it is cited for and how that was checked. Papers and books can be revised or misread, so follow the links before relying on a detail. Code marked “Toy model” is our own illustration of an idea, not the code of the cited system.
(2016). ISO 10218-1/-2 (industrial robots) and ISO/TS 15066 (collaborative robots). www.iso.org
Cited for:
- The standards describe four types of collaborative operation: safety-rated monitored stop, hand guiding, speed and separation monitoring, and power and force limiting. Checked against the publication record.
- Speed and separation monitoring keeps a protective separation distance between person and robot, computed from the positions and speeds of both, the robot’s stopping distance, measurement uncertainty, system latency and control frequency; if the actual separation falls below it, the robot is stopped. Checked against the publication record.
What’s next
That completes deployment. Next: humanoid VLA systems.