Tune with Evidence

Changing three gains randomly is not tuning. It is gambling with decimal numbers.

A controlled tuning process changes one thing, watches a defined response, and records what changed.

Start with a safe model

Use simulation, recorded data, or a low-energy supervised mechanism.

Define:

• setpoint;
• measurement;
• output limit;
• success criterion;
• stop condition.

Example success criterion:

Reach 90 degrees with less than 5 degrees of overshoot and settle within ±2 degrees.

Now the tuning has a target.

Trial table

These values are illustrative. They are not recommended gains for a real mechanism.

Make one bounded change

A useful process might be:

1. begin with I and D at zero;
2. increase P gradually until response is useful but not unstable;
3. add D only if damping is needed;
4. add I only if persistent error remains and the mechanism needs it;
5. retest under more than one load or starting condition.

There are many valid tuning methods. The discipline is more important than this exact sequence.

Test outside the favorite case

A controller tuned from one starting position may fail elsewhere.

Test:

• near target;
• far from target;
• different load;
• disturbance;
• sensor noise;
• actuator saturation.

Produce a tuning record

Create at least three trials.

For each, save:

• gains;
• initial condition;
• target;
• peak error or overshoot;
• settling behavior;
• one sentence explaining the next change.

End with:

I trust this controller only within ______ because ______.

That boundary statement is more valuable than saying "PID works."

Change one thing at a time

A tuning session becomes useless if Kp, Ki, and Kd all change together and the behavior improves. You no longer know which change mattered.

Use controlled trials.

Example proportional-only test:

The numbers are illustrative. The method is the important part.

Log the response, not your impression

"Feels better" is weak evidence.

Record at least:

• target;
• measured value over time;
• controller output;
• saturation events;
• test conditions;
• gains used.

If the platform cannot generate a graph, a timestamped table is enough to reveal overshoot, settling, and persistent error.

A controller is ready only when its behavior is acceptable across the conditions that matter, not when one beautiful trial happens on the bench.