Chapter 03 · Dynamics and feedback

Today in the field story

One problem, then the next

Close the Cold-Storage Door Tuning as a release review rather than a winning plot. Freeze plant, payload, initial state, setpoint, timing, gains, limits, noise, delay, and pass criteria; rerun nominal and planted faults. Report rise, overshoot, settling band, steady error, saturation fraction, recovery, and every failed trial so another engineer reaches the same evidence-limited verdict.

Why now: A repeatable report is the only honest bridge from controller intuition to engineering acceptance.
Ignore today: Ignore physical-door approval; simulation evidence cannot validate wiring, load, braking, or independent safety.
Unlocks next: A tested control-loop contract ready for deterministic C++ implementation.

Understand

Build the physical picture first

A controller is not “good” because it reached the target once. It is good only for a declared test when its complete response is stable, bounded, accurate, timely, and repeatable.

Start with a fixed test contract: plant model or mechanism, payload, initial state, setpoint change, sample period, noise and delay, command limits, gains, software version, and pass criteria. Changing any of these while comparing controllers makes the result ambiguous.

A step-response plot should show setpoint, measured output, error, requested command, applied command, and saturation. Rise time describes the initial approach using a declared convention, overshoot measures how far the response exceeds the target, and settling time is when it enters and remains inside a declared tolerance band.

Steady-state error measures the remaining long-term offset. Also report maximum command, time in saturation, oscillation or sign changes, and safety violations. One attractive average can hide rare large failures, so preserve per-trial results and the worst case.

Repeatability requires the exact runnable configuration and multiple fixed trials. A credible report includes successful and failed plots, numeric metric definitions, source data, and an engineering decision such as “reduce Kp,” “add model feedforward,” or “the actuator is undersized.” It never upgrades simulation evidence into a claim of hardware safety.

Words you need

Name each idea precisely

Rise time: Time for the response to make its initial rise across a declared fraction of the final change.
Physical example:
A report may define 10–90% rise time for a wheel-speed step.
Overshoot: How far the response exceeds the target, often as a percentage of step size.
Physical example:
A 10° target with a 12° peak has 20% overshoot for a step from zero.
Settling time: Time until the response enters and stays within a declared tolerance band.
Physical example:
The arm stays inside ±0.2° after 3.4 s.
Steady-state error: The remaining error after transient behaviour has ended.
Physical example:
A joint rests 0.1° below its target under gravity.
Saturation fraction: The fraction of trial time for which applied command is at a limit.
Physical example:
0.6 s saturated during a 4 s trial is 15%.

Visual model

See the relationship

Swipe the technical canvas horizontally on a small screen.

Day 21 · Math check — Another engineer can repeat the setup and verify the claim. Measured anchor: 100 % checks.

Math, one line at a time

Work through today’s relationship

Prerequisite rescue · optionalChange over time and feedback

Velocity, acceleration, and control error explain whether a robot settles, overshoots, or becomes unsafe.

Δx/Δt: change in position divided by elapsed timeUnit: metres per second (m/s)
e = target − measured: control errorUnit: same unit as the target
u: bounded actuator commandUnit: device-specific

A wheel moves from 1 m to 1.6 m in 0.2 s, so Δx = 0.6 m.
Average velocity is 0.6/0.2 = 3 m/s.
If the target is 2 m and measured position is 1.6 m, error e = 0.4 m; a controller converts that error into a limited command.

Programmer analogy

A feedback loop resembles an event loop that checks state repeatedly, but a missed deadline changes physical motion, not just screen responsiveness.

Position changes by 0.5 m in 0.25 s. What is average velocity?

0.5/0.25 = 2 m/s.

Percent overshoot is

M_p=\frac{y_{\text{peak}}-y_{\text{target}}}{y_{\text{target}}}\times100\%=\frac{12-10}{10}\times100\%=20\%.

If the response remains inside the declared $\pm0.2$ band after $3.4\ \mathrm{s}$ , then $t_s=3.4\ \mathrm{s}$ .

Calculate a small controller scorecard

A zero-to-10 unit step reaches 9 units at 1.1 s, peaks at 12 units, stays inside 10±0.2 after 3.4 s, finishes at 9.9 units, and is saturated for 0.6 s of a 4.0 s trial.

Declare rise-time convention; here use first time the response reaches 90% of the 10-unit step.
Read rise time as 1.1 s because 90% is 9 units.
Compute percent overshoot: (12-10)/10×100%=20%.
Read settling time as 3.4 s using the declared ±0.2 band.
Compute final steady-state error: 10-9.9=0.1 unit.
Compute saturation fraction: 0.6/4.0×100%=15%.
Compare every metric with written pass limits instead of assigning “good” by appearance.

Result

The scorecard is 1.1 s rise time, 20% overshoot, 3.4 s settling time, 0.1 unit final error, and 15% saturation.

