Since it’s the day before the first events (other than ISR), what swerve libraries or templates have you gone with? Do you have any compliments, suggestions, or complaints?
So to answer the second part of the question. Regarding the WPILIB example project:
Compliments: Easy to follow the code and comments to understand what it was doing. All the parameters I might want to edit are easy to find in the code. Follows the standards so that when I look things up in the documentation everything makes sense.
Complaints: Default PID and FF values were more confusing than helpful. It would have probably been better to put in 0 (or 1) for most of the values and link to the docs on how to set them up. Then things would have at least worked. I’ve talked to 2 other teams who gave up on swerve drive entirely because the out-of-the-box example caused chaos.
I’m also unsure about the TrapezoidProfile in the example project. This seems like a whole new and unnecessary thing for teams to learn when they are first trying to get the swerve drive working. Again, probably should be removed and just a link to the docs on how you could do that.
Suggestions: Perhaps keep example projects to be the bare minimum that does just what it’s supposed to be rather than including a variety of other control ideas. You could then add another example project (or a few) that combines them all, but the first examples should generally be used to teach one concept at a time, not several of them simultaneously. While profiling might be recommended, it’s not necessary to do to just get things working.
My team used the REV Max Swerve Template and we were able to get up and running in no time.
Huge shout out goes to rev for making this an accessible resource.
I’ve been pleased with the CTRE Swerve Generator. We started looking at updating our custom library that was originally based on the SDS templates and found the changes to be extensive and onerous. So, we figured we would at least give the swerve generator a try since we had all the correct hardware. It worked wonderfully with only a short amount of time and has performed very well through a lot of driving, both teleop and autonomous.
We did experience one issue when we were calling seedFieldRelative to localize our odometry. It would occasionally cause the robot to freeze and only restarting code would remedy the problem. We suspect that we are getting stuck on the state lock in that function but could not determine why. Once we commented out the line where the telemetrize function was registered, we have not experienced the issue. Our suspicion is we were doing too much in telemetrize (not really much more than the generated code, though). We are able to do everything that telemetrize does in our CommandSwerveDrive periodic method, so we moved what we needed there. Haven’t had the problem since, but still keeping our eye on it.