Chapter 1: Where Does a Robot Policy Run? — From Planner to Motor Loop

Overview

A robot policy is not the whole robot. It is one bounded proposal-making component in a layered execution stack. Between “look through the camera and choose the next action” and “drive the motor stably and on time” lie task and skill selection, motion generation, low-level control, a real-time interface, and independent safety authority. This chapter places those layers on one map and builds a record of each loop's owner, rate, clock, deadline, and failure action.

The goal is not to select one framework. The reader first produces an execution contract into which the classical baseline of Chapter 2, the learned policies of Chapters 5–7, and the hybrid stack of Chapter 8 can all fit.

Learning goals and experiment question

By the end of this chapter: you should be able to draw the execution and authority hierarchy and turn every loop's timing and failure behavior into a testable artifact.

By the end of this chapter, you should be able to:

1. draw the downward path of commands from task intent to actuators and the upward path of state and failure;
2. separate the authority of planners, policies, controllers, hardware interfaces, and the safety supervisor;
3. record the owner, nominal rate, clock, deadline, watchdog, and failure action of every loop;
4. compare classical and learned methods as different insertion points rather than wholesale replacements; and
5. trace one tabletop-assembly request from proposal to a bounded hardware command.

Experiment question: When the system receives “grasp this part, transport it, and insert it into the fixture,” which process decides what, against which timestamp is the decision still valid, and what causes a transition to hold, replan, or abort?

1.1 Draw the authority map first

1.1.1 Six layers and one layer watching from the side

This book uses the following execution stack.

Task / intent
  FSM · behavior tree · task planner · future VLA/world-model/agent layer
                         ↓ bounded skill request
Skill / action policy
  scripted primitive · BC/ACT · diffusion/flow · RL policy
                         ↓ action proposal + validity metadata
Motion generation
  IK · collision-aware planning · trajectory optimization · MPC
                         ↓ feasible path/trajectory/reference
Low-level control
  trajectory · position/velocity/torque · impedance/admittance/force control
                         ↓ time-bounded setpoint
Real-time interface / robot controller
  ros2_control hardware interface · vendor real-time API/controller
                         ↓ actuator command
Robot · gripper/hand · sensors

Independent safety supervisor
  limits · collision/force gate · watchdog · stop/fallback authority
  └──────── observes and restricts authority across every layer ────────┘

The downward arrows mean more than message forwarding. Representation and authority narrow at every step. “Insert the part” becomes skill requests such as “move to approach pose,” “search for contact,” and “advance along the insertion axis.” A Cartesian delta or action chunk proposed by a skill policy passes through joint, workspace, collision, and force constraints before it becomes a trajectory or controller reference. Joint state, camera and force observations, tracking error, timeout, and protective-stop state flow upward.

This separation retains a central lesson from classical robotics. Differential kinematics made the layer that maps task-space motion to joint motion explicit[1], while operational-space formulations exposed the control responsibilities between motion or force objectives and robot dynamics[2]. This chapter does not claim that either method transfers unchanged to every arm. Singularities, saturation, delay, sampling, collision handling, and hardware modes still require the validation developed in Chapters 2 and 3.

1.1.2 Use a narrow definition of policy

A policy is a rule that consumes an observation and produces an action proposal. That definition includes scripted primitives, behavior cloning, ACT, diffusion or flow policies, and RL policies. The following components are not interchangeable with a policy:

• The task layer decides which skill to invoke and when.
• Motion generation transforms a proposed target into an executable path under kinematic, collision, and timing constraints.
• A low-level controller reduces reference error in a faster loop or shapes contact dynamics.
• The real-time interface exchanges command and state with the robot controller and handles deadline violations.
• The safety supervisor must be able to restrict motion authority and trigger stop or fallback even when an upstream proposal is wrong.

This narrower vocabulary prevents “the model outputs an action” from overstating deployment authority. A policy output is a timestamped proposal with a validity envelope, not an actuator command.

1.2 Inputs, outputs, and completion evidence by layer

The key question is not only “who computes this?” but “who owns authority and failure handling?” One process may perform several computations, but collapsing task success and a motor deadline into one Boolean makes diagnosis ambiguous. The enduring engineering value of the OROCOS and ros_control lines is not a framework name; it is the explicit separation of components, controllers, and hardware interfaces[3,4]. A current deployment must still confirm that separation in the selected driver and controller configuration.