What this proves

Metric definitions and pass thresholds are part of the test; otherwise the same plot can support conflicting claims.

Physical examples

Where this appears in real life

Two lifts reach the same floor

One lift arrives smoothly in four seconds; another passes the floor, reverses twice, and arrives after ten seconds.

Look for:

Final position alone calls both successful, while overshoot, settling time, and command history reveal very different quality.

Warehouse rover with changing payload

A speed controller is tested empty and with a loaded tote using the same path and setpoint.

Look for:

Report per-condition rise time, tracking error, saturation, and any oscillation rather than combining all runs into one average.

Hands-on exercise

Make the idea observable

Use the bounded simulation from this week and freeze one setpoint, initial condition, sample period, command limit, and 100-step duration.

Write numeric pass criteria for maximum overshoot, settling time, steady-state error, and saturation fraction.
Run the baseline gains three times with exactly the same deterministic conditions.
Run one boundary case with added delay and one with a persistent opposing bias.
Export or copy setpoint, measurement, error, requested command, applied command, and saturation columns.
Calculate the five scorecard metrics with stated definitions.
Include the worst plot, explain its cause using evidence, and choose one next change.
Rerun only that change against the unchanged test contract.

Observe

A change that improves rise time may worsen overshoot or saturation; controller quality is a tradeoff constrained by the task.

Done when

The report is reproducible from its configuration, includes nominal and failure evidence, and ends with a justified engineering decision.

Build today

Control a simulated pendulum or cart-pole; log setpoint, error, command, saturation, and settling time.

Evidence to save

DONE when the weekly ship note explains how “Controller tuning report with plots and metrics” changed the build, what still fails, and the first task for next week.

Common mistakes

Catch the wrong mental model

Wrong

Reporting only the final error or one successful run.

Better

Include transient metrics, command limits, repeated conditions, failure cases, and per-trial results.

Wrong

Using “settled” without a tolerance band.

Better

Declare the band and require the response to enter and remain inside it.

Wrong

Comparing gain sets while changing payload, delay, or initial condition.

Better

Freeze the test contract; change one factor at a time or label a designed test matrix explicitly.

Wrong

Calling simulation success proof of safe hardware behaviour.

Better

Treat simulation as evidence for the model and implementation, then perform separate protected SIL, HIL, and hardware validation.

Job connection

How this becomes employable evidence

Build a regression report that compares controller versions across payload, delay, friction, and saturation cases with fixed acceptance thresholds and raw failure traces.

Relevant target roles

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

Chapter 03 interview drill

Interview questions: Controller tuning report with plots and metrics

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

What evidence would convince you that a wheel-speed controller is ready for HIL testing, and what would simulation still not prove?

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 must settling-time tolerance be declared?

Model interview answer

Different bands produce different settling times, so the number is meaningless without its criterion.

Q2What does 20% overshoot mean for a zero-to-10 step?

Model interview answer

The response peaked 2 units above the target, at 12.

Q3What does a repeatable simulation report not prove?

Model interview answer

It does not prove unmodelled hardware, electrical, thermal, contact, timing, or safety behaviour.

Chapter starter artifact

Inspect one bounded discrete PID update

A deterministic simulated door produces labelled setpoint, state, error, P/I/D terms, requested/applied commands, timing, saturation, and recovery plots plus a fixed test table and an evidence-limited PASS or NEEDS REVISION verdict.

week-03-cold-storage-door.mjsJavaScriptDownload starter

const mission = "cold-storage-door";
const target = 1.2;
const measured = 0.4;
const previousError = 1.2;
const dt = 0.1;
const integral = 0.12;
const gains = { p: 2, i: 0.5, d: 0.1 };
const error = target - measured;
const pTerm = gains.p * error;
const iTerm = gains.i * integral;
const dTerm = gains.d * (error - previousError) / dt;
const requested = pTerm + iTerm + dTerm;
const limit = 1;
const applied = Math.max(-limit, Math.min(limit, requested));
const numericContract = [
  target, measured, previousError, dt, integral, limit, ...Object.values(gains),
].every(Number.isFinite);
if (!numericContract || dt <= 0 || limit <= 0 || error <= 0 ||
    !Number.isFinite(requested)) throw new Error("invalid control update");
console.log("mission=" + mission);
console.log("error=" + error.toFixed(3));
console.log("requested=" + requested.toFixed(3));
console.log("applied=" + applied.toFixed(3));
console.log("saturated=" + String(applied !== requested));
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-03-cold-storage-door.mjs
Expected output: mission=cold-storage-door error=0.800 requested=1.260 applied=1.000 saturated=true status=PASS
Planted failure to diagnose: Reverse the error to measured minus target. The proportional correction changes sign and drives the simulated door away from its setpoint, exposing a positive-feedback convention fault.