Tune with Evidence Instead of Vibes

Tuning is an experiment.

Changing gains until the mechanism “feels good” can work, but it leaves you with no record of why the setting is reasonable or what condition will break it.

Define the behavior first

Choose measurable criteria.

Example for an elevator:

• reaches target within 1.0 second;
• overshoot stays below 3 cm;
• settles within ±1 cm;
• does not oscillate continuously;
• works with expected game-piece load;
• current remains within an acceptable operating range.

Now the tuning process has something to optimize.

Change one parameter at a time

A controlled tuning record might look like:

The exact numbers here are illustrative, not universal settings.

The table makes the decision visible.

Test disturbances

A control loop that works with no load may fail with a game piece.

Useful disturbances include:

• different mechanism load;
• lower battery voltage;
• starting farther from target;
• small external resistance;
• repeated cycles.

Do not create unsafe disturbances. The purpose is to test realistic operating conditions.

Diagnose the shape

Common behavior patterns:

Slow response
Controller may be too conservative, output limited, mechanism heavily loaded, or model/feedforward poor.

Overshoot
Correction may be too aggressive or damping insufficient.

Oscillation
Gain may be too aggressive, measurement noisy, delay significant, or mechanism flexible.

Never reaches target
Output may be insufficient, friction/load may dominate, sensor units may be wrong, or persistent error exists.

Runs away immediately
Stop. Check sign, sensor direction, output direction, and feedback logic before touching gains.

Produce a tuning record

Use simulation, logged team data, or a supervised mechanism.

Run at least three controlled trials.

Record:

• target;
• starting condition;
• parameter change;
• response;
• error behavior;
• one chart, table, or log excerpt;
• conclusion.

Then choose the setting or strategy you would keep and explain the tradeoff.

Optional extension: system identification

Advanced teams can use system-identification tools to estimate mechanism behavior and support feedforward/control design. That is more defensible than pretending one PID value is magic.

You do not need SysId to finish this unit. The core skill is evidence-driven control.

Unit evidence

Your Unit 6 package should now contain:

• sensor definition and calibration logic;
• feedback-loop diagram;
• tuning or response data;
• one diagnosed failure mode;
• final control decision with a tolerance.

If your conclusion is “0.2 felt best,” the evidence is not finished yet.