Swerve Drive Arc When Rotating in Auto Using PathPlanner

[gibsonDeGroot85]

Hello everyone,

I am a programmer from team 85, and 2023 was our first year using a swerve drive. Over the offseason we decided that we would learn how to use and implement pathplanner to our autos, and we have gotten pretty far. Our robot can drive paths we draw out perfectly, but our problem is that when we try to rotate and drive straight, the robot goes in an arc.

Here is our command to drive the path:

public Command followTrajectoryCommand(PathPlannerTrajectory traj, boolean isFirstPath) {
return new SequentialCommandGroup(
new InstantCommand(() → {
// Reset odometry for the first path you run during auto
if(isFirstPath){
// If we are running our first path of the auto it will set an origin point to where are robot starts at the beggining of the auto
m_drivetrainSubsystem.resetOdometry(traj.getInitialHolonomicPose());
}
}),
new PPSwerveControllerCommand(
traj,
// Note: the :: as opposed to . when calling a function means that it is refrencing the function, but not running it, as the
//PPSwerveControllerCommand will run it in its own code from pathplanner when the followTrajectoryCommand is run.
m_drivetrainSubsystem::getPose, // Supplies command with the function to get the robot’s position
m_drivetrainSubsystem.getKinematics(), // Wheelbase, tracklength, and other variables
new PIDController(0, 0, 0), // X controller. Tune these values for your robot. Leaving them 0 will only use feedforwards.
new PIDController(0, 0, 0), // Y controller (usually the same values as X controller)
new PIDController(0, 0, 0), // Rotation controller. Tune these values for your robot. Leaving them 0 will only use feedforwards.
m_drivetrainSubsystem::setModuleStates, // This function is most likley where broken code would be that causes the robot to not move at all
false, // Should the path be automatically mirrored depending on alliance color. Optional, defaults to true
m_drivetrainSubsystem // Requires this drive subsystem
)
);
}

From prior experience I assume we will have to tune those 3 PID controllers? Is there any other thing that I could be missing?

Thanks from team 85!

[hage-043]

My first guess would be that you’re somehow transforming your desired states based on your heading. In other words, driving robot-oriented when you should be field-oriented or vise versa. We initially ran into something like this and I believe switching to robot oriented fixed it for us. I have bad memory though.

Try looking at your swerve module state consumer and see if it transforms the states at all.

[arnavthak]

Tuning those three PID controllers seems like the answer here to me. I’m honestly surprised that most of your paths follow accurately without tuning those constants. Right now, your path following is only relying on feedforward control and velocity closed loop control on the drive motor if you use that, so it wouldn’t be surprising that rotation and translation together causes the robot to go in an arc.

[hage-043]

Good point. In my experience the FF does a good enough job that I would expect the robot to at least look like it’s trying to follow the path even running the drive motor in open loop. But if you’re working in meters, a kP of 5 should be good for your translation PID controller and if you’re working with radians, our robot has a kP of 4. YMMV tho.