PathPlanner Autonomous Routes
Autonomous routing combines preplanned paths, event markers, robot constraints, and live pathfinding.
Motion, sensing, control loops, and plans made visible as a field of forces and trajectories.
Interactive model
Search around an obstacle
The grid visualizer isolates route search. A real FRC autonomous routine must also track field pose, obey drivetrain constraints, coordinate mechanisms, and respond to sensor state.
Live HTML simulation · adjust the controls and watch the computed output respond.
Interactive
A* expands likely paths first instead of flooding the whole grid
Expanded 36 cells; path contains 14 cells.
This is a simplified teaching model. Its displayed values are computed from the controls; the article explains where the model stops.
Site connection
How preplanned routes, generated paths, pathfinding, events, pose, and mechanism state combine into a testable FRC autonomous routine.
A useful autonomous route is not just a line. It is an executable sequence that respects drivetrain limits, field obstacles, starting pose, mechanism actions, game-piece state, and fallback behavior.
Definitions: Path, Trajectory, and Routine
A path describes where the robot should travel geometrically. A trajectory adds time and motion state while respecting constraints. An autonomous routine composes drive motion with intake, shooter, pivot, sensing, waits, and decision logic.
Pose is the robot's field position and heading. Tracking a route requires a credible initial pose plus odometry and, when available, carefully validated vision updates. A precise path file cannot compensate for a wrong coordinate frame.
Mental model: the path is a route on a map; the trajectory is a schedule for traveling it; the autonomous routine is the whole mission. The analogy stops where wheel slip, actuator delays, sensor faults, and command requirements affect execution.
Preplanned, Generated, and Pathfound Motion
Preplanned paths are authored and rehearsed for known starts and scoring sequences. A path generated on the fly can connect a live pose to a goal under chosen constraints, but generation alone does not imply obstacle avoidance. Pathfinding searches for a route around obstacles represented in its navigation data.
Team 1257's notes preserve this distinction: early generated trajectories to field targets could pass through walls, while PathPlanner pathfinding was intended to avoid obstacles. The team reported fixing pathfinding by updating an older LocalADStarAK.java file.
| Approach | Best fit | Strength | Failure to guard against |
|---|---|---|---|
| Preplanned path | Known start and rehearsed cycle | Predictable and tunable | Start-pose or field mismatch |
| On-the-fly path generation | Connecting live pose to a target | Flexible geometry | Obstacle ignorance if no search layer is used |
| Pathfinding | Runtime route around mapped obstacles | Adapts route shape | Bad or incomplete obstacle map |
| Hybrid | Pathfind to a rehearsed path | Flexible entry plus controlled finish | Transition and configuration complexity |
Worked Example: A Two-Note Routine
Imagine a robot begins at the top starting pose with one note. Step 1 resets the field pose to the selected alliance-correct start. Step 2 spins up and scores the preload only after pivot and shooter readiness. Step 3 follows a constrained path to Note 2 while the intake runs. Step 4 checks the break beam; if no note is present, it skips the scoring trip instead of wasting time. Step 5 returns to a scoring pose, aims, waits for readiness, and feeds.
If the intake path is 3.0 m long and the chosen trajectory averages 2.0 m/s, drive time is roughly 1.5 s before acceleration, settling, and mechanism delays. That estimate helps budget the 15-second autonomous period, but logs from complete rehearsals—not distance divided by speed alone—must establish real timing.
This example mirrors the architecture described in Team 1257's custom-auto notes, including selecting note/score positions and later checking whether a note was acquired. It is illustrative, not a claim that this exact routine succeeded in competition.
Events, Named Commands, and State Gates
Event markers can schedule named commands while a path is running. Team 1257 used named commands at event markers and linked waypoints so shared path points stayed consistent. Its custom MakeAutos flow used dashboard-selected note and score positions, pathfinding via goToPose, and deadlineWith to run intake concurrently with driving.
A marker is a scheduling trigger, not proof that the mechanism is ready. Robust routines use state gates: note detected, shooter within tolerance, pivot settled, pose credible, or timeout reached. Command requirements must also prevent two commands from fighting over the same subsystem.
| Route component | What it coordinates | Validation question |
|---|---|---|
| Initial pose | Field coordinate alignment | Does the configured start match the physical robot? |
| Constraint set | Feasible speed and acceleration | Can the real drivetrain track it without saturation? |
| Event marker | When a command is scheduled | What happens if arrival timing shifts? |
| State gate | Whether progression is allowed | Is there a timeout and safe fallback? |
| Alliance flip | Mirrored field geometry | Were poses and headings transformed consistently? |
Testing, Obstacle Data, and Source-Honest Limits
PathPlanner's official pathfinding documentation says the project needs a navgrid.json obstacle map. Search results depend on that representation; an absent obstacle cannot be avoided. Dynamic obstacles also need current, correctly framed data. Pathfinding chooses a route, while the follower and drivetrain still determine whether the robot can execute it.
Team 1257 tested dynamic obstacles in simulation before DCMP and described match performance as theoretical at that point. Earlier, the team chose not to run PathPlanner trajectories when swerve and gyro behavior was unreliable. Those records show the right reliability boundary: validate localization and drive control before trusting increasingly advanced route logic.
Test in layers: geometry in the GUI, command composition in simulation, drivetrain tracking on an empty field, mechanisms during motion, then repeated full routines from deliberately perturbed starts.
Common Pitfalls
- Assuming simulation timing matches match timing.
- Creating paths that exceed drivetrain velocity or acceleration capability.
- Ignoring initial pose, coordinate-frame, or alliance-flip errors.
- Triggering mechanisms at a marker without checking readiness or acquisition state.
- Confusing path generation with obstacle-aware pathfinding.
- Trusting dynamic obstacles on hardware when they have only been demonstrated in simulation.
- Letting multiple commands contend for the same subsystem requirement.