The first PathPlanner beta realease of the 2025 season has just been released! You can download the latest beta from here, and install PathPlannerLib through VSCode. The beta version of PPLib now uses a different vendor json file, so you will need to remove your 2024 PPLib install to install the 2025 beta. The main vendor json will be updated to the 2025 version with the kickoff release. The documentation has been updated for the beta. Note: Beta 1 currently requires WPILib 2024. Once the WPILib 2025 beta is released, PPLib will require the 2025 beta. Also, simulation on macos is not currently supported, this will be resolved once PPLib updates to use the WPILib 2025 beta.
This release focuses on the ground-up rework of PathPlanner’s trajectory generation, which aims to solve the shortcomings of the previous iteration and attempts to give PathPlanner trajectories a “just works” quality with little to no tuning, all while maintaining the ability to generate trajectories on-the-fly.
Beyond the trajectory generator rework, this release also includes new zoned event markers, “point towards” zones, the ability for event markers to function as a Trigger as an alternative to using NamedCommands, a path optimization tool in the GUI, updated support for Choreo 2025, and more. For people already familiar with PathPlanner and PathPlannerLib, I recommend checking out the docs again. Significant changes have been made to the settings, and there have been some changes to PPLib usage, such as configuring AutoBuilder, which is now condensed into a single configure method.
Improvements of Trajectory V2
Respects Swerve Dynamics
Trajectories are now generated with swerve kinematics/dynamics in mind to make sure each state is within the robot’s capabilities, increasing path following accuracy and consistency.
Motor Torque Based Acceleration Limits
Trajectory V2 uses the available torque output of your robot’s drive motors to limit the acceleration and deceleration along the trajectory. One of the issues with limiting acceleration of a module or the robot as a whole with a constant maximum acceleration/torque is that the robot’s drive motors are unable to provide constant torque throughout its entire RPM range. Therefore, they cannot maintain a linear acceleration, which requires the user to either reduce the maximum acceleration or velocity below the true maximum capabilities of the robot, or risk the robot falling behind the target acceleration when already near the max velocity. Essentially, you would have to choose between high speed or high accuracy.
Trajectory V2 now limits the acceleration of each module based on the maximum possible torque output of its motor. This uses the motor’s current RPM and current limit to get the true maximum torque output of the motor. The robot as a whole will only accelerate as much as the torque outputs from each motor would allow for. Furthermore, forces within the module due to friction are taken into account, which further limits the robot’s acceleration but aids in deceleration.
Arbitrary velocity/acceleration constraints can still be used via global constraints or constraint zones, and they will further limit the robot’s motion as long as the arbitrary constraints are within the robot’s capabilities.
Traction Control
The maximum torque applied by each drive motor is limited by the force of friction between the wheels and the carpet to prevent wheel slip. Furthermore, the maximum speed in curves is limited to prevent the wheels from slipping due to the centripetal forces it experiences.
Balanced Translation and Rotation
Translation and rotation speed is balanced to ensure that every rotation target is hit. The robot will now be able to slow down to give enough time for a rotation to complete.
Torque-Current Feedforwards
During generation, torque-current feedforwards are calculated at every state. Path following commands can now output these feedforwards along with the normal ChassisSpeed output, allowing Phoenix Pro teams using TorqueCurrentFOC control modes to utilize these values to further increase path following performance and accuracy. For teams using voltage output, the module’s acceleration is also provided, which can be converted to a voltage feedforward using the characterized kA value.
Other Notable Changes In Beta 1
Path Optimization
The path editor now includes a path optimizer tool that uses a genetic algorithm to adjust the shape of the path, minimizing the total trajectory runtime. The optimizer is not guaranteed to find the true “optimal” path shape, but it can still significantly improve the runtime of unoptimized paths. The optimizer can be run for multiple iterations if better results are desired.
Zoned Event Markers & Event Triggers
Event markers now have the option of including an end position. If a marker is zoned, its associated command will start when the robot enters the zone, and be stopped when it exits the zone. Event markers can now also be used as triggers based on the name they are given in the GUI. For zoned markers, event triggers will remain high while within the zone, and go low when leaving. If a marker is unzoned, its trigger will go high for one loop. Using events as triggers allows for much more complex behavior than NamedCommands, by binding different commands to a marker going high/low, combining multiple event triggers together to handle overlaps, or combining event triggers with other custom triggers to react to sensor reading, for example.
Future beta releases will expand on this concept by allowing for the creation of triggers on individual PathPlannerAuto commands to create more customizable/complex auto behaviors on a per-auto basis.
“Point Towards” Zones
Point towards zones are zones within a path where the robot should aim at a target position on the field. For example, this can be used to track a goal position while following a path. Overriding rotation feedback while in this zone can further increase aiming accuracy. In a future beta release, you will be able to bind commands to a trigger controlled by entering/exiting a point towards zone to easily switch on/off a rotation feedback override.
Replanning Removed
Path replanning has been removed for various reasons. First and foremost: it seemed to cause more issues than it solved. It is very difficult to create a generalized replanning solution that works for everybody. Everyone expects it to work a little bit differently, and it can’t really work perfectly for everyone. It tended to cause a lot of confusion for some people, so I think it is best to remove the generalized solution and leave any complex replanning up to individual teams to implement according to their needs if they want such a feature. Furthermore, the computation requirements for trajectory generation has significantly increased. Teams heavily relying on replanning to stich their autos together would experience noticeably higher generation time if they were constantly generating new paths throughout auto mode instead of using the pre-generated “ideal” trajectory.
Torque-Based Swerve Setpoint Generator (Currently Java Only)
A custom version of FRC team 254’s SwerveSetpointGenerator which generates setpoints based on available motor torque instead of a maximum acceleration. Also includes various other limits carried over from the generation algorithm, such as limiting torque to maintain traction and limiting module heading changes to prevent sliding. This implementation uses the same configuration object as trajectory generation, making setup quick and easy.
Override Correction Feedback
Methods have been added to PPHolonomicDriveController that allow for overriding the X, Y, and rotation feedback/correction while path following. This can be used to correct the robots X/Y velocity or rotation velocity to target a game piece or goal, while still using the feedforward velocities from the trajectory.
As usual, I appreciate anyone who spends the time time test these beta releases, and highly value any feedback/issue reporting on the github issues page. Good luck to everyone in 2025!
