We’re converting our PathPlanner code from PP 2023 to PP 2024.
The question I have - in a new command FollowPathHolonomic there is a Supplier getChassisSpeeds. Does it need to provide the ACTUAL chassis speeds every 20ms (or whenever loop gets to it), or does it need to provide MAXIMUM EXPECTED speeds in x/y/a directions?
We have our path following code currently set to our theoretical speed, but we have yet to actually test this on our robot. (hopefully we can test tomorrow)
It is fairly simple to change which speed the ChassisSpeed class needs, so we just set it to theoretical for the moment.
It may also help to have the speed set to theoretical, as this would prevent any outside factors from interfering with the speed, i.e. maybe a bump it the carpet. However, this may also cause issues with not reaching our desired speeds…
We will see what speed value we need when we do some testing, I’ll give an update when I can.
I guess my real question was - if the getChassisSpeeds shold always return the same value throughout trajectory run, that is based on constants, why is it defined as a Supplier, and not just ChassisSpeed object, with the note that you need to provide the object with limits for your robot.
getChassisSpeed should return the speed of the chassis at the time it is called.
If ChassisSpeed stayed constant throughout the auton path, then PID loops wouldn’t work to correct the chassis’s position.
Our code, in theory, should update the xSpeed, ySpeed, and Rot. values every 20ms or so (update time for default drive commands), which would provide accurate speeds for our math in getChassisSpeeds.
That’s not necessarily true. There is a Pose2D supplier that supplies real-time pose to the command, which is sufficient to calculate errors if you have max speeds known. So, there may be no need to supply current speeds. As I said, the FRC 8088 example shows supplying the same exact numbers throughout the trajectory (those are constants).
In fact, calculating current chassis speed is not a trivial task. For instance, while there is a method to convert ChassisSpeeds into SwerveModuleState, there is no “reverse” conversion.
How do you calculate current ChassisSpeeds in your code? Also perhaps, someone that runs trajectories now with PP 2024 can clarify this?
So, I got the answer from the PP developer. That does need to be real-time velocity values. One can get them via SwerveDriveKinematics.toChassisSpeeds(SwerveModuleState… wheelStates)