Why Measurement Beats Guessing

Across the previous lessons in Unit 8, you've built feedforward controllers, PID controllers, motion profiles, and Motion Magic configurations. Every single one of those tools has constants at its core — kS, kV, kA, kP. And at some point, someone has to put real numbers into those constants.

The way most teams first encounter this is by guessing. Start at 0.1, deploy, watch the mechanism, try 0.2. It can eventually work, but the result is rarely optimal, takes a long time under build-season pressure, and has no guarantee it reflects the mechanism's actual physics. When the mechanism gets heavier in week 3 because the mechanical team added a brace, the guesses stop being valid.

System identification — SysId — takes a different approach. Instead of asking "what gain produces behavior I like," it asks "what physical model best explains the data this mechanism actually produced." The mechanism runs controlled test patterns, the data is captured, and a regression finds the gains that minimize the error between the model and reality. The result is a set of constants grounded in the mechanism's true physics.

The Physics Model SysId Fits

SysId fits data to a specific motor model called the DC motor model. It describes the voltage required to produce a given velocity and acceleration:

V = kS·sgn(v) + kV·v + kA·a

Everything SysId does traces back to this equation. The tests it runs, the data it collects, and the regression it performs are all in service of finding the values of kS, kV, and kA that best fit your real mechanism's behavior.

The SysId Process: Four Steps

Click each step to understand what you're doing and why.

Adding SysIdRoutine to a Subsystem

The following shows a drive subsystem with SysId wired in. The pattern applies equally to any mechanism — arm, elevator, shooter — with the mechanism lambda adapted to your motor and encoder types.

import edu.wpi.first.units.measure.*;
import edu.wpi.first.wpilibj2.command.sysid.SysIdRoutine;
import static edu.wpi.first.units.Units.*;

public class DriveSubsystem extends SubsystemBase {

    private final TalonFX m_leftLeader  = new TalonFX(1);
    private final TalonFX m_rightLeader = new TalonFX(2);

    private final SysIdRoutine m_sysIdRoutine = new SysIdRoutine(
        new SysIdRoutine.Config(
            Volts.of(0.5).per(Second),   // quasistatic ramp rate: 0.5 V/s
            Volts.of(3.0),              // dynamic step voltage: 3 V
            Seconds.of(10),             // test timeout: 10 s
            null                          // use default state consumer (logs to DS)
        ),
        new SysIdRoutine.Mechanism(
            // Drive mechanism: apply voltage to both sides symmetrically
            (voltage) -> {
                m_leftLeader.setVoltage(voltage.in(Volts));
                m_rightLeader.setVoltage(voltage.in(Volts));
            },
            // Log mechanism state each loop for regression
            (log) -> {
                log.motor("drive-left")
                    .voltage(Volts.of(m_leftLeader.getMotorVoltage().getValueAsDouble()))
                    .linearPosition(Meters.of(getLeftPositionMeters()))
                    .linearVelocity(MetersPerSecond.of(getLeftVelocityMetersPerSecond()));
                log.motor("drive-right")
                    .voltage(Volts.of(m_rightLeader.getMotorVoltage().getValueAsDouble()))
                    .linearPosition(Meters.of(getRightPositionMeters()))
                    .linearVelocity(MetersPerSecond.of(getRightVelocityMetersPerSecond()));
            },
            this
        )
    );

    // Expose the four test commands for binding in RobotContainer
    public Command sysIdQuasistaticForward() {
        return m_sysIdRoutine.quasistatic(SysIdRoutine.Direction.kForward);
    }
    public Command sysIdQuasistaticReverse() {
        return m_sysIdRoutine.quasistatic(SysIdRoutine.Direction.kReverse);
    }
    public Command sysIdDynamicForward() {
        return m_sysIdRoutine.dynamic(SysIdRoutine.Direction.kForward);
    }
    public Command sysIdDynamicReverse() {
        return m_sysIdRoutine.dynamic(SysIdRoutine.Direction.kReverse);
    }
}

