Dashboard Tuning Workflow
Tune with graphs and notes instead of guesses.
Tune with graphs and notes instead of guesses.
In this lesson, you will:
FTC Dashboard shortens the tuning loop by letting teams adjust constants and graph behavior live. It is powerful only if the test procedure is repeatable.
Tuning is an experiment. The robot setup, battery voltage, target move, and mechanical condition are part of the data.
You already know that tuning means changing a parameter and checking the response. Let's make that a controlled experiment where we're not just guessing, and we actually decide what we change next. Before touching a constant, we need to have a good baseline. This sample run uses a 1,000-tick target. It has a kP of 0.0005 and kG of 0.08, and it has an output limit of 0.5. We want to record a few things: the starting state, the target, the voltage band, the output limit, the rise, the overshoot, the settling behavior, and the reason the test ended. A graph without its test conditions is not a reusable baseline. In the code, this fixture keeps the trial really small on purpose. Baseline returns the original kP, kG, and output limit. One-variable trial changes only kP; kG and the limit stay fixed. Ambiguous trial changes both kP and kG, so we have one deliberately invalid comparison. In a real tuning tool, the live values may come from your Dashboard configuration fields. The main rule stays the same: save the starting values somewhere reviewable before actually changing them. Trial A changes kP from 0.0005 to 0.0007. kG, the target, output limit, start state, test conditions, and all the other conditions remain fixed. The lesson's tuning log also rejects a comparison when the battery readings differ by more than 0.2 volts. If those conditions match and the response changes, we can reasonably connect that change to kP.
Make constants configurable, graph target/actual/error/output, change one value at a time, and copy final reviewed values back into code.
TuningConstants.javaJava
@Config
public class LiftTuning {
public static double kP = 0.004;
public static int targetTicks = 1200;
}Dashboard can encourage random knob turning. If students change multiple constants at once, they cannot learn what mattered.
Tune one guarded vertical-lift fixture from a frozen start state and target sequence. Verify soft limits, reduced output, timeout, and STOP first; change one of kP or kG per run; reject comparisons above ΔV = 0.2 V; export maximum error, overshoot, settling, saturation, limit state, and exit reason; restore the accepted baseline after the two-change fault; then record three cold-init repetitions at each named target.
Check your understanding before moving on.
0 of 2 answered