Mini-Project: An Autonomous Routine with PathPlanner

A competitive auto does more than drive – it intakes, scores, and chains paths. PathPlanner’s AutoBuilder plus named commands let you author that in the GUI and trigger your real subsystem commands at event markers along the path.

Step 1: Register named commands

The string you register must be identical to the name you type in the PathPlanner GUI, and registration must happen before any auto or path is created – the docs are explicit that a command registered after auto/path creation will not be used. Register in RobotContainer after subsystems are created:

NamedCommands.registerCommand("intake", m_intake.intakeUntilHasPiece());
NamedCommands.registerCommand("score",  m_arm.scoreL4());
NamedCommands.registerCommand("stow",   m_arm.stow());

Step 2: Configure AutoBuilder

AutoBuilder needs to know how to read your pose, reset it, get robot-relative speeds, and drive robot-relative – so it can follow paths and fire event markers automatically. In PathPlannerLib 2025 the path-following controller is passed as a single object (e.g. PPHolonomicDriveController built from translation and rotation PIDConstants):

AutoBuilder.configure(
    m_swerve::getPose,                 // Supplier<Pose2d>
    m_swerve::resetPose,               // Consumer<Pose2d>
    m_swerve::getRobotRelativeSpeeds,  // Supplier<ChassisSpeeds>
    (speeds, ff) -> m_swerve.driveRobotRelative(speeds), // drive + feedforwards
    new PPHolonomicDriveController(
        new PIDConstants(5.0, 0.0, 0.0),   // translation
        new PIDConstants(5.0, 0.0, 0.0)),  // rotation
    config,                            // RobotConfig (from GUI settings)
    () -> DriverStation.getAlliance()
              .orElse(Alliance.Blue) == Alliance.Red, // flip path for red
    m_swerve);

Step 3: Build the auto

Once AutoBuilder is configured, loading a saved .auto file is one line, and you can offer a chooser on the dashboard. buildAutoChooser("...") takes an optional default-auto name:

private final SendableChooser<Command> m_autoChooser =
    AutoBuilder.buildAutoChooser("3-Piece Center");
// in robotInit / constructor:
SmartDashboard.putData("Auto", m_autoChooser);

public Command getAutonomousCommand() {
  return m_autoChooser.getSelected();
}

Event markers do the coordination

In the GUI you drop an event marker partway along a path and attach the named command intake. When PathPlannerLib follows that path, it fires the command at that point while continuing to drive – so the robot intakes on the move instead of stopping. Wrap PathPlanner-invoked commands with .asProxy() if you don’t want the path itself to be interrupted by a default command grabbing the subsystem.

Common gotcha

If an event marker “does nothing,” the cause is almost always a registered string that differs from the GUI string (“Intake” vs “intake”), or a command registered after building the auto. Register first, build second, and keep names identical.

Test the whole routine in simulation first, then on blocks with the wheels off the ground before a full field run.

Key takeaways

• Register named commands before creating any auto/path, with strings identical to the PathPlanner GUI.
• AutoBuilder.configure() takes pose getter/setter, a robot-relative speeds supplier, a drive consumer, a path-following controller, RobotConfig, an alliance-flip supplier, and the subsystem.
• Event markers fire your real commands mid-path so the robot acts while driving.
• Use buildAutoChooser() to pick autos from the dashboard, and .asProxy() to protect path commands from interruption.

This lesson was adapted from learnfrc.com.