The same governed loop — now between a robot's brain and its actuators.

Two capabilities

How the governor decides

Fail-safe by design: missing state or a critical breach stops the machine. Limits are commissioned per cell; teams set their own.

Notes & install guidelines

Prerequisites

• A running Robo8 instance (see the dashboard / one-command VM install).
• For inline action-gating on a robot: ROS 2 with rclpy, geometry_msgs, std_msgs. The gate logic itself runs without ROS (it's a pure function), so you can test it first.

A · Secure the estate (telemetry → ICS detection)

Feed robot/OT anomalies in — they normalise to ATT&CK-for-ICS and correlate like any source:

# one-click sample in the dashboard: Operations → "Robot/OT (ICS)"
curl -X POST localhost:8000/ingest \
  -H 'Authorization: Bearer <token>' -H 'Content-Type: application/json' \
  -d '{"records":[{"robot_id":"cell-7/arm-02",
        "signal":"Unauthorized command on control bus","severity":"high"}]}'

B · Gate an action (the governor API)

curl -X POST localhost:8000/governor/check \
  -H 'Authorization: Bearer <token>' -H 'Content-Type: application/json' \
  -d '{"action":{"kind":"move","speed_mps":2.0},
       "state":{"speed_mps":0.8,"nearest_human_m":0.4,"comms_age_s":0.1},
       "envelope":{"max_speed_mps":1.5,"min_human_distance_m":1.0}}'
# → {"decision":"block","recommended_action":"safe_stop", ... }

C · Inline gate on ROS 2 (the bridge)

Run the governor between the planner and the drive. Have the planner publish to a raw topic; the bridge republishes only safe commands to the real one, and a zero/stop Twist otherwise. Publish the robot's state as JSON on a state topic.

# Full ROS 2 package + TurtleBot3 Gazebo launch live under ros2/robo8_governor:
export TURTLEBOT3_MODEL=burger
ros2 launch robo8_governor governor_sim.launch.py   # Gazebo + state pub + governor
ros2 run turtlebot3_teleop teleop_keyboard --ros-args -r /cmd_vel:=/cmd_vel_raw
# (or the lightweight in-repo node:)  python -m robo8.ros2_bridge

# state message, e.g.:
ros2 topic pub /robo8/robot_state std_msgs/String \
  '{data: "{\"speed_mps\":0.8,\"nearest_human_m\":3.0,\"comms_age_s\":0.1}"}'

The ROS 2 topic graph

Two nodes ship in the robo8_governor package (ament_python). The governor is a pure interposer on the velocity stream; the state publisher turns raw sensors into the safety state the governor reasons over:

The interposer pattern means nothing downstream changes: remap your planner/teleop/Nav2 output to /cmd_vel_raw and the robot keeps driving /cmd_vel — it just can't receive an unsafe command.

Integrating with a real stack

• Nav2 / MoveIt — gate the controller's output (/cmd_vel for Nav2; the trajectory/servo command for MoveIt) the same way: planner → raw topic → governor → driver. The planner stays untouched; the governor is the last hop before hardware.
• QoS for safety — run the gate on a reliable, low-depth, volatile QoS profile so a stop is never silently dropped or replayed from a stale queue; match the driver's profile on the output side.
• Multi-robot fleets — one governor per robot under its namespace (/robotN/cmd_vel), each with its own commissioned envelope; decisions stream back to one Robo8 instance for fleet-wide audit and policy.
• Transport security (SROS 2 / DDS) — enable DDS Security (auth, encryption, access control) so command and state topics can't be spoofed or sniffed; the governor's fail-safe on stale/again-unsigned state is the backstop if they are.
• State source — the scan-based human proxy is a starting point; swap in a certified people-detector / safety scanner output on /robo8/robot_state and the governor contract is unchanged.

D · Prove it in simulation first

A headless harness drives realistic trajectories (human walking into the path, geofence drift, comms dropout) through the same gate and shows it halting before harm — no ROS or hardware needed:

python examples/sim_governor.py
#  human-into-path  [A A A A A A A A A X X X]  stopped@t9  · min human 0.5 m · no collision
#  geofence-breach  [A A A A X X X X]          stopped@t4  · no collision
#  comms-dropout    [A A A X X X X X]          stopped@t3  · no collision
#  A=allow  R=require-approval  X=block(+safe-stop)

The exact gate_command() exercised here is what runs in the ROS 2 node, so a green sim is a meaningful pre-flight before you point it at Gazebo / a TurtleBot and then a real cell. A Gazebo integration test is the next milestone.

Configuration

• Envelope — per-cell limits (max_speed_mps, min_human_distance_m, allowed_zones, comms_timeout_s, force/payload). Pass per request or set node defaults.
• Fail-safe — missing/partial state ⇒ block. Don't suppress it.
• Audit — every governor decision is written to the tamper-evident log and exposed in metrics (robo8_governor_decisions_total).
• Policies — operating-envelope rules sit alongside the policy-as-code posture checks; extend with your own.

Roadmap — where we build on Physical AI

Honest sequencing: harden what ships, then deepen perception and fleets, then earn the right to gate real-world action at certification grade. The invariant across every phase — the governor can get smarter, but it can never widen the safety envelope.

Full detail in docs/roadmap-physical-ai.md and the strategy in docs/vision-physical-ai.md. Dates indicative; safety milestones gate on evidence, not calendar.

Why it's the same bet, higher stakes

Robo8's thesis has always been governed, explainable, sovereign autonomy. Cyber defence came first because the data is available and the blast radius is contained. Physical AI is the same loop where the stakes — and therefore the value of glass-box, bounded, audited autonomy — are highest. Same loop, same trust primitives, higher consequence.