What PathPlanner Is — and What It's Not

PathPlanner is two things packaged together: a desktop GUI application for drawing paths, and a Java library that makes the robot follow them. The GUI doesn't write any robot code — it produces .path and .auto files that the Java library reads at runtime. The Java library doesn't draw anything — it reads those files, generates trajectories, and provides commands that your RobotContainer schedules.

This separation is intentional and powerful. Your drive coach or strategy lead can update paths between matches without touching Java code. A mechanical team member can draw an initial path without knowing the WPILib API. The programmer configures the integration once, and from that point, adding or changing paths requires nothing but the GUI.

Installation and Initial Setup

PathPlanner has two components to install separately: the GUI application and the Java library.

Installing the GUI

Download the PathPlanner application from the Microsoft Store (Windows) or the PathPlanner GitHub releases page (github.com/mjansen4857/pathplanner/releases). The app is available for Windows, macOS, and Linux. Always install the latest stable release, not a pre-release. Launch it and select your robot project folder — PathPlanner will automatically find and use the deploy/pathplanner/ directory within your project.

Adding the Java Library

// Option 1: Use WPILib's "Manage Vendor Libraries" in VS Code
// W key → "Manage Vendor Libraries" → "Install new libraries (online)"
// Paste: https://3015rangerfinder.com/vendordeps/PathplannerLib.json
// (URL may update each season — check pathplanner.dev for current link)

// Option 2: Add directly to build.gradle dependencies block
dependencies {
    implementation "com.pathplanner.lib:PathplannerLib:2025.x.x"
    // Replace 2025.x.x with the current season's version from pathplanner.dev
}

// After adding, run: ./gradlew dependencies
// Verify PathPlannerLib appears in the output.
// If VS Code can't resolve PathPlanner imports, run a Gradle refresh.

Configuring Robot Settings in the GUI

Before drawing any paths, open the PathPlanner settings panel and configure your robot's physical dimensions and drive constants. PathPlanner uses these to correctly visualize the robot footprint on the field and to generate physically achievable trajectories.

• Robot width and length — bumper-to-bumper dimensions in meters. PathPlanner shows the robot footprint at each waypoint so you can see clearances.
• Max module speed — the top speed of your swerve modules in m/s. Used for constraint validation.
• Drive base radius — distance from robot center to the farthest module, in meters. Used for rotation calculations.
• Max velocity and acceleration — global defaults applied to all paths unless overridden by a zone.

The PathPlanner Editor: Key Concepts

The interactive editor below simulates the core elements of the PathPlanner GUI. Click to place waypoints, drag control handles to shape the spline, add event markers, and watch how changes affect the generated path. This is designed to build intuition for the real application — the actual PathPlanner GUI has more features, but the same concepts apply.

Waypoint Properties in Depth

Each waypoint in PathPlanner has properties that control how the trajectory passes through or ends at that point. Understanding what each property does prevents the common mistake of drawing paths that look right in the GUI but produce unexpected robot behavior.

Event Markers: Decoupling Actions from Movement

Event markers are the most strategically important feature of PathPlanner. They let you trigger robot commands at specific points along a path, decoupling mechanism actions from drivetrain movement. Instead of "drive, then activate intake," you can "activate intake while driving through this arc," saving time on every cycle.

Each event marker has a name (a string) and a distance-from-start position. You give the marker a name in the GUI, then register the corresponding Command in your robot code using NamedCommands.registerCommand(). PathPlanner matches names at runtime and fires the command at the right moment.

public RobotContainer() {
    // Register BEFORE configuring AutoBuilder.
    // Names must exactly match the marker names in the PathPlanner GUI.
    // Case-sensitive. "StartIntake" != "startIntake".

    NamedCommands.registerCommand("startIntake",
        new IntakeUntilSensorCommand(m_intake).withTimeout(2.0));

    NamedCommands.registerCommand("spinUpShooter",
        Commands.runOnce(() -> m_shooter.setTargetRPM(4000), m_shooter));

    NamedCommands.registerCommand("shoot",
        Commands.parallelRace(
            new EjectCommand(m_shooter),
            Commands.waitSeconds(0.5)));

    NamedCommands.registerCommand("stopIntake",
        Commands.runOnce(() -> m_intake.stop(), m_intake));

    // Configure AutoBuilder AFTER registering named commands.
    configureAutoBuilder();
}

