PYTHON · NUMPY

The Improvement Loop: Measure → Tune → Re-Sim

Your device overshoots at 18 percent against a 5 percent limit. You raise the actuator proportional gain. What happens?

Diagnose a failing device from sim telemetry and adjust the correct parameter(s) in the correct direction to bring it to spec, and prove the change was driven by the measured data, not by guessing.

01Challenge

The bench opens on the latch-arm-v1 rig (a clean single-DOF tuning device, NOT the M4 slider-crank), already failing its spec. Cell 1 holds the editable parameters, cell 2 runs a 3.0 s rollout, cell 3 reads the metrics off the telemetry, and cell 4 grades them against the spec: S1 settle_time ≤ 0.80 s, S2 overshoot ≤ 5.0 %, S3 steady_error ≤ 1.0 deg, S4 hold_under_load (0.15 N·m disturbance at t=2.0s, |Δθ| ≤ 3°), S5 |tau_act| < 2.0 N·m for ≥95% of the run. First run: settle_time 2.26s (S1 FAIL), overshoot 66.5% (S2 FAIL), saturation 8% (S5 FAIL); steady_error 0.89° and hold_under_load 2.73° pass. OUT OF SPEC. Editable params: arm_len, arm_thick, spring_k, actuator_kp, actuator_kv, stop_angle. Your goal, BEFORE reading on: edit cell 1, re-run cells 2–4, and get all five checks to PASS. You are NOT told which knob to turn. Most learners' first instinct is to crank actuator_kp to 'get there faster', and it makes overshoot WORSE: 66.5% becomes 71.9% at actuator_kp = 8. That productive failure sets up the Model.

Predict firstYour device overshoots at 18 percent against a 5 percent limit. You raise the actuator proportional gain. What happens?

02Model

Your device just failed. A worse engineer guesses; a better one reads. Telemetry isn't decoration. It's a confession. This curve overshoots the target by sixty-six percent, then takes more than two seconds to settle. Overshoot has a meaning: the push driving the arm is winning against whatever should be slowing it down. Too much go, not enough whoa. Cranking the gain to 'get there faster' (the obvious move) makes overshoot worse. The fix is the other dial: damping. More whoa, not more go. This is the loop: measure the gap, form ONE hypothesis about ONE parameter, change only that one, re-simulate. If you change three knobs at once and it passes, you've learned nothing: you can't repeat it. One change, driven by the data, re-sim. That's not luck; that's engineering you can defend. Now go close the loop on yours.

Measure → tune → re-sim until in spec.

03Guided practice

Step A (fully scaffolded worked example): here is the diagnosis table, every number read off the rollout you just ran at actuator_kv = 0.15: overshoot 66.5% (S2 FAIL) MEANS push >> damping → candidate knob actuator_kv → INCREASE; settle_time 2.26s (S1 FAIL) MEANS oscillating before resting → actuator_kv (same) → INCREASE; saturation 8% (S5 FAIL) MEANS commanding more torque than the actuator can deliver → actuator_kv again → INCREASE; steady_error 0.89° (PASS, the limit is 1.0°) MEANS the aim is already fine → leave actuator_kp → HOLD. Takeaway: three failing checks point at the SAME knob: actuator_kv (damping) is too low; raise it; do NOT touch kp, because touching it would risk the one thing that already works. Step B (partial scaffold, predict-then-run): change ONE parameter. Write the prediction down first ('raising kv should ____ overshoot and ____ settle_time' → 'decrease / decrease'), make exactly one edit in cell 1 (raise actuator_kv), and re-run cells 2–4. Expected result at kv≈0.8: settle_time passes at 0.47s and overshoot falls from 66.5% to 6.7%, but S2 still fails by a little. Your hypothesis held; you're close but S2 still fails by a little. Nudge the SAME knob a little further, don't jump to a new one. Step C (scaffold removed): no table, no prediction, just the spec and the metrics. Converge (e.g. actuator_kv ≈ 1.0, where settle_time is 0.33s and overshoot 1.2%) until all five pass. The window is not one-sided: below about 0.85 it still overshoots past the 5% limit, above about 1.92 it is over-damped and settle_time fails again, so 'more damping' stops being the answer at some point and the telemetry says where. Keep a change-log as you go: every edit and the metrics it produced. The notebook grades only the spec, so the log is where you show that the decisive edit was the one the telemetry implicated.

