Chapter 06

Give the robot an inspectable body, frame tree, and control boundary

Build one small robot description from physical measurements, connect every sensor and moving link through time-aware transforms, then expose measured state and bounded commands through ros2_control without confusing a software command with verified motion.

Before you start

Name links, revolute joints, prismatic joints, joint axes, and degrees of freedom.
Read metres, radians, kilograms, and seconds, and add aligned translations.
Understand a ROS 2 node, topic, message timestamp, launch file, and lifecycle state at a beginner level.
Recognize that powered hardware needs limits, an emergency stop, and a supervised first-motion procedure.

By the end

Read and create a small URDF whose link frames, joint origins, axes, limits, visual geometry, collision geometry, and inertial data have distinct meanings.
Use Xacro to remove repetition while keeping the expanded URDF deterministic, uniquely named, and reviewable; explain what belongs in SRDF instead.
Build a single-parent tf2 tree and distinguish fixed relationships from time-varying relationships.
Perform a transform lookup for the sensor measurement time and diagnose disconnected, stale, and future-dated data without hiding the failure.
Trace ros2_control's read–update–write loop through hardware, state interfaces, controllers, command interfaces, and lifecycle transitions.
Distinguish commanded joint state, measured joint state, published JointState data, and the transforms produced by robot_state_publisher.
Run a repeatable model-and-transform audit that detects topology, unit, naming, timestamp, and controller-interface faults.

The field story

The Warehouse Arm Identity Audit

A simulated warehouse arm looks correct in RViz, but its camera appears twenty-five metres away, one elbow turns around the wrong axis, and the operator display animates desired commands instead of measured state. The XML parser reports success, so the team needs a stronger audit. You will give every rigid body, joint, sensor, transform, hardware interface, controller, and state signal one inspectable identity, then challenge the model with known poses, physical ranges, timestamps, lifecycle transitions, and planted faults.

The Warehouse Arm Identity Audit uses one simple mobile manipulator throughout the chapter. URDF defines the physical tree, Xacro removes justified repetition, tf2 carries relationships through time, and ros2_control separates measured state from bounded command requests. The mission remains on ROS 2 Jazzy with mock or simulated hardware. Lyrical and rolling documentation may inform a future compatibility review, but they cannot silently redefine the checked interface or command behavior inside this chapter.

Why this chapter now: The ROS graph needs a trustworthy physical model and command/state boundary before simulation, perception, planning, or hardware can use its names.
Ignore for now: Ignore detailed mesh artistry, powered actuation, full MoveIt planning, and vendor buses. Use primitives, conservative values, and mock hardware.
This unlocks: Gazebo simulation, sensor transforms, controller integration, calibration, Nav2 footprints, MoveIt scenes, and honest operator state.
Proof you will leave with: Save expanded model, validation output, known-pose table, frame ownership diagram, timestamp failures, interface and lifecycle traces, desired-versus-measured log, starter output, and three-fault audit.

Environment contractUbuntu 24.04 with ROS 2 Jazzy is the golden path. Use Jazzy URDF, tf2, robot_state_publisher, ros2_control interfaces, and mock or simulated hardware. The dependency-free starter runs with repository-supported Node.js 22.13.0 or newer.

Compatibility boundary: Lyrical, Kilted, rolling, or vendor-specific plugins belong in isolated build and behavior matrices. Do not copy configuration from another distribution until names, lifecycle, interfaces, timing, and tests pass on Jazzy.
Smoke check: Source /opt/ros/jazzy/setup.bash, confirm ROS_DISTRO=jazzy, and verify robot_state_publisher, xacro, and controller_manager resolve before expanding the model.
Contract reviewed: 2026-07-25
Runtime evidence: The dependency-free starter is executed by repository tests on the supported Node.js baseline. Chapter-specific ROS 2, Gazebo, model, dataset, checkpoint, and hardware environments are learner-created unless the repository supplies an explicit asset; run the smoke check and preserve its versions and output before claiming runtime compatibility.
Drift risk: high

Today in the field story

One problem, then the next