// In configureButtonBindings() — use a separate controller or chord
// so these cannot be triggered accidentally during a match.

// Quasistatic tests: hold button, mechanism ramps slowly. Release when done.
m_operatorController.a().whileTrue(m_drive.sysIdQuasistaticForward());
m_operatorController.b().whileTrue(m_drive.sysIdQuasistaticReverse());

// Dynamic tests: press button, mechanism steps to full voltage. Release quickly.
m_operatorController.x().whileTrue(m_drive.sysIdDynamicForward());
m_operatorController.y().whileTrue(m_drive.sysIdDynamicReverse());

// Safety note: wrap in a condition that only allows SysId bindings
// when a "characterization mode" toggle is active, to prevent
// accidental triggering during normal operation.

The Two Test Types: What They Measure

SysId collects data via two fundamentally different test patterns. Each one is designed to isolate different physical properties of the mechanism. Running only one of them produces incomplete data and poor regression results.

Quasistatic Test

The quasistatic test ramps voltage very slowly — typically 0.5 V/s — from zero upward. "Quasistatic" means "approximately static" — the mechanism moves, but so slowly that it's essentially never accelerating. This nearly-zero acceleration means the kA term drops out of the model equation, leaving:

V ≈ kS·sgn(v) + kV·v

By plotting voltage against velocity during this test, the analyzer can fit a line: the intercept is kS (voltage at near-zero velocity) and the slope is kV (voltage per unit velocity). You run it in both forward and reverse directions to ensure the model is symmetric — if it isn't, you've discovered a mechanical asymmetry worth investigating.

Dynamic Test

The dynamic test applies a large voltage step — typically 3–7V — instantly from zero. This creates a rapid acceleration phase before the mechanism approaches free-speed velocity. During the acceleration phase, the kA term dominates: the model needs significant voltage above what kS + kV·v would predict to produce that acceleration. By comparing the measured acceleration against the "unexplained" voltage (voltage minus the quasistatic prediction), the analyzer isolates kA.

Running the dynamic test too long lets the mechanism overshoot its physical limits or reach free speed, where acceleration collapses to zero and kA becomes unobservable. Release the button well before the mechanism runs out of travel.

Reading the Data: Clean vs. Contaminated

After collecting all four test runs, you export the .wpilog file from the roboRIO (via the Driver Station log folder or AdvantageScope) and open it in WPILib's SysId analysis tool. Before reading the gain outputs, always inspect the raw data plots. Good regression requires clean data.

Reading the Analyzer Output and Placing Gains

When the data is clean and the regression runs, the SysId analyzer produces a set of gains and suggested feedback gains. Here's what a typical output looks like for a drivetrain, and where each number goes in your code:

public static final class DriveConstants {

    // ── SysId characterization output ─────────────────────────────────────
    // Run SysId on the actual competition robot with a fresh battery.
    // Re-run if drivetrain gearing, wheels, or carpet contact changes.

    public static final double kS = 0.14;    // volts
    public static final double kV = 2.68;    // V·s/m
    public static final double kA = 0.34;    // V·s²/m

    // SysId suggests kP = 0.62 — start here, tune on carpet with fresh battery.
    public static final double kP = 0.62;

    public static final double WHEEL_DIAMETER_METERS = 0.1016; // 4 in
    public static final double GEAR_RATIO = 8.46;
}

// In DriveSubsystem.java:
private final SimpleMotorFeedforward m_feedforward =
    new SimpleMotorFeedforward(
        DriveConstants.kS,
        DriveConstants.kV,
        DriveConstants.kA);

private final PIDController m_drivePID =
    new PIDController(DriveConstants.kP, 0, 0);

Which Mechanisms to Characterize — and When

Not every motorized mechanism needs SysId. The return on investment depends on how precisely that mechanism must be controlled and how much that precision affects match outcomes.

🔌 System Check

Knowledge Check