04Feedback

PASS WHEN All five spec checks PASS at seed 0xD2C1 (settle_time ≤ 0.80s, overshoot ≤ 5.0%, steady_error ≤ 1.0°, hold_under_load ≤ 3°, saturation < 5%). The notebook grades the spec; the defensible part, one telemetry-implicated parameter moved in the implicated direction (raising actuator_kv), is in your change-log, and brute-forcing every knob would pass the grader without earning it.

If your run fails, check:

S2 overshoot 18% (limit 5%). You raised actuator_kp, which adds PUSH and grows overshoot. The telemetry shows too little damping: raise actuator_kv instead.
S2 overshoot 6.2%, close, limit is 5.0%. Same knob, same direction: nudge actuator_kv up ~0.05 more and re-sim.
If you met the spec by moving 4 parameters at once, the change isn't defensible: the fix can't be attributed to the data. Reset, change ONE implicated knob, and re-run. A fix you can't explain isn't a fix.
S5 saturation: tau hit 2.0 N·m for 11% of the run. You're commanding more torque than the actuator can deliver. Lower actuator_kp or raise actuator_kv to ask for less force.
PASS: settle, overshoot, steady-error, hold, and saturation all in spec. One change, driven by the data, re-simulated. That's engineering you can defend.

05Retrieve & space

(M2, constraints/ranges) Before you push actuator_kp higher: the M2 guard says arm_thick ≥ 0.006. If raising kp led you to thin the arm to drop inertia, which guard would you violate? Type the failing constraint. Reconnects tuning to the valid design envelope.
(M3, DOF) How many degrees of freedom does this latch arm have, and about which axis does theta measure? Answer: 1 DOF, revolute about hinge z. Keeps the kinematic model alive under the physics.
(M4, metric definition) overshoot is computed relative to travel, not to stop_angle. If stop_angle were 70° instead of 35°, would the same absolute peak give a larger or smaller overshoot %? Answer: smaller (larger travel denominator). Reinforces that a metric is a definition, not a vibe.

06Mastery & project

To unlock 5.2, demonstrate in the notebook: (1) bring latch-arm-v1 from OUT OF SPEC to all five checks PASS at seed 0xD2C1; (2) show from your change-log that the decisive edit was on a telemetry-implicated parameter in the implicated direction (evidence-driven, not brute-forced); and (3) pass a transfer probe: at your passing actuator_kv = 1.0, weaken the actuator to actuator_kp = 1.0. The symptom flips: no overshoot, and settle_time 1.93 s fails because the arm crawls to the stop. Recognize the changed symptom and pick the now-correct knob: lower actuator_kv (it passes near 0.4 to 0.5) or restore actuator_kp (it passes from 3), proving you're reading data, not pattern-matching last time's answer. Passing all three demonstrates the L2 competency: diagnose from telemetry and correct on evidence.

This lesson IS the engine of the capstone. The diagnose→hypothesize→change-one→re-sim loop you just proved is exactly the optimization phase you run in 5.2, except there, no one hands you the failing instance or the parameter panel: you define the spec, you build the model, and you drive it past target.

GO FURTHER · THE LIVE PLAYGROUND

Iterate a design in Forge ↗ · describe → simulate → tune the loop, end to end.

← Reading the Verdict: Did It Settle?Capstone: Design, Simulate, Validate & Optimize a Device →

PYTHON · NUMPY

The Improvement Loop: Measure → Tune → Re-Sim

latch-arm-v1: a single-DOF revolute hinge driven by a torsion-spring + position actuator, modelled parametrically in numpy (in the full Bench this is CadQuery geometry + MuJoCo-WASM dynamics). Deterministic seed 0xD2C1, 3.0s rollout. Change ONE parameter in cell 1 and re-run cells 2–4 until all five spec checks PASS. Which one is what the telemetry is for.

You read

the arrays and values already in scope

You change

the code you write in each cell

Fixed

the dataset and the checks that grade you