AutoBuilder.configure(): The Integration Point

AutoBuilder.configure() is the bridge between your drivetrain subsystem and the PathPlanner library. It tells PathPlanner which methods to call on every loop to get the current pose, set chassis speeds, and access robot configuration. You call it once, in the drivetrain subsystem constructor or in RobotContainer, and from that point every PathPlanner command knows how to drive your specific robot.

private void configureAutoBuilder() {
    AutoBuilder.configure(
        // 1. Supplier of current robot pose (from odometry)
        m_drive::getPose,

        // 2. Consumer to reset pose (called at start of each auto)
        m_drive::resetPose,

        // 3. Supplier of current robot-relative ChassisSpeeds
        m_drive::getRobotRelativeSpeeds,

        // 4. Consumer of field-relative ChassisSpeeds (to apply to modules)
        (speeds, feedforwards) -> m_drive.driveFieldRelative(speeds),

        // 5. Holonomic path-following controller configuration
        new PPHolonomicDriveController(
            new PIDConstants(5.0, 0.0, 0.0),  // translation PID
            new PIDConstants(3.0, 0.0, 0.0)   // rotation PID
        ),

        // 6. Robot configuration (drive base geometry + motor specs)
        new RobotConfig(
            DriveConstants.ROBOT_MASS_KG,
            DriveConstants.ROBOT_MOI,
            new ModuleConfig(
                DriveConstants.WHEEL_RADIUS_M,
                DriveConstants.MAX_MODULE_SPEED_MPS,
                DriveConstants.WHEEL_COF,
                DCMotor.getKrakenX60(1),
                DriveConstants.DRIVE_GEAR_RATIO,
                1  // motors per module
            ),
            DriveConstants.MODULE_POSITIONS  // Translation2d[] of each module
        ),

        // 7. Path flip supplier: returns true if we're on red alliance
        // (PathPlanner mirrors paths for red alliance automatically)
        () -> {
            var alliance = DriverStation.getAlliance();
            return alliance.isPresent() &&
                   alliance.get() == DriverStation.Alliance.Red;
        },
        m_drive  // the subsystem requirement for all PathPlanner commands
    );
}

Paths vs. Autos: The Two File Types

PathPlanner distinguishes between paths and autos. Understanding the difference is what lets you build reusable, composable autonomous routines.

A .path file describes a single continuous trajectory: a sequence of waypoints with headings, control handles, constraints, and event markers. A path does one physical movement. A path is reusable — you can use "DriveToSpeaker" in multiple autos.

A .auto file is a routine: an ordered sequence of paths and standalone commands assembled in the PathPlanner GUI's auto editor. An auto says "run path A, then run command 'shoot', then run path B." An auto file corresponds to a single SendableChooser option — one selectable strategy for the drive team.

// After configureAutoBuilder() has been called:
private final SendableChooser<Command> m_autoChooser =
    AutoBuilder.buildAutoChooser();
// ↑ Scans deploy/pathplanner/autos/ for every .auto file.
//   Each .auto file becomes one dropdown option.
//   No addOption() calls needed — add a .auto file → it appears automatically.
//   New option naming: use the file name (e.g. "TwoPieceLeft.auto" → "TwoPieceLeft")

public RobotContainer() {
    registerNamedCommands();    // 1. Register named commands first
    configureAutoBuilder();      // 2. Configure AutoBuilder second
    // m_autoChooser is built with buildAutoChooser() as a field initializer,
    // which runs after the constructor body — but after AutoBuilder.configure()
    // is called via configureAutoBuilder(), so the order is correct.

    SmartDashboard.putData("Auto Mode", m_autoChooser);
    configureButtonBindings();
}

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

// You can also load a specific auto by name without the chooser:
Command specificAuto = AutoBuilder.buildAuto("TwoPieceLeft");
// Useful for testing a single routine without showing all options on dashboard.

🔌 System Check

Knowledge Check