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

Today in the field story

One problem, then the next

The chosen path is only ordered geometry until joint limits and time are assigned. Apply time parameterization, inspect velocity and acceleration, and send the simulated trajectory through the real action boundary. Cancel midway and confirm feedback, controller state, and terminal result agree. Then change the scene before execution and require revalidation instead of allowing a beautiful but stale plan to move.

Why now: Execution semantics and timing turn a plan into a commandable, cancelable trajectory.
Ignore today: Ignore aggressive cycle-time tuning; prove bounded timing, freshness, feedback, and cancellation.
Unlocks next: A verified simulated motion primitive for the staged transfer.

Understand

Build the physical picture first

A path says which joint poses to visit, while a trajectory adds a clock and speed limits so a controller knows when and how quickly to visit them.

A geometric path is an ordered list or curve of collision-free configurations. It says nothing about when the robot reaches each point. A trajectory adds increasing timestamps and usually joint positions, velocities, and accelerations. This distinction matters because a path can be geometrically valid yet demand impossible speed, abrupt acceleration, or an unsupported controller interface when given careless timing.

MoveIt uses trajectory processing to time-parameterize a planned path under per-joint velocity and acceleration limits. Those limits can come from the robot model and be overridden by MoveIt configuration such as joint_limits.yaml; the more conservative, validated hardware value should win. Algorithms have assumptions and parameters. For example, MoveIt's documentation notes that Time-Optimal Trajectory Generation expects start and end at rest, so algorithm choice and endpoint conditions belong in the recorded configuration.

Execution is another boundary. A MoveIt plan or Task Constructor solution must be sent to a compatible controller, commonly through a ROS action. The controller reports acceptance, feedback, cancellation handling, and a terminal result while joint-state feedback shows what the simulated or physical plant did. A successful planning return proves no execution. An accepted action proves no final pose. Compare desired and measured traces, tolerances, timestamps, and the actual terminal status.

A plan also ages. If the robot moved, a payload changed, or the planning scene changed after planning, the old trajectory can be invalid even though its numbers remain well formed. Recheck the start state and relevant scene version immediately before execution. Cancellation needs a defined deceleration or stop policy and a verified terminal state; a software cancel request is not an emergency stop and must not replace independent protective hardware.

Words you need

Name each idea precisely

Geometric path: An ordered route through robot configurations without a schedule for reaching them.
Physical example:
Three arm poses drawn on paper show where the joints go but not whether the move takes one or ten seconds.
Trajectory: A path with monotonically increasing time and motion information such as position, velocity, and acceleration.
Physical example:
The same three poses labeled 0.0 s, 1.2 s, and 2.5 s become a schedule a controller can follow.
Time parameterization: The process of assigning feasible timing, velocity, and acceleration behavior to a geometric path under declared limits.
Physical example:
A sharp paper waypoint receives enough time for a toy joint to slow, turn, and speed up without exceeding its motor limit.
Joint limit override: A planning configuration that narrows model velocity or acceleration limits for the deployed robot or task.
Physical example:
A joint rated at 1.5 rad/s is capped to 0.4 rad/s for a fragile-object simulation and commissioning profile.
Tracking tolerance: The allowed difference between requested and measured joint behavior before execution is considered outside its contract.
Physical example:
If a joint is more than 0.05 rad behind for too long, the controller reports an error instead of silently claiming completion.
Terminal result: The final action outcome such as succeeded, canceled, or aborted, separate from goal acceptance and intermediate feedback.
Physical example:
The controller accepts a trajectory but later aborts because measured error exceeds the path tolerance.

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.

Average joint speed is

\bar\omega=\frac{\Delta q}{\Delta t}=\frac{1.2\ \mathrm{rad}}{3\ \mathrm{s}}=0.4\ \mathrm{rad/s}.

The stated triangular profile reaches $\omega_{\text{peak}}=0.8\ \mathrm{rad/s}$ , so peak velocity and acceleration require separate limit checks.

Find a feasible minimum time for one joint

One joint must move 1.20 rad, starting and ending at rest. Its simplified limits are v_max = 0.60 rad/s and a_max = 1.20 rad/s². Assume a symmetric trapezoidal profile only for this hand calculation.

