Skip to content

PathPlanner v2025.1.1
Compare
Choose a tag to compare
@mjansen4857 mjansen4857 released this 05 Jan 02:19
· 13 commits to main since this release
v2025.1.1
7ea3e9b
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Learn about vigilant mode.

The first PathPlanner realease of the 2025 season is now available! You can install PathPlannerLib through VSCode. If you used the 2025 beta, you will need to remove the beta vendor json and install the stable version again.

image

This release includes a 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.

Improvements of Trajectory V2

image

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 Since 2024

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.

image

GIF/PNG Export

The ability to export a path as an animated GIF or PNG image has been added. This can be used to easily share auto animations, create auto printouts for competition, etc.

image

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.

"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.

PathPlannerAuto Triggers

Allows for creation of event triggers, point towards zone triggers, and more on a per-auto basis instead of globally for all path following commands. This can be used to create more complex auto functionality via triggers instead of a monolithic command composition.

Robot Features

The ability to add custom shapes to the robot preview to represent different robot features has also been added. This can be used to represent things like intakes to make path creation a bit easier, or can be used to draw pretty much anything on the robot preview. Currently, features can be added as a rectangle, circle, or line. The robot’s bumpers can now also be offset from the center of the robot’s drivetrain.

image

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.

New Contributors Since 2024

Full Changelog: v2024.1.5...v2025.1.1

Contributors

jasondaming, JosephTLockwood, and 9 other contributors
Assets 7
Loading