PID Error Analyzer
Paste a run logged from the robot and get the numbers that describe it: overshoot, rise time, settling time and steady-state error. Tuning with evidence instead of by feel.
Inputs
One sample per line, time, value. Seconds and whatever unit you are controlling. A bare list of values also works, in which case the sample interval below is used.
The setpoint the run was aiming for.
How close counts as settled. 2% is a common choice.
Only used when your data has no time column.
Results
Overshoot
—%
Peak value
—
Rise time
—sec
10% to 90% of target.
Settling time
—sec
Last entry into the band.
Steady-state error
—
Mean of the final 10%.
Tracking RMS error
—
From the moment it first reaches target. The number to compare tunings on.
RMS error, whole run
—
Includes the opening ramp.
Samples read
—
Direction changes
—
Across the whole run.
How this is calculated
Every number here is measured from your data. None of it depends on knowing your gains, which is the point: the response tells you what the gains are doing more reliably than the gains themselves do.
The measurements
- Overshoot is how far past the target the peak went, as a percentage of the target. Some overshoot buys speed. A lot means P is too high or D too low.
- Rise time is 10% to 90% of target, the standard definition. It measures how aggressively the loop attacks the error.
- Settling time is the last moment the signal entered your band and stayed. Taken from the last crossing rather than the first, so a run that wanders back out is not credited with settling early.
- Steady-state error is the average of the final tenth of the run. A stubborn offset here is the classic sign that I is missing or too small.
- Tracking RMS error is measured from the moment the run first reaches target, so it describes how well the loop holds position. This is the number to compare two tunings on.
- RMS error over the whole run includes the opening ramp, which is mostly a measure of how far the start was from the target. Use it to compare runs of the same move, not different ones.
- Direction changes counts reversals across the whole run. Repeated reversals that are not shrinking mean the loop is oscillating rather than converging.
With your numbers
Reading them together
The pattern matters more than any single figure. Large overshoot with fast rise is too much P. Slow rise with no overshoot is too little. Overshoot that decays over several cycles wants more D. An offset that never closes wants I. A run that oscillates without settling is not tuned yet, and no amount of D will rescue a P that is far too high.
One run proves nothing
Log the same move several times before believing any of this. Robots are not repeatable enough for a single trial, and a tuning that looks better once often turns out to be the same tuning with a luckier start. Compare RMS error across several runs of each candidate.
Sources & assumptions
No VEX data is used. These are standard step-response measurements applied to numbers you supply, so nothing here goes stale between seasons.
Assumes a single step toward one target, sampled often enough to catch the peak. Sampling too slowly hides overshoot: if your log interval is close to the rise time, the reported peak is meaningless. Rise time is interpolated between samples; the other times are reported at sample boundaries.
Save this run, and compare
Keeps what is on screen so you can change something and see both sides of the change. Saved in this browser only, never uploaded.
Save this as evidence
Collects what you entered, what came out, how it was worked out, and anything the tool flagged, with a timestamp and a version so someone else can reproduce it.
This is evidence, not a notebook entry. It deliberately does not write your problem statement, your reasoning, or your conclusion, because under RECF rules an Engineering Notebook has to be the students' own work and no tool may generate or organise its content. Take the numbers, decide what matters, and write it yourself.