We have the 2025 Pathplanner Beta 4 and the corresponding .json for Pathplanner Beta 4 installed in our vendor dependencies. And it still can’t find lib.config. We did delete the 2024 json file prior to installing the 2025 beta json. I’m hoping it’s just as simple as MJansen pushing out an update to the Pathplanner lib because we seemed to follow the structure in the example as close as we could. I did some searching in the Pathplanner lib but couldn’t find anything for config yet. We were able to compile a 2024 version of the code using the old library and old structure. Overall with Pathplanner, we have been having a very difficult time tuning our PP PIDs to have repeatable paths. We have a SDS neo setup which had colson wheels on it. Had so much trouble with slipping wheels at the regional that we just switched to the billet wheels this month and wanted to implement the 2025 Pathplanner changes now so we have time to get help troubleshooting our auto issues before the season. It seems that 50 teams with 50 different versions of code all use different PID values for Pathplanner with similar results. Frustrating that the best teams with high level coders can just “find a way to do it a better way” but unfortunately we just aren’t there. We really appreciate the simplicity and user friendliness of Pathplanner (and really appreciate mjansen’s willingness and efforts to help teams level the playing field) but just want to confirm it’s not something obvious we are doing wrong, thus following the example code exactly. Last years version of our code will follow the paths 90% accurate, just have those inaccuracies that are critical to resolve to be reliable. For instance, Path 1 will drive repeatable every time, but a linked waypoint reversal of path 1 will come up short of it’s target (all of our wheels encoders are calculating correct distances, but all 4 wheels come up short of the target value. If it’s not tuning the gains on Pathplanner, then we are starting from square one finding a solution to the inconsistencies. Any thoughts will help everyone!!! Thanks!! (copy of our code attached)
Update: after deleting and reinstalling the json 2-3 times, we were able to finally get the 2025 beta json to work and find the lib.config and were able to compile a 2025 version of the code. We are still expecting to have path inconsistencies but will report back. Is there any other tuning parameters we could test during our troubleshooting besides the Pathplanner PID constants and the wheel diameter, to help us get more accurate path distances? I’m not an expert, so anything beyond that is just a guess for us as to what could fix the issues. We have Neo drive with sparkmax velocity PID loops and neo steering motors on sparkmax using a wpi PID position loop. Our teleop drives great. Our auto paths do not. For instance, our drawn path to go get a center field note drives out accurately, but then when it drives back it slightly veers off path and stops short of the target location. Pathplanner Telemetry also shows it veering off path and stopping short of the target location. Wheel speeds have been tested as accurate, and drive distance encoders have been tested as accurate. Thanks for the help! (copy of code attached)
We’ve been unable to successfully load the vendor library for the 2025 beta version into our 2024 project. We did delete the 2024 library before installing the beta 2025 version. We had all year last season a strange error regarding our GradleRIO version but it never stopped the code from building. Below is a copy of what the VSCode terminal is saying is wrong. Any ideas how we can get around this? Thanks!
What went wrong:
An exception occurred applying plugin request [id: ‘edu.wpi.first.GradleRIO’, version: ‘2024.1.1’]
Failed to apply plugin class ‘edu.wpi.first.gradlerio.wpi.WPIPlugin’.
Could not create an instance of type edu.wpi.first.gradlerio.wpi.WPIExtension.
Vendor Dependency PathplannerLib has invalid year 2025. Expected to be 2024. Reach out to the vendor to get a new version of the dependency. Attempting to modify an existing dependency will break at runtime, and will result in loss of support from the WPILib team.
The last version of the beta to support WPILib 2024 is 2025.0.0-beta-2.2. You would need to change the versions in the vendor json to that and change the frcYear back to 2024. I don’t really recommend using that version anymore though, since its pretty outdated and will be incompatible with changes made to the GUI after the next release.
This beta release focuses on reworking the robot config/settings to allow for arbitrary swerve module positions, as well as the ability to add custom features to the robot preview to represent something like an intake. There have also been a few bug fixes.
A couple things to note with this update:
PPLib beta 5 requires WPILib beta 2
You will need to reconfigure your robot’s module positions in the GUI. They will not be automatically translated from the previously set trackwidth/wheelbase
If you use the RobotConfig.fromGUISettings() method to load a RobotConfig in code, you MUST regenerate your settings file from the GUI or the method will fail to load the settings. You can do this by changing any setting.
If not using the above method, you will need to change the creation of your RobotConfig to use individual module positions, which must be in FL, FR, BL, BR order.
The GUI settings menu has been reworked to allow for the configuration of each individual module position, instead of just trackwidth and wheelbase. This allows PathPlanner to properly generate trajectories for robots without rectangular swerve module placement. To help visualize module positions, a robot preview is always shown in the robot config settings.
PPLib has also been updated to utilize individual module positions in RobotConfig.
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.
Thank you! Next place we’re hung up is on our manually created path following command, specifically regarding the method that drives the robot with robot relative Chassis Speeds, AND feed forward. We already have the method for driving robot relative with Chassis Speeds, as we used it with PathPlanner for the 2024 season, but don’t know how to incorporate the feed forward for use in this newer version. Is there anywhere we can see a java example of this type of drive method? Thanks again!
It really depends on your swerve hardware and what framework you’re using if you’re using one. The feedforwards are completely optional and are probably only worth worrying about if you are using FOC. In that case, the CTRE swerve framework has methods to pass the feedforwards to the ApplyRobotSpeeds swerve request
With the CTRE framework, should you use the ApplyRobotSpeeds request with feedforwards on top of generating the current setpoint with the Swerve Setpoint Generator? I’m confused as to how to incorporate the setpoints into CTRE swerve requests.
Feedforwards are always optional, but they might increase accuracy a bit. The setpoint output from the generator contains chassis speeds, module states, and feedforward. You can pass the chassis speeds and feedforward X/Y components right to the ApplyRobotSpeeds request with the withSpeeds, withWheelForceFeedforwardsX, etc. methods.
When flipping the path from blue to red in a game that has mirrored symmetry, the feedforwards need to be re-arranged to swap the left and right sides. So, blue FL becomes red FR, blue FR becomes red FL, etc. The code that does this makes the assumption of having 4 modules, and being FL, FR, BL, BR order. Technically this could work with any order that goes front, front, back, back or vice versa. But, FL, FR, BL, BR is a pretty standardized order at this point, so I’ll just recommend that. Plus, the GUI uses that order so in order for the GUI generation to match the PPLib generation you should use the same order.
You can’t put any other order in the GUI. I’d recommend just standardizing on FL, FR, BL, BR since it should be a pretty minor change to make and will avoid any potential issues from using a different order.
I see. We’ll probably stick to counter clockwise modules order (mainly to be aligned with pit standard). I hope that at a future release custom order will be supported.
You can still use that as long as it goes front, front, back, back. You just have to create the RobotConfig manually with that order. The GUI won’t match, but that only actually makes a difference if your module placement is not rectangular. If you don’t plan on using the feedforwards the order does not matter at all.
We’re testing PP2025 Beta. Thanks for improving both the UI and the API in this release! The students found that setting physics in UI is much easier to follow than doing the same directly in code.
We found (not just in this release, but since PP20204) that accuracy of the trajectory runs on smaller distances (e.g. 1 meter straight run) is not that great (e.g. the command stops at 90cm instead of 1m).
The longer runs work much better (e.g. 3 or 4m straight runs stop with 2-3cm to go).
The distance differential is from the chassis odometry (meaning - this is what we feed into the trajectory controller, so it definitely knows it’s short). We did slow down trajectory to 3.5m/s speed and 2.0m/s^2 acceleration.
What do you think is set wrong - the physics of the robot, PID, trajectory being too fast? Note that we run a trajectory by subclassing FollowPathCommand (so we have more control what happens on the .execute). The PID constants for the translation are currently set at 5,0,0. Changing them did not improve anything (increasing D made it very jerky, for instance, and actually decreasing it to 0 made it work better)
Thanks.
I think the plots from the pathplanner telemetry would be helpful to find out the problem, can you run it and take a screen shot for a 1 meters path and a 3 meters path?
Haven’t touched PP or odometry for a while, but maybe it has to do with bad feedforward? What I have in mind is that maybe on longer runs the PID has time to cover for it, but for shorter ones it doesn’t?
Re: FF - that’s an interesting point. The chassis we test this on has very little friction. Nevertheless, I will look into it. The FF - you mean define it on PID for PP?
@mjansen4857 Ahead of the 2025 release could we pull the PathPlanner settings from YAGSL if you detect it exists? That way teams that are using both don’t get foot gunned by the multiple sources of truth, one of which is hidden away in a settings menu?
