The Architecture: Parallel Paths, One Output

Feedforward and PID run in parallel — both compute independently, then their outputs are summed into a single voltage command. The feedforward path is open-loop and stateless: it receives the setpoint, computes the predicted voltage from the physics model, and outputs it immediately. The PID path is closed-loop and stateful: it receives the measurement, computes the error, updates its accumulator, and outputs a correction. The combination: immediate physics-based drive from feedforward, precision from PID.

FF Only vs PID Only vs FF + PID

Select a mode to see how each approach responds to the same step command.

The Three Complete Patterns

Color-coded lines: green = feedforward, purple = PID, blue = the combined setVoltage() call. Click highlighted tokens for explanations.

The Reduced kP Insight

This is the most practically important consequence of combining feedforward with PID. When feedforward provides 90–95% of the required output, the PID controller only needs to correct the remaining 5–10% of error. That means kP can be dramatically smaller than in a PID-only controller — often 5 to 20 times smaller.

Why does smaller kP matter? Smaller kP means:

• Less overshoot — a smaller proportional force at maximum error produces less momentum toward the setpoint
• Less oscillation risk — the kP threshold for oscillation is higher relative to the working gain
• Less need for kD — with modest kP, the D term needed to damp overshoot is smaller, reducing noise sensitivity
• No kI needed in most cases — feedforward eliminates the static friction error that kI was needed to correct

For a flywheel: a PID-only controller might need kP = 0.05 to drive 80 RPS. With feedforward providing the 8V base, kP = 0.002 corrects the residual ±2 RPS error. The PID contribution is never more than ±0.004V per RPS of error — tiny corrections on top of a stable base.

Split-Output Telemetry: Verifying FF Is Doing Its Job

The most important diagnostic for a combined controller is publishing FFVolts and PIDVolts as separate channels. This pattern reveals the health of the combined system in one look. Press the simulation buttons to see healthy and unhealthy patterns.

The Sign Convention Check

The feedforward and PID outputs must both point in the same direction for the system to work correctly. A sign mismatch — where FF is positive and PID correction is always negative — means they are fighting each other. The motor gets FF − PID instead of FF + PID, which can cause oscillation or inability to reach the setpoint.

How to check: command a positive setpoint (arm to 90°, flywheel to positive RPS). At steady state, both FFVolts and PIDVolts should be approximately the same sign (both positive for an upward/forward command). If PIDVolts is consistently large and opposite in sign to FFVolts, the PID's setpoint or measurement convention is inverted. Common causes:

• Encoder reads in the wrong direction (negative velocity when moving forward)
• Setpoint units mismatch between feedforward and PID (FF in RPS, PID in RPM)
• ArmFeedforward using radians but PIDController using degrees

You've Already Used This Architecture — Since Unit 7

Every swerve module you built in Unit 7 uses the FF + PID combined architecture — but onboard the TalonFX at 1 kHz instead of roboRIO-side. Your Slot0 configuration:

cfg.Slot0.withKP(0.1).withKV(0.12).withKS(0.25);

This is exactly V_total = kS·sgn(v) + kV·v + kP·error — feedforward (kV and kS terms) plus PID (kP term) — computed onboard at 1 kHz. The only difference from the roboRIO pattern in this lesson: Phoenix 6 runs both in the same slot, on the same chip, at 20× higher frequency. The architecture is identical. The location is different.

Knowledge Check