A couple days ago my team finally finished making the swerve drive train and it was running pretty smoothly.
The next day I come in during lunch to test it again and the strafing was stuttering. We didn’t change the code or touch the robot in between those days. After more testing we found out that when the swerve is at exactly 90 degrees it stutters and the motor safety was going off. I have a good feeling it’s a programming issue, I just don’t understand what we did differently.
I only ask because I’m definitely 0 help on the programming side of things, but did not touching the robot in those days include not putting in a fresh battery? Or is it possible you’ve got a bad battery where before you had a good one?
All else truly equal, the battery is the first thing my mind goes to as a potential issue.
Don’t know too much about programming swerve drives however if the drive train safety is going off usually the speeds aren’t being updated enough. If it is dealing with specifically 90* make sure your values for driving aren’t zeroing out as a result.
For somebody who knows more than me some code and or a video would be nice.
You may need to current limit the Neos - sometimes when the azimuth motor has to start with a turn the current draw goes too high and the spark maxes will cut power momentarily - causing a stutter. OK…I’ve said more than I can technically vouch for But check it out.
Your located pretty close to us. If you would like us to send over one of our programmers let me know, or you could bring your bot by our shop. We can also help you out at Glacier Peak if needed, just let us know.
We’ve also spent a long time getting the Mk2 drivetrain working well and are finally happy with it, and I’d be happy to answer questions. Are you using Java or C++? (And if Java, are you running the example code?)
We are using java and the example code. I slightly modified it so that it would use cims instead of neos for just the drive motors and made it so that all the code in DriveCommand.java would run in Robot.java.
It’s generally recommended for field-centric driving (forward/backwards on the stick always corresponds to the driver’s forward/back instead of the robot’s). It can certainly run without one, but most drivers find it less intuitive.
Theoretically you could calculate your angle with odometery and use that in place of a gyro, but I can’t vouch for the accuracy/drift of that method as I’ve never tried.