Emergency stop: a latch that never releases itself

The problem an e-stop has to solve#

An emergency stop that releases when the button is let go is not an emergency stop. The classic failure: the operator presses the mushroom button while holding the stick forward, the drives stop, the operator releases the button to reach for something — and the vehicle resumes immediately, because the stick is still forward. The mechanical mushroom button on IGNIS-8 latches and must be twisted to release. The software mirrors that behaviour, and then goes further.

There is a second, less obvious failure that the software has to handle: where the stop lives. The operator terminal is a browser on a handheld. If the emergency stop lived only in the terminal, a dead terminal — a crashed browser, a switched-off handheld, a dead radio link — would stop nothing. The terminal is shouting into a void. The vehicle needs its own decision-making, independent of the terminal, so that it can stop itself when the operator can no longer reach it at all.

That is why the current design has two latches instead of one: a terminal latch that reacts instantly to the operator, and a vehicle latch that survives everything on the terminal side.

Three independent stop mechanisms#

The e-stop is only one of three independent mechanisms, and they are deliberately built to fail differently — no single failure takes out all of them:

Mechanism	Triggers on	Fails if
Emergency stop latch (terminal + vehicle)	Operator intent, battery faults	Terminal itself is dead
Worker stale detection	Main thread blocked (> 120 ms)	Worker itself is dead
Vehicle watchdog	Command stream ceases (150 ms)	Vehicle software is dead

The vehicle watchdog is the backstop: radio loss, terminal crash, closed browser tab, pulled cable — all produce the same observable condition at the vehicle: no more commands. The watchdog does not care which of those occurred.

Why the vehicle needs its own latch#

The watchdog alone is not enough. It is undebounced and clears as soon as a fresh command arrives — which is correct for its job, but wrong for an e-stop. Consider a persistent fault: the battery reports an overcurrent. The watchdog would let the vehicle drive again as soon as the next command tick arrived, because nothing tells it why the stop happened.

The vehicle therefore runs its own e-stop latch in SystemState, independent of the watchdog. Any trigger source latches it via TriggerEstop, and it stays latched until the acknowledged release path clears it. The release is evaluated backend-side in GetKinematicInput and requires all three of:

• a release source held for EstopReleaseHold (800 ms), and
• the drive setpoints neutral, and
• no trigger source still demanding a stop.

That last condition is the no-automatic-reset rule. The release cannot outvote an active cause: if the battery is still overcurrent, holding the release button changes nothing. Fix the cause, then acknowledge manually. This is what makes the difference between a latch and a mere flag.

One latch, many trigger sources#

Every source that can decide “this vehicle must not move” feeds the same latch. Today these are:

• Discharge overcurrent (current below -DischargeErrA)
• Charge overcurrent (current above ChargeErrA)
• Pack voltage outside the 18.0–25.2 V window
• Any cell outside the 2.5–4.25 V window
• Battery temperature below 0 °C or above 50 °C
• HMI e-stop button (estop_trigger = "hmi_button")
• HMI mushroom module, F24 (estop_trigger = "hmi_f24")
• Robot hardware e-stop — the wiring point is reserved, not yet wired

The battery sources are evaluated in the BMS task via the shared estopTriggersActive(state) function; the HMI sources reach the vehicle over the control WebSocket as estop_trigger, set by latchEstop in gamepad.js and carried by control_worker.js. A non-empty value latches the vehicle e-stop immediately; clearing it alone never unlatches it.

Every source also appears as a status box in the HMI's e-stop drawer: green when nominal, yellow when outside the warning window, red and blinking when it has crossed the error bound. The HMI never derives a threshold — it only displays what the backend evaluated, so the drawer and the latch cannot disagree.

Why the stop is selective, not total#

An emergency stop on a reconnaissance vehicle has an unusual requirement: it must stop the drive, but not necessarily the mission instruments. IGNIS-8 exists to inspect battery hazards from a safe distance — exactly the situation where the operator most needs a live view of the surroundings.

The design therefore releases only the drive and steering channel. The kinematics input is forced to zeros; drive torque is withheld; steering setpoints are zeroed. Everything that does not move the vehicle stays live:

• Camera gimbal — pitch and yaw remain fully operable (D-pad, arrow keys, recenter). The gimbal does not move the vehicle, so it is safe to use, and a view of what went wrong is worth more than a frozen head.
• Sensors and streams — thermal camera, LiDAR, video, telemetry all keep reporting.