Find acceleration time to the velocity limit: t_acc = v_max / a_max = 0.60 / 1.20 = 0.50 s.
Find distance during acceleration: q_acc = 0.5 × a_max × t_acc² = 0.5 × 1.20 × 0.50² = 0.15 rad.
Reserve the same 0.15 rad for symmetric deceleration, leaving 1.20 - 0.30 = 0.90 rad for constant-speed travel.
Find cruise time: t_cruise = 0.90 / 0.60 = 1.50 s.
Add the three phases: 0.50 + 1.50 + 0.50 = 2.50 s, with peak speed exactly 0.60 rad/s and acceleration magnitude 1.20 rad/s².
Treat 2.50 s as a simplified one-joint lower-bound example; a multi-joint MoveIt trajectory still needs synchronized limits, collision checks, endpoint assumptions, and controller validation.

Result

The simplified joint cannot complete this rest-to-rest move in less than 2.50 s with the stated trapezoidal profile and limits.

What this proves

Timestamps must come from velocity and acceleration constraints, not from dividing distance by a convenient average speed.

Physical examples

Where this appears in real life

Dance poses without a beat

Write three dance poses on cards, perform them with no timing, then repeat with timestamps and a rule limiting how fast an arm may swing.

Look for:

The pose order stays the same, but timing changes speed and feasibility; timestamps that are too close make an otherwise possible sequence impossible.

Toy cart and marked track

Draw a clear curved route for a toy cart, then try to push it through a tight turn first slowly and then with one sudden fast shove.

Look for:

A collision-free drawn route does not ensure the cart can follow it under acceleration, traction, and stopping limits.

Hands-on exercise

Make the idea observable

Generate one collision-free path for the simulated tutorial arm and keep execution speed conservatively scaled. No hardware controller may be selected.

Save the raw geometric waypoints, chosen trajectory-processing algorithm, robot-model limits, configuration overrides, endpoint assumptions, and requested scaling factors.
Inspect every trajectory point for consistent joint ordering, finite values, strictly increasing time_from_start, and position, velocity, and acceleration values within the declared limits.
Execute once in simulation while recording desired and measured joint positions, action goal acceptance, feedback, controller name, and terminal result.
Compare planned duration with observed duration and calculate maximum position-tracking error for each joint rather than judging the RViz animation.
Cancel a second run at a reproducible timestamp, record cancel acknowledgment, deceleration behavior, final joint state, terminal result, and whether the robot can replan from that state.
Move the simulated obstacle or start state after planning, prove the stale plan is rejected or deliberately revalidated, then generate a fresh trajectory from the current state.

Observe

The time-parameterized points should remain inside limits, measured motion should follow within declared tolerance, cancellation should end in a known state, and a changed scene should invalidate blind reuse.

Done when

Evidence separates planning success, action acceptance, feedback, successful completion, safe cancellation, and stale-plan rejection with timestamps and measured joint traces.

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 the integrated “Trajectory generation, time parameterization, and execution” path is observable, cancelable, and leaves the prior baseline reproducible.

Common mistakes

Catch the wrong mental model

Wrong

Assigning evenly spaced timestamps to waypoints without checking joint velocity and acceleration.

Better

Use a validated time-parameterization stage, inspect every joint's limits and endpoint assumptions, and assert monotonic timing plus bounded derivatives.

Wrong

Calling a trajectory executed because the planner returned success or the controller accepted the goal.

Better

Capture controller feedback, measured joint traces, tolerance checks, and the terminal action result; each boundary proves a different state.

Wrong

Sending yesterday's valid trajectory after the robot, payload, or scene has changed.

Better

Verify current start state and relevant scene version immediately before execution, then revalidate or replan whenever those inputs differ.

Job connection

How this becomes employable evidence

Connect MoveIt trajectory output to a ros2_control joint trajectory controller, qualify limit configuration and tracking tolerances, expose progress to an operator, and reproduce cancellation or stale-plan behavior.

Relevant target roles

Robotics Application / ROS 2 Integration Engineer
Robotics Software Engineer — ROS 2 / AMR
Robotics Deployment, Integration & Validation Engineer
Robot HMI / Control & Monitoring Engineer

Chapter 12 interview drill

Interview questions: Trajectory generation, time parameterization, and execution

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

Differentiate path, time parameterization, trajectory, controller feedback, and terminal result; then explain how you would validate joint limits, tracking error, cancellation, and a scene change after planning.

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

Q1What information does a trajectory add to a collision-free geometric path?

Model interview answer

It adds increasing time and motion behavior such as joint velocities and accelerations, constrained by the robot and controller contract.

Q2Why does action-goal acceptance not prove the robot reached the goal?

Model interview answer

Acceptance only means the controller agreed to attempt the goal; feedback, measured state, tolerances, and the terminal result show what happened afterward.

Q3Why should a planned trajectory be checked again when the scene changes?

Model interview answer

Its collision and start-state validity were established against earlier inputs, so changed geometry, payload, transforms, or robot state can make the old motion invalid.