1.3 ROS 2 is an integration backbone, not necessarily every motor loop

ROS 2 can connect planning, state, policy, and lifecycle components, but the owner and timing of a motor-level loop remain platform- and driver-specific. [10,14,15] This statement is bounded by the inspected ros2_control, libfranka, and UR ROS 2 driver records; it does not establish one universal robot architecture. Treat the arm firmware, vendor controller, driver, OS, and command mode as one compatibility unit.

ros2_control provides an architecture in which a controller manager coordinates hardware components around a read → update → write boundary[10]. A configured update rate, however, is not automatically a hard real-time guarantee for every path. OS scheduling, hardware plugins, controller execution time, transport, and vendor-side loops all matter. Franka's direct SDK and the UR driver impose different host real-time and version-compatibility conditions[14,15]. Do not erase those differences behind a single “ROS 2 frequency.”

MoveIt move_group consumes robot state and submits trajectories through a controller action interface; it is not itself the hardware action server. [5] The planning scene is another input, and move_group is not the joint-state publisher. Planning success, controller acceptance, and tracking success are therefore separate gates.

A collision-free path can still fail downstream because:

• time parameterization is absent or unsupported by the controller;
• the joint trajectory controller expects command/state interfaces that the hardware does not export[12];
• vendor safety scaling makes wall-clock progress differ from trajectory time[13];
• the planning scene state or geometry is stale[5]; or
• MoveIt Servo collision or singularity scaling reduces motion but does not replace a certified safety function[6].

For that reason, do not record “plan succeeded” as “robot safely completed.” Keep planned, accepted, executing, tracked, task_succeeded, and stopped as distinct states.

1.4 Write a timing contract instead of one frequency

Command paths should record loop owner, update-rate source, event and arrival clocks, deadline, and failure action rather than presenting one generic frequency. [8,11,16] The cited official pages expose configured rates and diagnostics; they do not provide a cross-platform hard-real-time guarantee. Measure worst-case latency and jitter under the selected hardware and workload.

1.4.1 Minimum timing matrix

The table below contains fields to fill, not numerical defaults. All hardware-relevant TBD entries must be resolved before motion.

ROS 2 topic statistics help observe transport, but they are not proof of a motor deadline[8]. In simulation, publish rate can depend on rendering or GPU load and simulation-clock configuration. Topic visibility alone does not establish timestamp correctness or deterministic delivery[16]. A lifecycle state machine can organize startup and shutdown without certifying that a transition is safe[9].

1.4.2 Separate three notions of time

1. Event time is when a sensor exposure or robot state was physically sampled.
2. Arrival time is when the message reached its consumer.
3. Decision/execution time covers when the policy used the observation and the interval in which its command remains valid.

arrival - event is only part of age; inference, queuing, networking, and controller buffering add more. Use a monotonic or steady clock for latency if wall time may be adjusted. Store offset, drift, and uncertainty between sensor or robot clocks and host clocks. When converting between clock domains, record the conversion identifier and calibration epoch.

1.5 Where classical and learned models enter

The explicit-versus-implicit taxonomy is useful as a map, but it does not remove the distinctions among task selection, motion generation, low-level control, and safety authority. Capuano et al.'s organization supplies that first map for robot learning[18]. It is primary evidence for the tutorial authors' teaching organization, while the hierarchy in this chapter is an independent S12 synthesis. Classical operational-space control[2] and language-conditioned program proposals[19], for example, still require different execution interfaces.

Starting with a classical spine does not exclude learning. It creates a baseline in which failures can be localized. You need to know whether the planner failed, a policy proposal became stale, a controller rejected a trajectory, or a contact gate stopped execution before you can measure the contribution of a new model.

1.6 Independent safety and fallback authority

The S12 design requirement is: A safety supervisor, hardware limits, collision/force gates, and watchdog authority must remain independent of a learned policy proposal. This is a design rule, not a universal certification claim. The current claim packet is insufficient to finalize hardware prose for every cell: actual deployment must resolve applicable standards, the cell risk assessment, vendor safety manuals, and a validated stop path[11,17,18].

A software-limit clamp, planning collision check, and model confidence can each be useful without being synonymous with a certified safety function. Controller-manager fallback also depends on available interfaces and prior validation[11]. The minimum supervisor contract is consequently kept separate from the performance path:

