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

Today in the field story

One problem, then the next

Close the Warehouse Arm Identity Audit with three independent faults: scale, direction, and timestamp coverage. Predict each symptom, inject one at a time, and select the decisive physical-range, known-pose, or temporal check before changing code. Rerun topology, interfaces, lifecycle, desired-versus-measured, and frame tests after every repair so an isolated fix does not break the trusted baseline.

Why now: A layered audit is stronger than XML validity, one RViz screenshot, or one moving joint.
Ignore today: Ignore real mass, backlash, wiring, loaded motion, and physical commissioning claims.
Unlocks next: A model/control baseline ready for a repeatable simulated laboratory.

Understand

Build the physical picture first

A robot-model audit is like checking a bridge with known loads: test the tree, numbers, time, and command path with planted faults before trusting a live mission.

A model can pass an XML check and still describe the wrong robot. A complete audit therefore has layers. Structure checks ask whether names are unique, every child has one parent, referenced joints exist, and the expanded URDF is deterministic. Geometry checks compare known lengths, axes, limits, visual extents, collision extents, and inertial ranges with the physical record. Transform checks examine connectivity, direction, publisher ownership, and known poses. Time checks compare sensor stamps with buffer coverage and clock policy.

The control layer adds another chain: URDF joint name, ros2_control interface name, hardware lifecycle, controller state, command-interface claim, measured state, JointState publication, and resulting tf. Test these in order. If the final tool pose is wrong, changing a controller gain before checking a 100× unit error or wrong joint name wastes time and may create danger. A fault tree should start with evidence closest to the physical boundary and move outward without assuming one successful layer proves the next.

Plant one fault at a time so cause and symptom remain learnable. A camera translation of 25 m instead of 0.25 m should fail a physical-range or known-pose assertion even though the tree is connected. A reversed parent-child definition should fail the documented frame direction or known-point result. A measurement stamped 180 ms later than the newest required transform should fail the time-validity contract even if a latest lookup draws a plausible marker. Repair one, rerun the same checks, and keep the before/after artifact.

A portfolio-quality result is more than an RViz screenshot. Include the measured model inputs, expanded URDF, frame-tree report, automated assertions, controller/interface inventory, fault-injection procedure, structured logs, and a concise explanation of residual limitations. Record that simulation or mock hardware does not prove real mass, backlash, wiring, bus timing, safety functions, or loaded motion. This evidence maps directly to integration and validation work because another engineer can reproduce both the defect and the repair.

Words you need

Name each idea precisely

Known-pose test: A check that compares model output with a simple pose whose physical result is already known.
Physical example:
At zero angles, the tool marker should be 0.55 m along the aligned arm axis.
Physical-range assertion: A test that rejects a value outside the possible size, angle, mass, rate, or age for the system.
Physical example:
A desk robot camera mount cannot plausibly be 25 m from its base.
Fault injection: A deliberate, controlled defect introduced to prove that detection and recovery work.
Physical example:
Change one frame offset from 0.25 to 25 and confirm the audit identifies the unit-scale symptom.
Closure residual: The leftover error when relationships expected to cancel or return to a known result are composed.
Physical example:
An aligned translation plus its inverse should sum to 0 m.
Evidence pack: Reproducible inputs, checks, logs, results, faults, repairs, and limitations for review.
Physical example:
A repository and report that let an interviewer repeat all three planted failures.

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 inverse aligned transforms, the closure residual is

r=x_{AB}+x_{BA}=2.0+(-1.8)=0.2\,\mathrm{m},

but a correct inverse pair should give $r=0$ . The relation $x_{AC}=x_{AB}+x_{BC}$ then helps trace which edge corrupts a known pose.

Find three planted faults with three different checks

The audit robot contains: camera offset 25 m instead of 0.25 m, a reversed base-to-camera edge, and a lidar stamp 0.18 s newer than the newest required dynamic transform. The time contract is 0.10 s.

Run the structural check: the XML and tree may still parse, proving syntax alone cannot find all three faults.
Apply a 0–1 m mount-range assertion; 25 m fails immediately, so restore the recorded 0.25 m measurement.
Transform one known camera-axis point into base_link; the reversed relationship gives the opposite physical interpretation, so repair parent, child, and ownership from the written frame definition.
Compute time gap 0.18 s and compare it with the 0.10 s contract; reject or defer the lidar datum rather than using latest.
Rerun structure, known-pose, time, interface-name, lifecycle, and desired-versus-measured checks after each repair.
Save each failing assertion, the single repair, the passing rerun, and what real-hardware behaviour remains unverified.

Result

Three distinct checks find three distinct fault classes: physical range finds scale, known pose finds direction, and timestamp coverage finds temporal invalidity.

What this proves

The best audit is layered; no one picture, parser, or happy-path launch can validate an entire robot model and control chain.

Physical examples

Where this appears in real life

Flat-pack furniture inspection

The parts list can be complete while one rail is reversed, one dimension uses the wrong unit, or one hinge is attached to the wrong panel.

Look for:

Compare this with valid URDF syntax that still produces a physically wrong frame direction, scale, or child relationship.

Pre-flight control check

A pilot checks control direction, instrument agreement, and response rather than trusting that the dashboard simply powered on.

Look for:

Relate it to one-joint motion, desired-versus-measured state, correct tf response, and independent stop readiness.

Hands-on exercise

Make the idea observable

Use the week's robot_description and ros2_control mock setup. Create a clean baseline before changing one fault at a time.

Write an audit matrix with rows for structure, physical dimensions, frame topology, known poses, transform time, interface names, lifecycle, claims, and measured state.
Capture the baseline expanded URDF, tree report, selected transform echoes, controller list, hardware interface list, and one bounded known-pose result.
Inject exactly one unit-scale fault, one parent-child direction fault, and one timestamp-coverage fault in separate runs.
For each run, predict the expected observable failure before executing the checks, then record the actual decisive evidence.
Repair only the planted fault, rerun the full matrix, and verify neighbouring checks did not regress.
Package the scripts, commands, logs, annotated screenshots, model measurements, and residual hardware/safety limitations into a short reproducible report.

Observe

Different fault classes require different evidence; a connected tree does not validate scale, and fresh state does not validate name mapping or physical motion.

Done when

A second engineer can clone the artifact, reproduce all three failures, identify each with the intended check, apply the documented repair, and obtain the same passing matrix.

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 weekly ship note explains how “Transform audit: detect and repair three planted faults” changed the build, what still fails, and the first task for next week.

Common mistakes

Catch the wrong mental model

Wrong

Calling the model validated after check_urdf and one RViz screenshot.

Better

Add physical-range, known-pose, time, interface, lifecycle, and desired-versus-measured checks with reproducible evidence.

Wrong

Planting several faults at once and fixing whichever value looks suspicious.

Better

Inject one controlled fault, predict its symptom, use a decisive check, repair only that cause, and rerun the complete matrix.

Wrong

Presenting mock-hardware success as real-robot acceptance.

Better

State exactly what the mock proves and retain real mass, backlash, wiring, timing, loaded motion, and safety checks as unverified boundaries.

Job connection

How this becomes employable evidence

Deliver a commissioning-grade model audit that catches a CAD-to-URDF scale defect, a vendor frame-convention mismatch, and a sensor timing fault before supervised site motion.

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: Transform audit: detect and repair three planted faults

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

Your URDF parses, tf2 shows a connected tree, and the controller is active, yet a camera overlay is wrong. Give a layered audit order and explain what evidence would confirm each boundary.

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 does a connected tf tree not prove the model is correct?

Model interview answer

Connectivity cannot detect wrong scale, axis direction, physical origin, publisher truth, or timestamp validity.

Q2Which check best detects 25 m entered instead of 0.25 m for a camera mount?

Model interview answer

A physical-range or known-pose assertion tied to the measured hardware dimensions.

Q3What makes this week's audit useful as job evidence?

Model interview answer

Another engineer can reproduce the clean baseline, each controlled failure, the decisive detection, the repair, the passing rerun, and the stated limitations.

Chapter starter artifact

Audit an aligned frame-chain round trip

A pinned Jazzy model expands deterministically, validates physical ranges and known poses, exposes a single-owner time-aware frame tree, transitions mock ros2_control hardware safely, distinguishes desired and measured state, and detects three planted faults with reproducible checks.

week-06-arm-identity.mjsJavaScriptDownload starter

const mission = "warehouse-arm-identity";
const add = (left, right) => left.map(
  (value, index) => value + right[index],
);
const subtract = (left, right) => left.map(
  (value, index) => value - right[index],
);
const mapToBase = [2.0, 0.5];
const baseToCamera = [0.3, 0.2];
const cameraPoint = [1.0, 0.0];
const mapToCamera = add(mapToBase, baseToCamera);
const mapPoint = add(mapToCamera, cameraPoint);
const recoveredCameraPoint = subtract(mapPoint, mapToCamera);
const residual = Math.hypot(
  recoveredCameraPoint[0] - cameraPoint[0],
  recoveredCameraPoint[1] - cameraPoint[1],
);
const numericContract = mapToBase.concat(baseToCamera, cameraPoint).every(Number.isFinite);
const physicalRangeOk =
  numericContract && mapToCamera.every((value) => Math.abs(value) < 10);
if (!physicalRangeOk || residual > 1e-9) throw new Error("invalid frame chain");
console.log("mission=" + mission);
console.log("mapToCamera=(" + mapToCamera.map((v) => v.toFixed(1)).join(",") + ")m");
console.log("mapPoint=(" + mapPoint.map((v) => v.toFixed(1)).join(",") + ")m");
console.log("roundTripError=" + residual.toFixed(6) + "m");
console.log("rangeCheck=" + (physicalRangeOk ? "PASS" : "FAIL"));
console.log("status=PASS");

Download the file into your terminal's current folder, then run the command below. The expected output is exact.

Run: node week-06-arm-identity.mjs
Expected output: mission=warehouse-arm-identity mapToCamera=(2.3,0.7)m mapPoint=(3.3,0.7)m roundTripError=0.000000m rangeCheck=PASS status=PASS
Planted failure to diagnose: Enter the 300 mm camera offset as 300 metres. The round trip still cancels algebraically, but the independent physical-range assertion fails and exposes the scale error.