Validating emergency-stop behavior

1. Engineering problem

An emergency stop is validated by measurement, not by design intent. Reaction time and deceleration vary with load, floor and battery, so the stopping distance must be measured over repeated trials in the worst conditions and compared with the protective distance.

2. When is this needed?

• Commissioning the robot.
• After any change to the drive, brakes, payload or software.
• As a periodic check.

3. Selection and design decisions

Method: trigger the stop while moving at maximum speed (and with the maximum payload, on the worst floor, at the lowest battery), log velocity and the trigger instant at high rate, compute the time and distance from the trigger to zero speed for every trial, and compare the worst case with the requirement. Safety-rated functions must be validated to the standards that apply to them (not read here); this checks the performance of the stop itself.

4. Advantages and disadvantages

• More trials and conditions give confidence and take time.
• High-rate logging shows the reaction time precisely.
• A margin factor on the measured worst case covers variation not seen in the trials.

5. Requirements and constraints

• Trials at maximum speed and worst conditions.
• Time stamps from one clock for trigger and velocity.
• Requirements written before the tests and judged on the worst case.

6. Architecture

trigger ─▶ log velocity at high rate ─▶ stop time, stop distance per trial ─▶ worst case versus requirement

7. Implementation

1. Define the conditions and the requirement.
2. Run the trials and log velocity and trigger time.
3. Compute stop time and distance (below) for each.
4. Compare the worst case with the requirement and apply a margin.
5. Repeat after any change.

def stop_metrics(t, v, t_estop):
    i0 = next(i for i, x in enumerate(t) if x >= t_estop)
    i1 = next((i for i in range(i0, len(v)) if v[i] <= 0.01), None)
    if i1 is None: return None
    dist = sum((v[i] + v[i + 1]) / 2 * (t[i + 1] - t[i]) for i in range(i0, i1))
    return t[i1] - t[i0], dist, v[i0]
trials = []
base = [round(0.1 * k, 1) for k in range(21)]
for decel, delay in ((1.5, 0.20), (1.4, 0.25), (1.6, 0.18), (1.2, 0.30), (1.5, 0.22)):
    v = []
    for tt in base:
        if tt < 0.1 + delay: v.append(1.0)
        else: v.append(max(0.0, 1.0 - decel * (tt - 0.1 - delay)))
    trials.append(stop_metrics(base, v, 0.1))
times = [t for t, _, _ in trials]; dists = [d for _, d, _ in trials]
print("stop times (s):", [round(t, 2) for t in times])
print("stop distances (m):", [round(d, 2) for d in dists])
req = 0.9
print(f"worst distance {max(dists):.2f} m against a requirement of {req} m ->", "pass" if max(dists) <= req else "FAIL")
print("a requirement is judged on the worst case over many trials, not the average:", f"mean {sum(dists) / len(dists):.2f} m")

Printed (checked by the site’s tests):

stop times (s): [0.9, 1.0, 0.8, 1.2, 0.9]
stop distances (m): [0.54, 0.61, 0.49, 0.72, 0.55]
worst distance 0.72 m against a requirement of 0.9 m -> pass
a requirement is judged on the worst case over many trials, not the average: mean 0.58 m

Reading it: five trials at 1.0 m/s give stop times of 0.8 to 1.2 s and stop distances of 0.49 to 0.72 m (mean 0.58 m); the worst case of 0.72 m passes an example requirement of 0.9 m. The requirement is judged on the worst case, not the mean. The data are synthetic and illustrative.

8. Real examples

• Commissioning report: twenty stops at 1.0 m/s with and without payload, worst distance 0.8 m.

9. Failure scenarios

• Judging by the mean.
• Testing only at low speed or unloaded.
• Not logging the trigger instant, so reaction time is unknown.

10. Troubleshooting

1. If the worst case is long, find the condition that causes it.
2. Check the delay between trigger and deceleration.
3. Check the floor and tyres.

11. Validation

• The analysis prints the lines shown (executed by the site tests).
• Twenty or more trials in worst conditions all meet the requirement with margin.

12. Engineering checklist

• Worst conditions defined
• High-rate logging
• Stop time and distance per trial
• Worst case judged
• Repeated after changes

13. Further references

• Method is standard engineering practice; for safety-rated functions follow the validation requirements of the applicable standards, which were not read for this page.

Related on FixTheRobot