Skip to content

Conversation

@jimsynz
Copy link
Contributor

@jimsynz jimsynz commented Dec 13, 2025

Summary

Introduces a global safety controller that manages arm/disarm state for all robots on the node:

  • BB.Safety behaviour with disarm/1 callback for hardware shutdown
  • BB.Safety.Controller GenServer in BB's application supervision tree
  • Error state handling - if disarm callbacks fail, robot enters :error state and cannot arm until force_disarm/1 is called
  • Runtime verification - checks all BB.Safety implementers have registered on startup
  • Comprehensive documentation explaining BEAM's soft real-time limitations and hardware kill switch recommendations

Safety States

State Description
:disarmed Robot safely disarmed, all callbacks succeeded
:armed Robot armed and ready to operate
:error Disarm attempted but callbacks failed; hardware may not be safe

Architecture

  • Two ETS tables: protected robots table (state), public handlers table (registration)
  • Handler registration writes directly to ETS to avoid mailbox bottleneck
  • Safety state changes go through GenServer to ensure callbacks are triggered
  • High scheduler priority for the safety controller

Files Changed

  • lib/bb/safety.ex - Behaviour + API
  • lib/bb/safety/controller.ex - Global GenServer
  • lib/bb/application.ex - Application supervision tree
  • lib/bb/robot/runtime.ex - Integration with runtime state machine
  • lib/bb/command/arm.ex / disarm.ex - Updated to use BB.Safety
  • documentation/topics/safety.md - Safety documentation

Test plan

  • All existing tests pass (457 tests, 0 failures)
  • mix check --no-retry passes (formatter, credo, dialyzer, reuse)
  • Manual testing of arm/disarm lifecycle
  • Test error state by implementing a failing disarm callback
  • Verify force_disarm/1 resets error state

Introduces a global safety controller that manages arm/disarm state for all
robots on the node. Key features:

- BB.Safety behaviour with `disarm/1` callback for hardware shutdown
- BB.Safety.Controller GenServer in BB's application supervision tree
- Two ETS tables: protected robots table, public handlers table
- Handler registration writes directly to ETS (avoids mailbox bottleneck)
- Safety state changes go through GenServer to ensure callbacks are triggered
- Error state when disarm callbacks fail - robot cannot arm until force_disarm/1
- Runtime startup verification that all BB.Safety implementers are registered
- Comprehensive safety documentation explaining BEAM limitations and
  hardware kill switch recommendations

Safety states:
- :disarmed - Robot safely disarmed, all callbacks succeeded
- :armed - Robot armed and ready to operate
- :error - Disarm failed, hardware may not be safe

The software safety system provides best-effort safety management but is not
suitable for safety-critical applications. Hardware safety controls are
recommended for any system where actuator failures could cause harm.
- Run disarm callbacks concurrently with `Task.async_stream` (5s timeout)
- Add `:disarming` state to reject commands while callbacks are running
- Add `disarming?/1` for fast ETS reads of disarming state
- Add `terminate/2` callback for emergency disarm on shutdown
- Add tests for error state, `force_disarm/1`, timeouts, and transitions
…E.md

- Extract `emergency_disarm_robot/1` to fix credo nesting depth warning
- Add Safety System section to CLAUDE.md referencing documentation/topics/safety.md
- Add safety pattern note to Key Patterns section
@jimsynz jimsynz merged commit 6075934 into main Dec 13, 2025
14 checks passed
@jimsynz jimsynz deleted the feature/safety-controller branch December 13, 2025 23:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants