Chapter 12 · Make an arm plan, move, touch, and prove the whole task

Today in the field story

One problem, then the next

The target approach from Week 10 enters the arm model today. Resolve it through the correct planning group, IK solver, current robot state, and scene revision. Compare multiple IK candidates by limits and collision rather than joint distance alone. When the vial is grasped later, its geometry must move from world object to attached body without leaving two contradictory copies in the scene.

Why now: Planning needs a precise model of joints, groups, state, world geometry, and intended contact.
Ignore today: Ignore motion quality optimization; establish valid start and goal configurations.
Unlocks next: A scene-consistent manipulation request with inspectable IK alternatives.

Understand

Build the physical picture first

The URDF describes the robot's body, the SRDF names useful teams of joints, IK proposes poses for those teams, and the planning scene judges each proposal in context.

URDF and SRDF answer different questions. URDF describes the physical kinematic tree, joints, limits, links, and visual or collision geometry. SRDF adds semantics used by MoveIt: planning groups, end-effectors, named states, virtual or passive joints, and disabled self-collision pairs. An SRDF cannot repair a wrong joint axis, missing link, incorrect limit, or badly scaled collision mesh in the URDF; semantic labels sit on top of a valid physical model.

A planning group selects which joints MoveIt may change for one request. Inverse kinematics maps a desired tool pose into one or more candidate joint configurations for that group. The pose must name the intended tool link, reference frame, position, orientation, and tolerance. IK can return no answer, several answers, or an answer near a joint limit. Every candidate still needs bound, self-collision, world-collision, and task-constraint checks before it becomes a planning goal.

The planning scene joins the RobotModel with a current RobotState, world geometry, attached bodies, transforms, and an allowed-collision matrix. That scene has operational state: object IDs must be stable, updates must reach the planning process, and consumers must know whether they are looking at the monitored scene or a stale local copy. Seeing a box in one RViz display does not prove the planner that handled the request received the same version.

Pick-and-place changes object ownership inside the scene. Before grasp, the cup is world geometry and should block the arm. After contact is independently verified, the scene removes it from the world and attaches it to the tool, with only intended touch links allowed. At placement, the object is detached and restored to the world at its measured or commanded pose. Attaching early makes a missed grasp look successful; detaching early can let the planner drive through the still-carried object.

Words you need

Name each idea precisely

URDF: The robot description that defines the physical link-joint tree and commonly supplies limits plus visual and collision geometry.
Physical example:
A six-joint arm URDF names each hinge axis and the collision mesh carried by each child link.
SRDF: A semantic companion description that groups joints and links and records planning concepts such as end-effectors, named poses, and selected disabled self-collisions.
Physical example:
The same physical robot can have an arm planning group, a gripper group, and a named ready configuration.
Planning group: The named subset of joints and links that MoveIt is allowed to plan for in a request.
Physical example:
An arm-only request moves six arm joints while leaving the gripper joints unchanged.
Inverse kinematics: The calculation that seeks joint values whose forward kinematics place a chosen link at a requested pose.
Physical example:
Elbow-up and elbow-down shapes can put the same simple arm tool at one point.
Planning scene: The versioned planning context containing robot model and state, world objects, attached objects, transforms, and collision permissions.
Physical example:
A shelf, cup, carried cup, current joint readings, and allowed fingertip contact all affect whether a goal is valid.
Scene diff: An incremental planning-scene update that adds, removes, attaches, detaches, or changes selected state rather than replacing everything.
Physical example:
A single update adds cup_7; a later update changes cup_7 from world object to tool-attached object.

Math, one line at a time

Work through today’s relationship

Prerequisite rescue · optionalConfiguration space, sampling, and trajectory timing

A collision-free pose is not enough; the complete joint path and timing must be feasible.

q: one point in joint configuration spaceUnit: rad or m per joint
Δq: joint change between samplesUnit: rad or m
v = Δq/Δt: joint velocityUnit: rad/s or m/s

A joint moves from 0.2 rad to 0.8 rad, so Δq = 0.6 rad.
If allocated time is 0.3 s, average velocity is 0.6/0.3 = 2 rad/s.
If the limit is 1 rad/s, increase duration to at least 0.6 s and collision-check the interpolated path.

Programmer analogy

A route can pass API validation at its endpoints while failing in the middle; robot trajectories must validate every segment.

A 0.5 rad move with a 2 rad/s limit needs at least how long?

Δt = 0.5/2 = 0.25 s.

For candidate configurations $q_i$ , a joint-distance comparison can be written as

c_i=\lVert q_i-q_{\text{current}}\rVert.

Here $c_1=0.6\ \mathrm{rad}<c_2=1.4\ \mathrm{rad}$ , but feasibility checks still decide whether either candidate is valid.

Choose between two IK candidates with complete checks

The arm group receives a base-frame tool pose. IK returns candidates A and B. Their joint-distance costs from the current state are 0.55 rad and 1.20 rad. A is inside limits but its elbow intersects shelf; B is inside limits and collision-free.

Verify that the request names the correct base frame, tool link, planning group, units, orientation convention, tolerances, and scene version.
Confirm both candidates satisfy every joint bound; an IK return code alone does not perform the complete acceptance decision.
Compare motion preference: A is nearer because 0.55 rad < 1.20 rad, but distance is only a cost, not a validity override.
Run self and world collision checks; reject A because its elbow intersects the shelf even though it has the lower joint-distance cost.
Validate B against path constraints, attached payload geometry, and the intended approach direction before passing it to the planner.
Record both candidates and rejection reasons so a later engineer sees that the farther solution was selected deliberately, not accidentally.

Result

Candidate B becomes the valid goal despite its larger joint-space distance; candidate A remains an invalid, documented alternative because of elbow-shelf collision.

What this proves

IK proposes configurations, while model bounds, the current scene, collisions, and task constraints decide whether any proposal may be planned.

Physical examples

Where this appears in real life

Skeleton, team list, and room map

Draw a stick-figure arm, circle the shoulder-through-wrist joints as one team, and place paper furniture around it on a separate room sheet.

Look for:

The skeleton is the physical tree, the circled team is planning semantics, and the changing furniture sheet is scene state; none can substitute for another.

Carry a long ruler

Reach an empty hand between two chair backs, then hold a long ruler rigidly and repeat the same slow path without touching either chair.

Look for:

The arm pose may be unchanged, but the attached object adds geometry that can invalidate the route and must remain attached until it is actually released.

Hands-on exercise

Make the idea observable

Use the official simulated robot's MoveIt configuration package and a copied test scene. Do not change the shared robot package or connect a hardware controller.

Trace one arm planning group from its SRDF name to included joints, base and tip links, end-effector relationship, named state, kinematics plugin, and joint limits in the underlying model.
Create one reachable tool-pose request with an explicit frame and tool link; save every IK candidate or the solver's bounded result plus seed, timeout, and tolerance.
Create one unreachable pose and one reachable pose whose candidate collides with a new box; keep no IK solution separate from IK solution rejected by collision.
Apply the box through the planning-scene interface, then query or inspect the monitored planning scene to prove the planner received the expected object ID, pose, dimensions, and frame.
Simulate grasp verification, attach the object with narrowly named touch links, check a lift pose, then detach it at the placement pose and confirm it again blocks later motions as world geometry.
Save a lifecycle table for each scene update with sequence, object ownership, scene evidence, accepted or rejected IK result, and exact reason.

Observe

Reachability, collision validity, and object ownership should appear as separate states; the same tool target can change validity when the scene or attached geometry changes.

Done when

One command path reproduces a valid candidate, an unreachable target, a colliding candidate, and the complete world-to-attached-to-world object lifecycle with verified scene state.

Build today

Use MoveIt 2 to plan around collision objects, servo toward a target, execute a Task Constructor pick-and-place, and stop safely on contact or invalid state.

Evidence to save

DONE when “SRDF, planning groups, IK, and planning scenes” runs from one documented command and the nominal plus boundary outputs are attached.

Common mistakes

Catch the wrong mental model

Wrong

Trying to correct a wrong joint axis or scaled mesh by changing SRDF planning-group settings.

Better

Repair and validate the physical URDF model first; use SRDF only for semantic groups, end-effectors, named states, virtual or passive joints, and justified collision semantics.

Wrong

Executing the first IK answer because the solver reported success.

Better

Check bounds, self and world collision, constraints, tool and reference frames, attached bodies, conditioning concerns, and path feasibility before planning.

Wrong

Attaching an object when the close-gripper command is sent rather than when grasp evidence is accepted.

Better

Require the declared contact or gripper-width evidence, then make one traceable scene transition; keep a failed grasp as world geometry.

Job connection

How this becomes employable evidence

Integrate a new arm and gripper by validating its URDF/SRDF contract, kinematics solver, planning groups, scene synchronization, and object attachment lifecycle across nominal and rejected targets.

Relevant target roles

Robotics Application / ROS 2 Integration Engineer
Robotics Software Engineer — ROS 2 / AMR
Robotics Deployment, Integration & Validation Engineer

Chapter 12 interview drill

Interview questions: SRDF, planning groups, IK, and planning scenes

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

Separate URDF, SRDF, IK, and planning-scene responsibilities, then explain how you would distinguish an unreachable pose, a colliding IK solution, and a stale obstacle update.

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 description should be fixed when a collision mesh is 1,000 times too large?

Model interview answer

The physical robot model or referenced mesh scale in the URDF must be corrected; changing SRDF groups would only relabel the bad geometry.

Q2Why is the nearest IK candidate not automatically the best goal?

Model interview answer

It may violate joint bounds, collide, oppose the desired approach, sit near poor conditioning, or conflict with the attached payload and task constraints.

Q3When should a grasped object move from world geometry to attached geometry?

Model interview answer

Only after the chosen grasp-verification contract succeeds; it remains attached through carried motion and returns to world geometry when release is verified.