A practical reading path
Robotics Architecture & Safety
Follow a robot command from AI planning to validated action, with reading paths for control, sensor confidence, timing, degraded modes and release evidence.
A robot combines processes that tolerate very different kinds of uncertainty. A language model can propose a task, a perception stack can estimate the world, and a controller must still act within the machine’s operating limits. Treating all three as interchangeable services obscures the boundaries that matter.
This reading path follows a command from an AI-facing interface to sensing and actuation. The articles support engineering decisions; a reading checklist alone does not establish the safety of a particular machine.
Start with the control hierarchy
Why LLMs Should Not Control Motors and Robots introduces the separation between task reasoning and actuator control. Continue with splitting authority between an LLM, ROS 2 and a microcontroller to assign responsibilities to concrete layers.
Bring a command-path diagram to the review. It should name the component that proposes an action, the component that checks it, the controller that executes it, and the mechanism that removes authority when assumptions fail.
Make each boundary answer a concrete question
| Design question | Reading path | Evidence to collect |
|---|---|---|
| Can an AI-facing process bypass validation? | Command validation for AI robot agents and ROS 2 security enclaves | Allowed interfaces and a test of prohibited publication paths. |
| What happens when commands or processes stop? | Robot Safety Architecture | Measured watchdog behavior and a documented stop path. |
| Is the observation usable when the command arrives? | Sensor confidence gates and sensor-to-actuator timing budgets | Timestamp meaning, age limits and timing measurements under load. |
| What can the machine still do after a fault? | Designing degraded modes | Entry conditions, retained authority and recovery rules for each mode. |
| Who can approve a proposed recovery? | Robot operator copilots | Separate advice, approval and command permissions. |
The middleware permission boundary and the physical stop path solve different problems. A deployment can have well-scoped ROS credentials and still respond incorrectly to stale sensor data or a failed power rail.
Use the ROS 2 latency budget calculator to allocate a sequential sensor-to-actuator path, compare observed stage maxima with their allocations, and export the record as CSV.
Choose control and communication deliberately
Use PID vs MPC in Robotics to examine tracking, coupling, constraints and prediction. For legged machines, how quadruped and humanoid robots stay balanced connects estimation, contacts and whole-body control.
For distributed sensors and actuators, read CAN Bus vs UART vs I2C vs SPI. Then use the robot communication bus decision worksheet to record the electrical interface, traffic assumptions and tests behind a choice. Selecting a familiar bus name is not a latency or reliability argument.
Turn assumptions into release evidence
The assumption ledger for Physical AI robots provides a place to record dependencies such as sensor freshness, localization quality and available braking behavior. Connect those assumptions to runtime assurance and autonomy release gates.
Start with one failure scenario: a delayed observation, a disconnected link or a restarted node. Record how it is detected, which authority is removed, what the machine does next, and how re-entry is allowed. Keep the test configuration and observed outcome with the decision.
Continue into deployment
Jetson & ROS 2 Engineering covers the compute, middleware and hardware integration work supporting this architecture. If an operator copilot also reaches enterprise data or business tools, use Enterprise AI Architecture & Governance for the corresponding identity and access boundaries.