Chapter 06 · Give the robot an inspectable body, frame tree, and control boundary
Today in the field story
One problem, then the next
Attach frames to the Warehouse Arm Identity Audit’s base, joints, camera, and tool, then assign one publisher to each parent-child edge. Separate fixed mounts from moving joints and transform a known camera point into the map frame. A pretty tree is insufficient: origins, axes, direction, units, owner, and inverse checks must tell the same physical story.
- Why now
Sensor and tool numbers cannot be compared until the model becomes a single-owner transform tree.
- Ignore today
Ignore delayed measurements until the static and current-pose relationships pass.
- Unlocks next
A frame chain that can be challenged at the measurement timestamp.
Understand
Build the physical picture first
A coordinate frame is a labelled ruler-and-compass attached to something; tf2 keeps the time-aware family tree that lets data written with one ruler be read with another.
A point such as (1, 0, 0) is incomplete until its frame and units are known. One metre forward from a camera is not the same physical location as one metre forward from a base whose x-axis points another way. tf2 stores relationships between named coordinate frames so nodes can transform stamped data into the frame they need. Common names include map, odom, base_link, camera_link, and tool0, but a name is useful only when the team documents its physical origin and axis convention.
Every transform edge has a parent frame and a child frame. Together, the edges should form a connected single-parent tree for the portion of the system being compared. A fixed sensor bracket has a static transform: its relationship to the base does not change during operation. A rotating wheel, moving arm link, or mobile base needs dynamic transforms whose poses change and whose timestamps matter. Static relationships are normally published on /tf_static with durable transient-local behaviour; moving relationships are repeatedly published on /tf with time history.
A lookup asks tf2 to convert data from a source frame into a target frame at a chosen time. For lookupTransform(target, source, time), read the question as “how do I express source-frame data in target-frame coordinates at this time?” tf2 may walk several edges, invert edges, and compose translations and rotations. In a one-dimensional aligned example, map-to-base x = 2.0 m and base-to-camera x = 0.4 m gives map-to-camera x = 2.4 m; the reverse relationship has −2.4 m. Real 3D transforms require rotation-aware multiplication, not simple addition.
A healthy frame tree also has clear ownership. One authoritative component should publish each physical relationship, because two publishers fighting over the same child can create jumps that look like sensor noise. Use tools such as a frame-tree report and transform echo to check parent-child direction, age, rate, and reachability before changing algorithms. A tree that draws successfully can still be wrong by 90 degrees, 1000× scale, or one old timestamp, so include known-pose tests.
Words you need
Name each idea precisely
- Coordinate frame
A named origin and set of axes used to describe positions and directions.
Physical example:base_link is centred between the drive wheels with x pointing forward.
- Static transform
A frame relationship that is treated as constant during operation.
Physical example:A lidar bolted to the chassis at a measured offset.
- Dynamic transform
A frame relationship that changes over time and therefore needs repeated stamped updates.
Physical example:forearm_link rotates relative to upper_link as the elbow moves.
- Source frame
The frame in which the input data is currently expressed.
Physical example:A detected point starts in camera_depth_optical_frame.
- Target frame
The frame in which the caller wants the result expressed.
Physical example:A navigation obstacle is requested in map coordinates.
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.
For aligned frames,
This one-dimensional translation check does not replace full rotation-aware transform multiplication.
Transform an aligned camera point into the map frame
At one instant, base_link is at x = 2.0 m in map. camera_link is fixed 0.4 m ahead of base_link. A point is measured 1.0 m ahead of the camera. All axes are aligned for this simplified check.
Write the frame chain map → base_link → camera_link → measured_point.
Record map-to-base translation as +2.0 m and base-to-camera translation as +0.4 m.
Record the point coordinate in camera_link as +1.0 m; do not label it as a map coordinate yet.
Compose the aligned translations: x_map = 2.0 + 0.4 + 1.0 = 3.4 m.
Check the inverse map-to-camera relationship: camera-to-map translation is −2.4 m, not another +2.4 m.
State the limitation: if any axes rotate, use full rigid transforms rather than this scalar sum.
The physical point is at x = 3.4 m in map for the stated instant and aligned-axis assumptions.
Frames turn bare numbers into traceable physical statements, and the frame path is part of every calculation.
Physical examples
Where this appears in real life
Roof antenna offset
A GPS antenna is 0.60 m forward of the vehicle reference point and never moves relative to the chassis.
Publish one static edge and predict the constant position error that appears if software pretends the antenna sits at base_link.
Wrist camera above a box
The camera is fixed to a moving wrist, while the wrist pose changes through every arm joint.
Trace camera → wrist → forearm → upper arm → base and identify which edge is fixed and which edges change.
Hands-on exercise
Make the idea observable
Use three labelled paper coordinate frames or a ROS 2 tf2 tutorial environment. No powered motion is required.
Define map, base_link, and camera_link origins and axis arrows in writing before publishing anything.
Create map → base_link and base_link → camera_link relationships with small, easy-to-check offsets.
Classify each edge as static or dynamic and name the single component responsible for publishing it.
Request camera_link in map and then map in camera_link at the same instant; verify inverse direction and units.
Use a frame-tree report to check connectivity and a transform echo to inspect the numeric relationship.
Reverse one parent-child declaration, observe which lookup or known-pose check changes, and repair it from the frame definitions rather than by guessing a sign.
A reversed edge can still produce plausible numbers, so a written physical definition and a known point are stronger than a pretty tree alone.
Another engineer can state every frame's origin and axes, identify the publisher for each edge, and reproduce both forward and inverse known-pose checks.
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 deterministic “Static and dynamic transforms with tf2” failure test reports expected versus actual behavior and passes after the documented fix.
Common mistakes
Catch the wrong mental model
Treating frame names as sufficient documentation.
Record each frame's physical origin, axis directions, units, and owning publisher.
Publishing a rigid sensor mount repeatedly as a dynamic transform.
Use a static transform for a relationship that truly does not change during operation.
Reading lookupTransform arguments as a parent-child declaration.
Read them as target, source, and time: the returned transform converts source-frame data into target-frame coordinates.
Job connection
How this becomes employable evidence
Connect a vendor camera, mobile base, and operator map so detections, planned paths, and UI overlays all use declared frames with auditable static mounts and dynamic pose ownership.
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: Static and dynamic transforms with tf2
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 camera detects a box correctly in its own image, but the box appears behind the robot in the map. Describe the frame definitions, tree edges, lookup direction, and known-pose checks you would inspect.
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 is the coordinate (1, 0, 0) incomplete on its own?
It lacks a named origin, axis convention, and units, so it does not identify one physical point.
Q2What makes a transform static rather than dynamic?
The physical relationship is treated as constant during operation, such as a rigidly bolted sensor mount.
Q3What does lookupTransform(target, source, time) let you do?
It gives the relationship needed to express source-frame data in target-frame coordinates at the requested time.