The Warehouse Arm Identity Audit begins with a measured parent-child tree, not a detailed mesh. Name every link and joint, then keep visual, collision, and inertial descriptions separate. Place the arm in a known zero pose, check axes and limits, and trace each origin to a measurement so a parser success cannot hide a metre/millimetre or parent-frame error.

Why now: Every transform, controller, and planner depends on the model’s topology, geometry, and joint conventions.
Ignore today: Ignore photorealistic meshes and precise dynamics until primitive geometry and physical ranges pass.
Unlocks next: A reviewable robot model that Xacro and downstream tools can consume.

Understand

Build the physical picture first

A URDF is a labelled family tree for the robot's rigid parts: it says what is connected to what and where each connection starts, but it does not by itself move, control, or calibrate the real machine.

A program cannot reason about “the metal plate near the motor”; it needs stable names and explicit relationships. URDF, the Unified Robot Description Format, stores that model as XML. Each rigid body is a link, and each connection between two links is a joint. A normal URDF robot is a tree: one root link has no parent, every other link has exactly one parent joint, and following parent-to-child connections cannot return to where it started. This tree restriction makes the pose of every child traceable from the root.

A link may contain three descriptions that look similar on screen but serve different jobs. Visual geometry tells RViz or another viewer what to draw. Collision geometry gives planners and simulators a usually simpler occupied shape to test for contact. Inertial data describes mass, centre of mass, and rotational inertia for dynamics. A beautiful mesh is not automatically a safe collision model, and a guessed box or zero inertia is not a trustworthy physical model. Keep the three roles separate even when the first toy model uses simple boxes and cylinders for all of them.

A joint names a parent link, a child link, a type, and an origin. At the zero joint position, the origin places the child link frame relative to the parent link frame. A revolute or continuous joint also has an axis; a limited revolute joint needs lower and upper angle limits, while a prismatic joint uses distance limits. The axis is expressed in the joint frame, so changing the joint origin can change how the same numeric axis points in the parent. Use SI units: metres, radians, kilograms, and seconds. A mesh exported in millimetres can appear one thousand times too large if its scale is not handled deliberately.

URDF is a design claim, not proof that the hardware matches it. A strong workflow checks the XML, opens the model in RViz, moves each joint through its allowed range, and compares a few measured physical distances with model distances. It also records where calibration lives, because encoder zero offsets and camera calibration usually come from configuration or calibration data rather than a hand-edited drawing. Never infer that a collision-free picture, valid XML file, or successful launch makes powered motion safe.

Words you need

Name each idea precisely

Link: A robot body treated as rigid and given its own coordinate frame.
Physical example:
The aluminium forearm plate between an elbow bearing and a wrist bearing.
Joint origin: The pose of a child link frame relative to its parent when the joint coordinate is zero.
Physical example:
The elbow hinge centre is 0.30 m along the upper-arm x-axis.
Visual geometry: Geometry chosen to show what the robot looks like.
Physical example:
A detailed camera housing mesh displayed in RViz.
Collision geometry: Geometry used when checking occupied space or simulated contact.
Physical example:
A conservative box around the camera housing that is faster to test than every screw.
Inertial data: Mass, centre of mass, and inertia values used by physics and dynamics.
Physical example:
A battery shifts the chassis centre of mass even if the outside shape stays the same.

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.

Programmer analogy

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.

For aligned link offsets,

x_{AC}=x_{AB}+x_{BC}=1.2+0.3=1.5\,\mathrm{m}.

Total mass is $1.0+0.5=1.5\,\mathrm{kg}$ . Offset addition checks placement; it does not validate inertia or collision geometry.

Place a two-link arm in its zero pose

The shoulder link frame is at the base. The elbow joint is 0.30 m along the shoulder x-axis, and a fixed tool frame is another 0.25 m along the forearm x-axis. All axes are aligned at zero.

Choose base_link as the root and create upper_link, forearm_link, and tool_link as children in one chain.
Place shoulder_joint at the base origin and give it the intended revolute axis and safe angle limits.
Set elbow_joint's zero-pose origin to x = 0.30 m from upper_link; do not put 300 and silently treat millimetres as metres.
Set tool_joint to fixed with an origin x = 0.25 m from forearm_link.
For this aligned zero pose only, check x_tool = 0.30 m + 0.25 m = 0.55 m from the shoulder frame.
Rotate the elbow in a viewer; the forearm and tool should move together around the marked elbow axis while upper_link stays attached to the base.