• Hold and stop paths work even when the policy is absent.
• Killing the policy process or disconnecting the network exercises the watchdog.
• Stale, NaN, out-of-range, wrong-frame, and wrong-version actions are rejected.
• Collision, force, workspace, and reset events are written to a separate audit log.
• Fallback and recovery are validated in the relevant hardware mode, not inferred from mock behavior alone.
• Human operators own release from E-stop or protective stop; a learned model does not approve reset.

1.7 Worked interface example: trace one tabletop insertion

This is an interface audit, not a numerical performance result. The system is a 6/7-DoF arm with a parallel gripper and wrist/scene cameras performing tabletop assembly.

Step 1 — Task request

An FSM emits insert(part=A, fixture=B, task_state=v37). Preconditions include fresh object pose, known gripper state, a clear workspace, and an active controller. There is no motor command in this request.

Step 2 — Skill proposal

A classical primitive or learned policy proposes approach → grasp → transport → contact_search → insert, with an action-schema version for each skill. A learned chunk additionally carries observation event time, policy/checkpoint ID, inference-completion time, horizon, and valid_until.

Step 3 — Motion generation

For free space, a collision-aware planner creates a geometric path and trajectory processing adds timing. As the official MoveIt documentation cautions, jerk bounds and vendor acceptance remain separate checks[7]. The contact phase switches to the constrained reference and impedance/force mode validated in Chapter 3.

Step 4 — Controller acceptance

The trajectory is submitted through an interface that exposes acceptance, result, and tolerance behavior[12]. If the controller rejects it, the policy does not respond by sending a stronger command. The system diagnoses mode, interface, start state, and timing, after which the task executive replans or aborts.

Step 5 — Execution and monitoring

The controller owner maintains the tracking loop. The safety owner monitors limit, collision/force, and watchdog events. The task layer observes progress without taking over the motor loop. This chapter does not invent contact-force thresholds or stop categories; they come from the cell's validated configuration.

Step 6 — Completion or failure

Success is not one done=true. Record the trajectory result, final pose tolerance, insertion/contact criterion, gripper and object state, absence or presence of safety events, and observation freshness. On failure, preserve raw, mapped, and sent actions together with controller and safety state for the Chapter 4 dataset schema and Chapter 9 promotion record.

1.8 Minimal reproducible workflow and validation gates

Gate 0 — Confirm the S11 handoff

Reconfirm, rather than copy, the packet/loop contract from S11 Chapter 8 and the asset–calibration–controller tuple from S11 Chapter 9. Stop here if joint limits, the collision model, E-stop and watchdog, frame/time synchronization, or command-mode ownership are undocumented. S11 is not yet release-ready, so it remains continuity input rather than a public link.

Gate 1 — Build a read-only graph

Without moving the robot, inventory processes/nodes, topics/actions/services, controllers, hardware interfaces, and clock domains. Attach schema/version and owner to every edge. Configuration linting and a mock interface can verify structure without a device connection.

Gate 2 — Replay recorded state

Replay recorded observations to the policy and planner while blocking actuator writes. Inject stale timestamps, frame mismatch, dropped messages, and duplicate or reordered actions. The expected result is rejection of an unsafe proposal with an explicit reason.

Gate 3 — Simulation and shadow

Run a simulation regression with the same task, action, and controller contract. Then read real sensors and state in shadow mode without sending commands. Measure age, jitter, compute time, and constraint-rejection rate. Do not substitute simulator topic rate for a hardware deadline[16].

Gate 4 — Bounded hardware trial

Proceed only under validated low-speed, small-workspace, supervised conditions and the cell-specific safety configuration. Failure actions for network loss, policy timeout, controller rejection, and safety events must already be tested. This gate checks authority boundaries before it tries to maximize task success.

1.9 Failure symptoms and diagnosis order

The diagnosis principle is to read the downstream rejection reason before generating more upstream actions. MoveIt Servo scaling and controller holding behavior are not safety certification and remain hardware-implementation dependent[6,12].

1.10 A bounded implementation prompt for Codex

The prompt below authorizes an execution contract and validator, not robot motion.

Goal
- Implement an owner/rate/clock/deadline/watchdog/failure-action matrix and a
  read-only validator for this repository's tabletop-assembly command path.

Context
- Robot: <model/firmware>; controller: <name/version>; ROS 2: <distribution>;
  MoveIt/ros2_control/vendor driver: <pinned versions>.
- Inputs: current launch/config files, interface inventory, recorded rosbag,
  and vendor manuals.