This was a deliberate decision, not an oversight. Freezing the gimbal during a fault would remove information at exactly the moment it matters most. The safety analysis documented in docs/safety.md calls this out explicitly: during a fault the view of the surroundings is more valuable than usual.

Advantages of the current design#

• No automatic reset anywhere. Both latches require a deliberate, held acknowledgement with the controls at rest. A momentary stray press of the release cannot clear anything, and a persistent fault holds the vehicle stopped until it is actually fixed.
• Survives a dead link. Because the vehicle latches independently, a dead terminal, a crashed browser or a lost radio link leaves the vehicle holding its stop — the terminal latch alone could not do that.
• Sources the latch, not the operator. Battery faults latch the vehicle without any operator involvement, and the HMI cannot re-arm the vehicle while a cause is still active.
• Single evaluation, single truth. estopTriggersActive is shared by the BMS task (latching) and the release logic (blocking), so both sides see the same conditions by construction.
• Per-source visibility. The drawer shows which source tripped and how far outside its window it is — the operator diagnoses instead of guessing.
• Selective stop. The gimbal and sensors stay live, which is the entire point of a reconnaissance platform.
• Warning is decoupled from stopping. Warning levels colour boxes yellow but never trigger the e-stop, so the operator is informed early without the vehicle stopping on every excursion.

Disadvantages and honest limits#

• The e-stop is not faster than the watchdog when the link is down. If the radio is already dead, the mushroom button changes nothing at the vehicle — the terminal is shouting into a void, and the vehicle's own watchdog is the backstop. For a ~1.3 km/h, 20–35 kg vehicle that is acceptable; for anything faster or heavier it would need an independent radio kill channel.
• Two latches to keep consistent. The terminal latch and the vehicle latch must agree on the release rule. Today both use the same 800 ms hold + neutral + no-trigger logic, but the duplication is a real maintenance surface — a change to one must be mirrored in the other.
• No braking. All three mechanisms remove torque; none brakes. The vehicle free-wheels and can still move on a slope. This is a deliberate omission — active braking through the drive motors would need a controlled deceleration ramp, and an uncontrolled one could tip a vehicle whose centre of mass sits above the wheel axes.
• Not a certified safety system. There is no ISO 13849 Performance Level and no IEC 61508 SIL rating. These are engineering measures for a remotely operated research vehicle, proportionate to its energy and environment — not a substitute for a rated safety chain.
• Simulated sources stay advisory. A simulated LiDAR tilt is never allowed to latch the drive e-stop — it would stop the vehicle on a synthetic slope. Sensor-based triggers like tip-over therefore remain display-level until real hardware confirms them.
• The robot hardware e-stop is not wired yet. The source, the drawer box and the release input exist, but the physical connection on the robot is still to be built.

What the operator sees#

The HMI's e-stop drawer renders the whole picture as a mindmap: trigger sources on the left, the latch state in the centre, release sources on the right. Current, voltage and temperature are combined boxes with the live value on the left and the warn/error limits on the right; cells, the HMI button, the F24 source and the robot input are single boxes. A fault blinks red; the centre box reads LATCHED with the instruction “hold reset to clear”.

Release comes from the same place as the latch: the e-stop module's reset button (F23) or the Enter key, held with the controls released. The gamepad START button is deliberately not mapped to the release — the release belongs on the same module as the latch, not on a stray gamepad press.

Status and next steps#

The current trigger set covers the battery faults that motivated the e-stop in the first place, plus the operator-side triggers. Still on the list, recorded in the project notes:

• Motor temperature as a hard trigger (source field already exists in telemetry)
• Cell-to-cell delta (unbalance) as a hard trigger
• Tip-over from the LiDAR IMU — as a hard trigger only once real hardware confirms the attitude, otherwise warning-only
• SBC/board temperature and Wi-Fi loss as warnings rather than e-stop sources
• Wiring the robot-side hardware e-stop input

The short version: the e-stop is implemented the way it is because a stop that clears by itself is not a stop, and because on a remotely operated vehicle the stop must survive the link dying. The price is two latches to keep consistent, no braking, and an honest ceiling — this is engineering, not certification. In exchange the vehicle gets a stop that holds until the cause is gone, per-source visibility of what tripped it, and a camera that keeps looking at exactly the moment the operator most needs eyes.