Chapter 06 · Give the robot an inspectable body, frame tree, and control boundary
Today in the field story
One problem, then the next
Activate one controller on the Warehouse Arm Identity Audit and follow desired joint value through claimed interfaces to measured state, JointState publication, and robot_state_publisher transforms. Plant an interface conflict and a wrong joint name. The operator display must show request, measurement, age, and error separately instead of animating the command as if it were observed motion.
- Why now
The system needs one traceable distinction between what software requested and what the modeled body reported.
- Ignore today
Ignore advanced trajectory planning and real actuator tracking.
- Unlocks next
Ground-truth comparisons and controller evidence inside Gazebo.
Understand
Build the physical picture first
The controller asks, the hardware reports, and robot_state_publisher draws; commanded position, measured position, JointState messages, and tf transforms are related but never interchangeable.
A command value describes what a controller wants the hardware to do. A state value describes what the hardware reports, such as measured position, velocity, or effort. The joint_state_broadcaster reads available state interfaces and publishes joint data for the rest of ROS. It does not turn requested commands into truth. If a wheel is blocked, desired velocity can remain nonzero while measured velocity is near zero. Monitoring should show both when the difference matters.
robot_state_publisher receives the robot's URDF tree and JointState updates. Fixed URDF joints produce static transforms, while movable joint values are combined with the model to publish changing link transforms. Names are the join key: a fresh angle labelled with the wrong joint name moves the wrong branch of the model. The resulting tree may still be smooth and current, so a known physical pose and joint-name test are necessary.
Different controllers expose different motion contracts. A joint trajectory controller follows a time-ordered joint-space trajectory using configured interfaces. A differential-drive controller turns a body-motion request into left and right wheel requests and estimates odometry from wheel feedback according to its configuration. Both rely on correctly named joints, available interfaces, limits, timing, and fresh state. Pick a controller from the physical task and hardware capabilities rather than selecting one because it accepts a convenient message.
Controller Manager handles loading, configuring, activating, deactivating, switching, and interface claims. A state broadcaster and a motion controller can coexist because they use interfaces differently, but two motion controllers usually cannot claim the same exclusive command interface at once. Inspect controller states and hardware interfaces before sending any reference. During switching, verify the old controller stops producing commands, the new controller owns exactly the intended resources, and stale application commands cannot leak into the new mode.
Words you need
Name each idea precisely
- Joint state
A named measured joint position, velocity, or effort with a timestamp.
Physical example:An encoder reports left_wheel_joint velocity = 3.8 rad/s.
- Joint command
A requested joint position, velocity, effort, or other supported command value.
Physical example:A controller requests left_wheel_joint velocity = 4.0 rad/s.
- joint_state_broadcaster
A ros2_control broadcaster that publishes selected hardware state interfaces as joint information.
Physical example:Measured wheel positions and velocities become visible to monitoring and other nodes.
- robot_state_publisher
A node that combines URDF kinematics and joint states to publish fixed and moving link transforms.
Physical example:An elbow angle moves forearm_link in the tf tree.
- Interface claim
Controller ownership of the command interfaces it needs while active.
Physical example:The drive controller claims both wheel velocity commands so another controller cannot write them simultaneously.
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.
Average joint speed is
For a wheel, linear surface speed is
Separate desired joint position from measured position
A controller requests elbow_joint = 0.50 rad. The next measured state is 0.46 rad, stamped 30 ms before now. The control loop runs at 100 Hz.
Write desired = 0.50 rad and measured = 0.46 rad as two different signals.
Compute position difference: e = 0.50 − 0.46 = 0.04 rad.
Convert the 100 Hz loop rate to a 10 ms period.
Express measurement age in loop periods: 30 ms / 10 ms = 3 cycles old.
Check the JointState name is exactly elbow_joint before robot_state_publisher applies 0.46 rad to the model.
Report the 0.04 rad difference and three-cycle age without declaring a controller fault until tolerances, motion phase, and communication evidence are known.
The display should show a 0.50 rad request, 0.46 rad measured state, and 30 ms age; tf should be calculated from the measured named state.
Freshness and signal identity matter as much as the number—otherwise an HMI can confidently display a request as reality.
Physical examples
Where this appears in real life
Car speedometer and accelerator
The accelerator request and measured vehicle speed are related but differ on a hill, on ice, or when blocked.
Map the accelerator request to command interfaces and the speedometer to state interfaces; never copy the request into the measurement display.
Stage manager and puppeteer
A stage manager assigns one puppeteer to each control string, while an observer records where the puppet actually moved.
Relate resource claims to control ownership and joint-state publication to independent observation.
Hands-on exercise
Make the idea observable
Use ros2_control mock hardware, joint_state_broadcaster, robot_state_publisher, and either a simple trajectory or differential-drive controller.
List hardware interfaces and controller states before activation; save the expected names beside the URDF joint list.
Activate only the state broadcaster and verify measured names, values, units, and timestamps before any motion controller.
Confirm robot_state_publisher moves the correct child frames when each joint state changes independently.
Configure and activate one motion controller, then verify which command interfaces it claims.
Send a small bounded reference in simulation or mock hardware and log desired, measured, error, age, controller state, and tf result.
Plant a wrong joint name or competing claim, capture the exact failure, and repair the configuration instead of renaming data in an HMI.
State publication can look healthy while a motion controller is inactive, and a controller can be active while measured motion disagrees with the command.
A reviewer can trace one bounded reference through claimed command interfaces to measured state, JointState publication, and the correct moving tf frames.
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 60–120 second uncut “Controller manager, trajectory/diff-drive controllers, and joint states” demo links to its command, logs or plots, result count, and honest failure note.
Common mistakes
Catch the wrong mental model
Publishing desired commands as JointState because the animation then looks responsive.
Publish measured hardware state as measurement; show desired values separately and label simulation assumptions.
Assuming a correctly stamped JointState moves the correct link.
Verify each joint name against URDF and run one-joint-at-a-time known-pose checks.
Switching controllers without checking released and claimed command interfaces.
Inspect controller states and resource ownership before and after the switch, and test stale-command behaviour.
Job connection
How this becomes employable evidence
Build a commissioning view that separates desired and measured joint values, freshness, controller lifecycle, interface ownership, and resulting link pose during a supervised controller switch.
Relevant target roles
- Robot HMI / Control & Monitoring Engineer
- Robotics Deployment, Integration & Validation Engineer
- Robotics Application / ROS 2 Integration Engineer
- Robotics Software Engineer — ROS 2 / AMR
Chapter 06 interview drill
Interview questions: Controller manager, trajectory/diff-drive controllers, and joint states
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
The UI shows a 0.5 rad elbow target, but RViz shows 0.46 rad and the controller is active. Explain what each value represents and the evidence needed before calling it a control defect.
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
Q1Which value should normally drive robot_state_publisher: desired or measured joint position?
The measured named joint state, because tf should represent the robot state reported by the system rather than an unverified request.
Q2Why can joint_state_broadcaster run beside a motion controller?
It reads and publishes state interfaces, while the motion controller claims and writes command interfaces.
Q3What should be inspected before activating a different motion controller?
Lifecycle states, required and available interfaces, existing claims, command limits, and the old/new controller's stale-command behaviour.