Chapter 06 · Give the robot an inspectable body, frame tree, and control boundary
Today in the field story
One problem, then the next
The model is geometrically coherent, so connect the Warehouse Arm Identity Audit to a mock ros2_control component. List every state and command interface with units, then trace configure, activate, read, update, write, deactivate, and error paths. Measure the cycle budget and show the bounded response to a stale read or failed write without calling lifecycle management a hardware safety function.
- Why now
Controllers need a device-independent, lifecycle-aware boundary between measured state and requested effort or motion.
- Ignore today
Ignore vendor motor APIs and powered output.
- Unlocks next
Controller Manager integration and simulation-backed command testing.
Understand
Build the physical picture first
ros2_control is a guarded adapter loop: hardware reports measured state, a controller computes a new request, and a hardware plugin translates that request for the device.
A motor driver from one vendor may speak CAN, another may use EtherCAT, and a simulator may have no physical bus at all. Robot applications should not need a vendor-specific rewrite for every device. ros2_control creates a shared boundary. Hardware components expose named state interfaces such as joint position or velocity and named command interfaces such as desired velocity or position. Controllers consume available state and write only the command interfaces they have successfully claimed.
The Controller Manager coordinates controllers and runs the main read–update–write cycle. First, hardware components read fresh device or simulated state into state interfaces. Next, active controllers update their output using that state and their reference. Finally, hardware components write the resulting command values to the device. The Resource Manager loads hardware plugins, tracks their lifecycle and interfaces, and prevents incompatible claims. A <ros2_control> section in the robot description declares the hardware component and interfaces; its joint names must match joints in the URDF.
Hardware components and controllers use lifecycle transitions so bring-up is staged. Loading creates the component or plugin. Configuring can open or prepare resources and validate parameters without yet permitting normal commands. Activation makes the component or controller operational and allows required interfaces to be claimed. Deactivation should stop normal command production and release claims according to the component contract. A lifecycle state is software state, not proof that power is isolated or motion has stopped.
The loop rate and failure policy are engineering requirements. At 100 Hz, each read–update–write cycle has a 10 ms period; a blocking device read can consume the entire budget and make commands stale. Measure each stage and missed cycles. Define what happens when read, update, or write returns an error and test any fallback controller in simulation. Command limits and timeouts are useful layers, but they do not replace firmware limits, drive safety functions, guarded first motion, or a hardware emergency stop outside ordinary application software.
Words you need
Name each idea precisely
- State interface
A named read-only value made available from hardware or simulation to controllers.
Physical example:An encoder provides left_wheel_joint/velocity.
- Command interface
A named value an active controller may claim and write as a device request.
Physical example:A drive controller writes right_wheel_joint/velocity.
- Hardware component
A plugin-backed abstraction for a system, sensor, or actuator and its physical communication.
Physical example:One system plugin reads both wheel encoders and writes both motor requests over one bus.
- Controller Manager
The component that manages controller lifecycle, interface access, and the control update loop.
Physical example:It activates a drive controller only when the required wheel command interfaces are available.
- Read–update–write loop
The repeated sequence that obtains state, computes controller output, and sends commands.
Physical example:Read encoder velocity, calculate wheel effort, then write a bounded motor request every 10 ms.
Visual model
See the relationship
Math, one line at a time
Work through today’s relationship
Prerequisite rescue · optionalTransforms, joint limits, and command interfaces
A robot model must keep geometry, state, and commands consistent.
- q
- joint positionUnit: rad or m
- q̇
- joint velocityUnit: rad/s or m/s
- limit
- allowed minimum or maximumUnit: same as the value
A joint accepts q from −1.0 rad to +1.0 rad.
A planner asks for 1.2 rad, which exceeds the maximum by 0.2 rad.
Reject it by default before the hardware interface. Clip only when a separate, explicit controller contract authorizes clipping inside a validated envelope and records both the proposal and applied command.
Treat hardware interfaces like typed function contracts with validated ranges, except a broken contract can damage a mechanism.
Is q = −0.8 rad valid for limits [−0.5, 1.0] rad?
No. It is 0.3 rad below the minimum.
The update budget is
The measured work is , leaving
Budget one 100 Hz control cycle
A controller must run at 100 Hz. Normal read takes 2.0 ms, controller update 3.0 ms, and write 1.5 ms. One fault makes read take 12 ms.
Convert rate to period: T = 1 / 100 Hz = 0.010 s = 10 ms.
Add normal stage times: 2.0 + 3.0 + 1.5 = 6.5 ms.
Compute normal timing margin: 10.0 − 6.5 = 3.5 ms before the next scheduled cycle.
Replace normal read with the fault time: 12 + 3.0 + 1.5 = 16.5 ms.
The faulty cycle exceeds the 10 ms budget by 6.5 ms, so “configured for 100 Hz” is not evidence that 100 Hz was achieved.
Log per-stage duration and missed cycles, trigger the tested fault response, and keep ordinary motion commands bounded or disabled.
The normal case fits with 3.5 ms margin; the blocking read creates a measurable overrun that needs an explicit degraded response.
A control rate is a measured timing contract across read, update, and write—not merely a number in a parameter file.
Physical examples
Where this appears in real life
Interpreter at a loading dock
The warehouse instruction stays the same while an interpreter converts it into the language used by each delivery company.
The controller expresses a robot-level request; the hardware plugin owns vendor-protocol details and reports measured state back.
Two hands reaching for one steering wheel
Only one driver should control the steering wheel at a time even though many passengers can read the speedometer.
Relate exclusive command-interface claims to one motion controller, while state interfaces can support broadcasters and monitoring.
Hands-on exercise
Make the idea observable
Use a ros2_control demo or mock hardware component; do not connect an unreviewed controller to powered actuators.
Draw the path from encoder and motor driver through hardware plugin, state interfaces, controller, command interfaces, and back to hardware.
Declare one system component and its joint state and command interfaces using names that exactly match the URDF.
Start with hardware and controller inactive, then inspect available lifecycle states and interfaces before activation.
Run the mock read–update–write loop with bounded commands and log the duration of all three stages.
Inject a delayed read or returned hardware error and capture controller state, claimed interfaces, diagnostics, and output behaviour.
Write a first-motion checklist that requires interface inspection, zero or safe command, human supervision, clear area, and an independent stop.
A correctly loaded plugin can still expose the wrong interface name, miss its cycle, return stale state, or write unsafe values unless each boundary is inspected.
The mock component moves through declared lifecycle states, interfaces match the model, cycle timing is measured, and one hardware fault produces the documented bounded response.
Build today
Model a mobile manipulator in URDF/Xacro/SRDF, wire it to ros2_control, and verify frames, controllers, state, and lifecycle in RViz.
Evidence to save
DONE when a comparison table for “ros2_control architecture, hardware interfaces, and lifecycle” contains the test condition, metric, result, and justified engineering decision.
Common mistakes
Catch the wrong mental model
Calling a command interface the measured joint state.
Commands are requests; obtain actual position or velocity from hardware state interfaces and compare the two.
Activating every controller at startup without checking interface ownership.
Inspect required and available interfaces, configure deliberately, and activate only compatible controllers under a tested sequence.
Assuming the ros2_control loop or lifecycle is an emergency stop.
Use independent hardware safety functions and prove the software stop path separately under bounded test conditions.
Job connection
How this becomes employable evidence
Integrate a new motor bus behind a hardware component, prove interface naming and lifecycle behaviour in mock hardware, then measure update-loop timing and injected communication failures before supervised commissioning.
Relevant target roles
- Robotics Deployment, Integration & Validation Engineer
- Robotics Application / ROS 2 Integration Engineer
- Robotics Software Engineer — ROS 2 / AMR
Chapter 06 interview drill
Interview questions: ros2_control architecture, hardware interfaces, and lifecycle
Practise a 60–90 second answer: define the idea, connect it to a physical robot, state assumptions, frames, and units when relevant, then finish with the failure signal or evidence you would inspect.
Primary interview scenario
Trace a velocity command through ros2_control from application reference to motor driver and back to measured state. Where do lifecycle, interface claiming, timing, and safety boundaries appear?
Answer shape: clarify the situation → trace the physical and software path → test the most likely boundaries → name the evidence that would confirm the result.
Technical follow-up questions
Q1What happens in the three stages of the main ros2_control loop?
Hardware reads measured state, controllers update command values, and hardware writes those command requests to the device.
Q2Why must ros2_control joint names match the URDF?
The control interfaces must refer to the same physical joints defined in the robot model or the contract cannot be connected correctly.
Q3What does an active controller not prove?
It does not prove timely hardware communication, actual motion, correct feedback, power isolation, or physical safety.