- This task does not authorize hardware motion.

Constraints
- Separate Task, Policy, Motion Generation, Low-Level Control, Real-Time
  Interface, Robot, and independent Safety owners.
- Record event, arrival, and decision clocks plus clock-domain conversions.
- Do not guess rates; distinguish configured sources from measured diagnostics.
- Reject stale, NaN, out-of-range, wrong-frame, and wrong-version actions.
- Do not modify or bypass existing E-stop, protective-stop, limit, or watchdog paths.

Done when
- A versioned YAML/JSON contract and schema tests exist.
- Every command/state edge has an owner, schema, clock, deadline, and failure action.
- Recorded-state replay passes stale, drop, reorder, and timeout injection tests.
- The report marks unknown/TBD fields as fail-closed.
- Reproduction commands, the diff, and residual risks are documented.

Safety
- Lock actuator writes to a mock or disabled adapter.
- Hardware trials, controller switching, and gain/limit changes require a separate task.
- An LLM or policy has no torque, safety-reset, or E-stop-release authority.

1.11 Artifacts and metrics to retain

Required artifacts

• execution-hierarchy diagram and process/node inventory;
• versioned command/state interface schema;
• owner/rate/clock/deadline/watchdog/failure matrix;
• controller-mode and hardware-interface compatibility table;
• manifest of policy/checkpoint, robot model, calibration epoch, and task-state version;
• stale/drop/reorder/timeout fault-injection log;
• replay, simulation, shadow, and bounded-hardware promotion records; and
• an audit log that separates safety events from human reset actions.

Minimum metrics

• sensor-to-decision age distribution;
• inference, planning, transport, and controller-acceptance latency separately;
• loop overruns and missed deadlines;
• stale, reordered, and dropped proposals;
• constraint projection/rejection and fallback counts;
• controller reject/abort and tracking-error events;
• collision, force, watchdog, and protective-stop events; and
• task success, recovery, and human intervention as separate outcomes.

Do not preserve only a mean. Tail behavior, the failure timestamp, and the task, scene, policy, and controller versions are needed for reproducibility and comparison.

1.12 Boundary to the next chapter and volume

Detailed VLA, world-model, and agentic-policy comparisons belong to S13; S12 defines only the bounded skill/action interface they must obey. This is an editorial boundary, not a model-performance claim[18]. Open X-Embodiment and Octo are seeds for the S13 source map; this chapter makes no numerical or universal capability claim about them.

Chapter 2 now uses this common map to develop the default for structured free-space motion: FK/IK, collision-aware planning, the difference between a path and a trajectory, and time parameterization. Chapter 3 takes over when that trajectory enters contact and needs impedance, admittance, or force control. Policies may change later in the book; the owner, time, deadline, watchdog, and fallback contracts built here remain.

References

