Physical AI & Robotics · architecture
Target architecture
One modular stack, not a collection of demos. Probabilistic layers propose; deterministic layers refuse. The column “today” says where each layer exists — or that it does not.
- PERCEIVE
- MODEL
- PLAN
- ACT
- VERIFY
- RECOVER
- LEARN
Stack
| Layer | Nature | Role | Today |
|---|---|---|---|
| 01 Perception | probabilistic — may propose | Sensor fusion, detection, tracking, uncertainty. | robot-lidar-fusion 0.4.0 (projection, calibration, occlusion). |
| 02 World model | probabilistic — may propose | Scene state, object poses, pallet state, uncertainty over both. | Pallet state in palletizer planning; scene model not built. |
| 03 Task planner | probabilistic — may propose | Order sequencing, pattern selection, mixed-SKU placement. | palletizer optimizer, MissionPlanner, PatternManager. |
| 04 Motion planner | probabilistic — may propose | Collision-free trajectories for the chosen placement. | MotionController tests exist; no planner benchmark. |
| 05 Simulator | deterministic — may refuse | Executes the plan in physics before any actuator moves. | core/simulation and browser Rapier demos; KPI harness pending. |
| 06 Safety / constraint engine | deterministic — may refuse | Refuses anything outside limits. Cannot be argued with by a model. | HazardManager, FaultDetector; authorisation boundary by contract with NeuralBridge. |
| 07 Robot controller | deterministic — may refuse | Vendor SDK or ROS 2 driver behind the RobotInterface. | RobotInterface abstraction; ROS 2 bridge examples; no certified vendor driver. |
| 08 Actuation | physical | Arm, gripper, conveyor. | None owned. Simulation first. |
| 09 Telemetry | telemetry | Every cycle, fault and intervention as a typed event. | CommunicationInterface publishes telemetry; KPI schema on /palletizer. |
| 10 Failure analysis | telemetry | Classify every failed pick and intervention by cause. | Not built. |
| 11 Learning | probabilistic — may propose | Improve planners from telemetry; never touch safety limits. | Not built. Research program on /research. |
Safety gate
Every physical action passes all six steps. A model may participate in PLAN; from SIMULATE onwards the steps are deterministic and the model has no say. Authorisation is a human or a certified runtime, recorded with provenance. No LLM or learned model may bypass safety controls, command an unrestricted actuator, modify a safety limit without authorisation, or silently modify production behaviour.
- PLAN
- SIMULATE
- VALIDATE
- AUTHORIZE
- EXECUTE
- VERIFY
| Agent tool | Allowed | Note |
|---|---|---|
generate_plan | yes | Propose a pallet plan or inspection plan. Output is a candidate, not a command. |
analyze_scene | yes | Read perception output and describe it. |
propose_action | yes | Enter the gate at PLAN. Nothing after VALIDATE is reachable from here. |
retrieve_procedure | yes | Look up a documented procedure. |
diagnose_failure | yes | Explain a failed pick or intervention from telemetry. |
optimize_schedule | yes | Re-order work; the result is validated before it is scheduled. |
generate_simulation_scenario | yes | Create test scenarios for the simulator. |
command_actuator | no | Never. Actuators are reached only through the gate after AUTHORIZE. |
modify_safety_limit | no | Never without human authorisation recorded in the decision log. |
modify_production_behavior | no | Never silently. Every change is an authorised, logged deployment. |
bypass_gate | no | Does not exist as a tool. Absence is the control. |
Every allowed tool carries a schema, authentication, authorisation, deterministic validation, a timeout, provenance, logging, failure behaviour and test coverage. A tool missing one of these is not deployed.
Robot-agnostic by evidence
Abstraction has a cost. An abstraction is written only if it passes at least two of four tests:
- Multiple deployments need it.
- It reduces integration time.
- It reduces vendor dependence.
- It creates a defensible platform capability.
| Candidate | Tests passed | Position |
|---|---|---|
| Robot arms | 3 / 4 | RobotInterface exists. Vendor dependence reduced only once two drivers exist. |
| Grippers | 2 / 4 | GripperController exists; second gripper type not yet needed. |
| Cameras | 1 / 4 | Single intrinsics model. Do not abstract further yet. |
| LiDAR | 3 / 4 | Shared across palletizing and inspection — robot-lidar-fusion is the abstraction. |
| Force sensors | 0 / 4 | No deployment needs it. Not abstracted. |
| PLCs | 1 / 4 | Only when a customer cell requires an interlock handshake. |
| Safety systems | 4 / 4 | One authorisation boundary, by contract. The only abstraction that is mandatory. |
| Conveyors | 1 / 4 | Not abstracted until a second conveyor type appears. |
| End effectors | 2 / 4 | Folded into the gripper abstraction for now. |