I am programming our swerve modules using the new WPILib Swerve classes. It works great except when we want to interface with our actual modules.
The swerve module state class in wpilib returns an angle that our module should be at from -180 to 180. This works for us, however, when we cross the -180 to 180 boundary, the module will wrap back around the “long” way.
Here is our code for converting the radian setpoint to encoder ticks:
This is a problem because given 180 it will return 2048 and given -180 it will return -2048. This isn’t what we want because we want our module to instead to just increase our tick value.
Here is a video of the issue in action if it helps:
The module still works, just not as efficiently as we would want.
Talons might have a way to wrap encoder counts, but I haven’t figured out how to use it if it exists. This is what we do.
Disclaimer: this is in Java, but you should be able to understand it.
The code doesn’t use the WPI stuff. Maybe there’s a better way to do it with the WPI swerve code, but I’m unaware of it. We decided to just do it manually.
minChange is basically a standard IEEEremainder function and minDistance is the absolute value of that.
I would like to stay inside the wpilib bubble as that gives me a lot of useful features like easy odometry calculations and simple math. The only thing holding me back is converting my setpoint to ticks in an efficient way
Yeah that’s what I was trying to get at. I guess my other post explains it better. I’ll link to that next time someone has this question.
There’s also the option of using WPI’s PIDController and doing the PID loop on the roborio instead of the talon. We’ve only had the PID loop on the talon, so I don’t know which one is better.