Our team is just working on swerve trajectory and we have run into some weird problems. First , we use pathplanner to draw a path. But we have went into some problems and l have also made an issue on their Github. The error of the rotation in the PathPlanner · Issue #66 · mjansen4857/pathplanner (github.com)
To sum up , my problem is that when l tell my swerve to go to a point with a rotation of 90 degree, but it will rotate to -90 degree instead. My gyro is navX and l use Rotation2d(ahrs.getYaw() * -1 / 180 * Math.PI) to get my swerve’s heading. l think that the problem may be with range of my gyro. My current range is -180 to 180 . After seeing some code of other teams , l find that the range should be 0 to 360.
Besides,l have noticed that l use a optimze method when setting my swervemodulestate.
In this method , l wonder what is the range of the state.angle. Is it between 0 to 360? My angle in this method is between -180 and 180, l wonder this may be a problem too.
You should confirm a positive PID output (positive turning) turns your robot counter-clockwise and increases your angle reading used for path following. If your robot tries to turn in the opposite direction from the target angle, you will end up turning to some angle 180 degrees offset (like what you described). Just to check, you should be using your odometry’s rotation for theta control since that is what the path is based on, and your raw gyro yaw will not match your odometry if it was reset.
A better way to write this would be: Rotation2d.fromDegrees(-ahrs.getYaw())
You don’t have to change the range. Using Rotation2d means the angles are returned as [-pi to pi] or [-180 to 180] after any operation(note the value is not constrained in the constructor). Even if your ranges were mismatched, the angle error in your theta PID controller is constrained when continuous input is enabled and should be the same.
l also find that in my teleop drive , l reverse the rotation input so that it will rotate in the right way. This may be where the fault lies in.l guess.
Edit: Why should l do this? l think there may be something wrong lie in otherwhere
Your thetaFF looks correct-- it should output a positive value when the error between angleRef and your pose is positive. What you need to check, then, is that whatever method you have to actually control the rotation of your swerve matches this. When you use a positive thetaFF value as an input to some driving function, you should be turning counter-clockwise.
If you’re plugging in joystick values in teleop, an XboxController’s right stick X is negative when pushed left, not sure if that is the same for other controllers. You should negate this value before it’s passed into your driving command so that pushing the stick left is a positive turn input (counter-clockwise).
HolonomicDriveController calculates ChassisSpeeds. You have to check your ChassisSpeeds with positive angular velocity is used by the drivetrain to spin counter-clockwise.
Since most of the swerve/Rotaion2D stuff is expecting 0-360 why not make a method that returns that from you gyro reading and use that everywhere instead of dealing with the output?
That’s the point of Rotation2d, angles are represented as cos/sin combinations so you can use degrees or radians wherever. Unless the angle value is being used incorrectly, the range should not matter. Angle is angle. The problem was related to the usage of the output.
