Why Sequential Commands Can't Do This

In Lessons 2–4 you built a solid foundation: sensor-based commands that drive a specific distance, turn to a specific angle, and sequence these into multi-step routines. This approach works well. For many FRC games and many teams, it's enough to be competitive.

But there's a fundamental limitation to the "drive, stop, turn, drive" pattern. Every time the robot stops to turn, it loses momentum. The sequence of motions isn't continuous — it's a series of discrete segments joined at hard stops. In a 15-second autonomous period where fractions of seconds matter, those stops add up. More importantly, they make the path longer than necessary: a smooth arc from position A to position B is almost always shorter than the drive-stop-turn-drive equivalent.

Path following solves this by treating the robot's motion as a continuous trajectory — a mathematically defined curve through space with a velocity and heading at every point along it. Instead of commanding "drive 2 meters, then turn 90°," you command "follow this arc from A to B, arriving with this heading and this velocity." The robot never stops. The closed-loop controller corrects for drift at every timestep. The result is motion that's faster, smoother, and more position-accurate than any sequence of discrete commands can achieve.

The Core Concepts

Path following introduces vocabulary that will appear throughout Lessons 7–10. These are not abstractions — each concept maps directly to a WPILib class or a physical robot behavior.

The Control Loop in Action

The path-following control loop runs every 20 ms. At each timestep, the controller compares where the robot should be (trajectory desired pose) against where it actually is (odometry actual pose) and computes the ChassisSpeeds needed to correct the error. Toggle between open-loop and closed-loop below to see what happens when there's no feedback to correct position drift.

The Path-Following Control Loop Step by Step

Understanding what happens every 20 ms during path following demystifies why it requires accurate odometry, why the holonomic controller has PID gains, and why pose resets before autonomous matter so much.

What the Robot Needs Before Path Following Works

Path following is more demanding than sensor-based commands. It requires several things to be true simultaneously on the physical robot. None of these are optional — each one is a hard dependency.

// 1. ACCURATE ODOMETRY
// The robot must continuously track its field-relative Pose2d.
// Test: place robot at known position, drive 1 meter forward.
// Odometry should read approximately (1.0, 0.0) if starting from origin.
// If it reads (0.7, 0.3), your encoder configuration or gyro heading is off.
SwerveDrivePoseEstimator poseEstimator = new SwerveDrivePoseEstimator(
    kinematics, gyro.getRotation2d(), modulePositions, startingPose);

// 2. POSE RESET AT AUTO START
// Odometry must be zeroed to the robot's actual starting position on the field
// before the first path command runs. The trajectory assumes the robot starts
// at a specific Pose2d — if odometry shows a different pose, the controller
// computes an immediate correction toward the wrong reference.
m_drive.resetPose(new Pose2d(1.5, 4.0, Rotation2d.fromDegrees(0)));

// 3. CHARACTERIZATION DATA FOR DRIVETRAIN
// The holonomic controller uses kV to predict the voltage needed at each
// velocity point in the trajectory. Without characterization, feedforward
// is effectively zero and the robot relies entirely on PID — causing lag.
// Run SysId on the drivetrain before tuning path-following gains.

// 4. HOLONOMIC CONTROLLER WITH TUNED PID GAINS
// Three independent PID controllers: x translation, y translation, rotation.
// Start with kP = 1.0-5.0 for translation, kP = 1.0-3.0 for rotation.
// Increase until you see oscillation, then back off 20%.
PPHolonomicDriveController controller = new PPHolonomicDriveController(
    new PIDConstants(5.0, 0, 0),   // translation PID
    new PIDConstants(2.0, 0, 0)); // rotation PID

// 5. MODULE STATES APPLIED CORRECTLY
// Each call to the path-following controller produces a ChassisSpeeds object.
// Your drivetrain must convert this to module states and apply them every loop.
// If your setModuleStates() method is missing, path following outputs will be
// computed but not sent to any motor controller.

Why Path Following Is Especially Powerful on Swerve

Path following exists for both differential and swerve drivetrains, but its advantages are compounded on swerve. A differential drive can follow a curved path, but it must rotate the robot to change direction — heading and translation are always coupled. A swerve drive can follow a curved path while maintaining any heading, independently. This decoupling is what "holonomic" means.

In autonomous, holonomic path following means the robot can:

• Drive in a curve while keeping the intake pointed at a game piece source
• Arrive at a scoring position facing the target without a dedicated turn command
• Travel from one scoring position to another via the most geometrically efficient path, regardless of the required headings at each end
• Correct for drift in two dimensions simultaneously rather than sequentially

The PathPlanner holonomic controller used in Lesson 7 exploits all of this. You define the robot's heading at each waypoint independently of its direction of travel, and the controller maintains that heading constraint throughout the path without any additional turn commands.

What Comes Next: PathPlanner

Lesson 7 puts everything from this lesson into practice with PathPlanner — the GUI path editor and Java library used by Team 2910 and most top FRC teams. You'll draw paths, configure constraints, register event markers, and generate the AutoBuilder chooser.

Before moving to Lesson 7, you should have the following working on your robot:

• A SwerveDrivePoseEstimator updating every loop in periodic()
• A resetPose(Pose2d) method on your drivetrain subsystem
• A getChassisSpeeds() method returning the current measured speeds
• A drive(ChassisSpeeds) method that accepts a ChassisSpeeds and applies it to the modules
• SysId characterization data for the drivetrain (kS, kV, kA) from Lesson 8.13

If any of these are missing, path following will either fail silently or produce incorrect motion. Verify each one independently before running the first PathPlanner path.

🔌 System Check

Knowledge Check