1. Whitney, D. E. (1969). Resolved Motion Rate Control of Manipulators and Human Prostheses. IEEE Transactions on Man-Machine Systems. https://doi.org/10.1109/TMMS.1969.299896
2. Khatib, O. (1987). A Unified Approach for Motion and Force Control of Robot Manipulators: The Operational Space Formulation. IEEE Journal on Robotics and Automation. https://doi.org/10.1109/JRA.1987.1087068
3. Bruyninckx, H. (2001). Open Robot Control Software: The OROCOS Project. Proceedings of IEEE ICRA 2001. DOI: 10.1109/ROBOT.2001.933002.
4. Chitta, S., Marder-Eppstein, E., Meeussen, W., Pradeep, V., Rodriguez Tsouroukdissian, A., Bohren, J., Coleman, D., Magyar, B., Raiola, G., Lüdtke, M., & Fernández Perdomo, E. (2017). ros_control: A generic and simple control framework for ROS. Journal of Open Source Software. https://doi.org/10.21105/joss.00456
5. MoveIt / PickNik. (2025). MoveIt 2 move_group Architecture. https://moveit.picknik.ai/main/doc/concepts/move_group.html
6. MoveIt / PickNik. (2025). MoveIt Servo Realtime Teleoperation Tutorial. https://moveit.picknik.ai/main/doc/examples/realtime_servo/realtime_servo_tutorial.html
7. MoveIt / PickNik. (2025). MoveIt 2 Trajectory Processing. https://moveit.picknik.ai/main/doc/concepts/trajectory_processing.html
8. Open Robotics. (2026). ROS 2 Jazzy Interfaces: Topics, Services, and Actions. https://docs.ros.org/en/jazzy/How-To-Guides/Topics-Services-Actions.html
9. Open Robotics. (2026). ROS 2 Jazzy Managed Node Lifecycle. https://docs.ros.org/en/jazzy/p/lifecycle/index.html
10. ros-controls. (2026). ros2_control Jazzy Architecture and Getting Started. https://control.ros.org/jazzy/doc/getting_started/getting_started.html
11. ros-controls. (2026). ros2_control Controller Manager Monitoring and Limits. https://control.ros.org/master/doc/ros2_control/controller_manager/doc/userdoc.html
12. ros-controls. (2026). ros2_control Joint Trajectory Controller Jazzy. https://control.ros.org/jazzy/doc/ros2_controllers/joint_trajectory_controller/doc/userdoc.html
13. Universal Robots. (2026). UR ROS 2 Controllers and Speed Scaling. https://docs.universal-robots.com/Universal_Robots_ROS_Documentation/doc/ur_robot_driver/ur_controllers/doc/index.html
14. Universal Robots. (2026). UR ROS 2 Driver Installation and Real-Time Guidance. https://docs.universal-robots.com/Universal_Robots_ROS2_Documentation/doc/ur_robot_driver/ur_robot_driver/doc/installation/installation.html
15. Franka Robotics. (2026). libfranka Changelog and Packaging through 0.20.x. https://github.com/frankarobotics/libfranka/blob/main/CHANGELOG.md
16. NVIDIA. (2026). Isaac Sim ROS 2 FAQ: Time and Topic Visibility. https://docs.isaacsim.omniverse.nvidia.com/latest/ros2_tutorials/ros2_faq.html
17. Lasota, P. A., Fong, T., & Shah, J. A. (2017). A Survey of Methods for Safe Human-Robot Interaction. Foundations and Trends in Robotics. https://doi.org/10.1561/2300000052
18. Capuano, F., Pascal, C., Zouitine, A., Wolf, T., & Aractingi, M. (2025). Robot Learning: A Tutorial. arXiv:2510.12403v1. https://doi.org/10.48550/arXiv.2510.12403
19. Liang, J., Huang, W., Xia, F., Xu, P., Hausman, K., Ichter, B., Florence, P., & Zeng, A. (2023). Code as Policies: Language Model Programs for Embodied Control. IEEE ICRA. arXiv:2209.07753.
20. Herman Bruyninckx (2001). The OROCOS project: Flexible toolchain for robot control. Annotated primary reading. DOI: 10.1109/robot.2001.932879. — Role: primary reading for execution, communication, and timing ownership. Limitation: The assumptions and evaluation setup are source-specific; current implementation claims require maintained official evidence.
21. Sami Haddadin et al. (2012). Human-Robot Collision Evaluation and Analysis. Annotated primary reading. DOI: 10.1007/978-3-642-40308-8. — Role: primary reading for execution, communication, and timing ownership. Limitation: Biomechanical thresholds and apparatus do not substitute for applicable standards or application risk assessment.
22. Yuya Maruyama et al. (2016). The Robot Operating System 2: Design, architecture, and uses in the wild. Annotated primary reading. DOI: 10.1109/SII.2016.7847304. — Role: primary reading for execution, communication, and timing ownership. Limitation: Early ROS 2 prototype results predate current executors, RMW implementations, and distributions.
23. Daniel Casini et al. (2019). Response-Time Analysis of ROS 2 Processing Chains under Reservation-Based Scheduling. Annotated primary reading. DOI: 10.4230/LIPIcs.ECRTS.2019.6. — Role: primary reading for execution, communication, and timing ownership. Limitation: Assumptions about callback execution and scheduler reservations must hold on the deployed kernel and executor.
24. Ruoxuan Feng et al. (2025). AnyTouch: Learning Unified Static-Dynamic Representation across Multiple Visuo-Tactile Sensors. Annotated primary reading. arXiv:2502.12191. — Role: primary reading for execution, communication, and timing ownership. Limitation: Platform, task, dataset, and evaluation assumptions must be checked in the primary paper before transferring a result.
25. NVIDIA et al. (2025). SPIDER: Scalable Physics-Informed Dexterous Retargeting. Annotated primary reading. arXiv:2511.09484. — Role: primary reading for execution, communication, and timing ownership. Limitation: Dynamic feasibility in simulation does not ensure contact fidelity on hardware