Skip to content
Mechanical, Build & Pneumatics·Lesson 43 of 47

Characterizing Any Mechanism with SysId

Use WPILib SysId to empirically measure kS/kV/kA (and kG) for drives, arms, and elevators, then deploy the gains for accurate feedforward control.

Sign in to track progress, earn XP, and save lessons.

Why characterize?

Guessing PID gains is slow and fragile. Elite teams instead measure their mechanism's physics. The permanent-magnet DC motors in FRC closely obey the voltage-balance equation:

V = kS * sgn(v) + kV * v + kA * a (add + kG for gravity-loaded systems)

SysId, included with the WPILib installer, drives the mechanism through controlled test routines and regresses these constants from logged voltage/velocity/position data.

The four constants

  • kS (static): voltage to overcome friction/stiction. Nearly impossible to model, must be measured.
  • kV (velocity): voltage to hold a given velocity, the dominant term.
  • kA (acceleration): voltage to produce a given acceleration; matters during fast moves.
  • kG (gravity): for arms/elevators, the voltage to counter gravity (cosine-scaled for arms).

The test routines

SysId runs two kinds of tests in both directions:

  1. Quasistatic: voltage ramps slowly so acceleration ≈ 0, isolating kS and kV.
  2. Dynamic (step): a sudden voltage step, exciting acceleration to extract kA.

You wire your subsystem into a SysId routine, run quasistatic-forward, quasistatic-reverse, dynamic-forward, dynamic-reverse, then analyze the log.

Deploying the gains

Drop the results into the matching feedforward (note the constructor order kS, kG, kV, kA for the gravity classes):

// Drive / flywheel
var ff = new SimpleMotorFeedforward(kS, kV, kA);
// Arm (kG cosine-compensated internally)
var armFf = new ArmFeedforward(kS, kG, kV, kA);
// Elevator (constant kG)
var elevFf = new ElevatorFeedforward(kS, kG, kV, kA);

Then add a modest kP for disturbance rejection. With good feedforward, kP does very little work, which is exactly what you want.

Per-side / per-module matters

Characterize each drive side (tank) or each module (swerve) separately. Mismatched kV across sides is the textbook cause of a robot veering; distinct, measured gains fix it.

Pitfalls

  • Garbage in, garbage out: ensure encoder conversion factors are correct before testing, or every gain is scaled wrong.
  • Run on the real surface with real mass; characterizing a bare gearbox gives gains that don't hold the loaded mechanism.
  • Respect mechanism limits, set soft limits so a dynamic step doesn't crash an arm into a hard stop.

The payoff

A characterized mechanism tracks motion profiles accurately, recovers from disturbances predictably, and behaves the same on Saturday as it did in your shop, the foundation every advanced technique below builds on.

Key takeaways

  • SysId empirically measures kS/kV/kA (and kG) via quasistatic + dynamic routines instead of guessing gains.
  • Feed the measured constants into SimpleMotorFeedforward/ArmFeedforward/ElevatorFeedforward (gravity classes use order kS, kG, kV, kA), then add only a small kP.
  • Characterize each drive side/swerve module separately and verify encoder conversion factors first, or every gain is wrong.

Lesson quiz

Required

Answer all 3 questions correctly to complete this lesson.

1.What is the primary output of running a SysId characterization routine on a mechanism?

2.How does the SysId quasistatic test differ from the dynamic test?

3.When characterizing an arm with SysId, what additional gain is required compared to a simple flywheel?

Answer every question to submit.