Result

The tool is 0.55 m from the shoulder only in the aligned zero pose, and every child has one traceable parent.

What this proves

A quick known-pose calculation catches unit and origin errors before a detailed mesh can hide them.

Physical examples

Where this appears in real life

Cardboard two-link arm

Two cardboard strips are joined by a paper fastener. Each strip is a link, and the fastener is a one-axis revolute joint.

Look for:

Mark a frame at each hinge, measure the distance between hinges, and verify which direction the joint axis points through the cardboard.

Lidar on a mobile base

A lidar is bolted 0.18 m forward and 0.24 m above the base reference point.

Look for:

Use a fixed joint for the rigid mounting, then check that the drawn scan origin matches the real optical centre rather than the outside of the housing.

Hands-on exercise

Make the idea observable

Use a two-strip cardboard arm or two rulers, a measuring tape, and a small robot-description repository. If ROS 2 is available, use its URDF checker and RViz; keep hardware unpowered.

Label the root, two moving links, two joint names, a tool frame, and each joint axis directly on the physical model.
Measure every origin offset in metres and write the measurement beside the matching physical feature.
Create the smallest URDF using primitive visual and collision shapes, realistic positive masses, and conservative joint limits.
Run the URDF checker, inspect the generated tree, and open the model with a joint-state GUI in RViz.
Move one joint at a time and compare the screen axis, direction, limit, and zero pose with the unpowered model.
Plant one 1000× mesh-scale or origin-unit error, record the visible symptom, repair it, and keep the before/after evidence.

Observe

A structurally valid tree can still be physically wrong; scale, axis, origin, and geometry-role mistakes need known measurements and motion checks.

Done when

The model validates, each joint moves the correct child around the correct axis, and a reviewer can trace every numeric origin back to a recorded measurement.

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 the learning log explains “URDF links, joints, inertial, visual, and collision models” in five precise points and a checked example produces the predicted output.

Common mistakes

Catch the wrong mental model

Wrong

Using the detailed visual mesh as proof that collision and inertia are correct.

Better

Review visual, collision, and inertial data separately and test each against its own purpose.

Wrong

Treating joint origin and link length as interchangeable numbers.

Better

Define named frames first, then measure the transform from the parent frame to the child frame at zero position.

Wrong

Typing millimetre measurements directly into fields that expect metres.

Better

Convert at the measurement boundary and add a physical-range assertion that rejects impossible robot dimensions.

Job connection

How this becomes employable evidence

Turn a vendor CAD assembly and measurement sheet into a reviewable robot_description package, then prove joint axes, physical extents, limits, and collision envelopes against the unpowered machine.

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: URDF links, joints, inertial, visual, and collision models

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

A robot looks correct in RViz but collides early in planning and falls over in simulation. Explain which URDF sections you would inspect, what each one controls, and how you would compare them with hardware.

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

Q1Why can a link have different visual and collision geometry?

Model interview answer

The visual model represents appearance, while the collision model should represent occupied space efficiently and conservatively.

Q2What does a revolute joint origin describe?

Model interview answer

It places the child link frame relative to the parent link frame when the joint coordinate is zero.

Q3What does a successful URDF parse not prove?

Model interview answer

It does not prove correct scale, axes, masses, collision envelopes, calibration, or agreement with the physical robot.

Chapter references

ROS 2 documentation — URDF tutorialsThe official sequence for visual, movable, collision, and physical robot models, Xacro, and robot_state_publisher.
ROS xacro repositoryThe maintained XML macro language used to generate shorter, parameterized robot-description XML.
ROS 2 documentation — tf2 tutorialsOfficial broadcaster, listener, frame-tree, time, timeout, and debugging exercises.
ROS robot_state_publisherThe maintained description of how URDF and joint_states produce fixed and moving transforms.
ros2_control — getting started and architectureController Manager, Resource Manager, hardware components, state and command interfaces, lifecycle, and the read–update–write loop.