Hello, our team is using swerve for the first time and we are experiencing some issues with swerve module drift. We had decided to fork from an established codebase to start and we have found that we keep tweaking values without seeing much of a difference in the end result. Our wheels seem to have minds of their own after starting and while some are close, others are off by 30 degrees or more. I am starting to wonder if maybe it was due to the constants not matching up with our current configuration: SDS MK4I modules and SparkMax modules. We seem to be spinning our wheels and some assistance with troubleshooting would be greatly appreciated!
I am thinking that a potential culprit here is our drive and turning gear ratios. They were originally set to be the same values in zero to autonomous’s code which were 1 / 5.8462 for the drive motor and 1 / 18.0 for the turning motor. I have since amended these to be what I believe are the correct values for the SDS MK4i per the specifications. Though, I am wondering if it was correct for me to invert them as I did. Another point that was brought up at our last meeting was that our kPTurning value was set to be too high and we may see better results by starting lower and tuning. We use Absolute Encoders from thrifty bot and plan to check if the magnet was installed properly the next time we meet.
I apologize if this post is rather short or lacks needed information, please don’t hesitate to ask any clarifying questions or for more information about our robot. Thank you.
Wait wait wait is this a combination of MK4I and MAXSwerve? I noticed your github had some constants that I use in my MAXSwerve (as well as having a drive and turning motor controllers as spark max in the code), you mention using MK4i and spark maxes in your description. Is it just MK4i with Neos? Sorry I got a little confused
Are the absolute encoders plugged into the spark max? If so, have you used REV Hardware client to set the zero of the absolute encoder and burn flash? Just making sure we went through all the prerequisites.
On that note, I think I found something…
I recommend restoring factory defaults to your spark max’s, as well as burning the flash once you are done modifying the position conversion factors and other things. It should look something like this:
We do this to make the spark max more hot-swappable, as it must be done at least once during installation (burning flash after applying settings). This also makes sure that all of the offsets that we have applied to the motor get forced to be put into the code (except for absolute encoder zeros) which helps us make sure we aren’t forgetting any settings for the sparks.
Also, not sure if you are aware of this or not, but I recommend forcing the sparks on break mode using CANSparkMax.setIdleMode(CANSparkMax.IdleMode.kBrake), as well as setting any current limits you may want using CANSparkMax.setSmartCurrentLimit(double). We use 50 amps as our driving limit and 20 amps as our turning limit, but we use a big Neo for driving and a mini Neo (550) for turning.
First off, I don’t know if this pun was intentional or not, but if it was, bravo!
As for what your problem is: if things seems OK at startup, and then gradually get worse, it is likely one of the two problems that you mentioned:
-The software doesn’t have the accurate gear ratio between the motor, the encoder, and the wheel. To try to validate that, just look at all of the gearing involved and make sure have it all exactly correct.
-Something is physically slipping somewhere in the orientation mechanism. That could be the encoder not accurately measuring its position, a belt skipping a tooth, etc. To try to validate this, put the robot up on same “jacks” (like wood blocks) so that the wheels are off of the ground, and make aggressive driving movements and monitor closely to see if you can observe anything go wrong.
I’ll try to answer these questions as best I can, sorry if I miss anything. We use MK4I modules with Neos. The absolute encoders are plugged into the RoboRio through the analog ports.
That is a very good point about restoring to factory defaults and burning to flash, is that safe to do every time the code is run? Do you think that the gear rotation ratio in the constants class will need to be inverted to obtain the proper value?
This is the link to the code that is practically identical(we have since changed some of our code so it’s not 1:1 anymore): https://github.com/SeanSun6814/FRC0ToAutonomous/tree/master/%236%20Swerve%20Drive%20Auto . I did take a look at YAGSL and I may end up switching gears on this current codebase if we can’t get it working and starting from there. I had not taken a look at 3512’s yet but I will certainly do so.
Yep, we run that every time the bot starts. We have some extra trickery that we add with it (we add a delay to burning flash so that we are more guaranteed that the data is saved to the spark), but that trickery is not at all necessary. I think I experienced something that would have been fixed by said “trickery” in only one of our 88 real matches…
You are going to notice really quickly if the gear ratios are incorrect, I recommend looking at the way other teams have their MK4i constants, as they are bound to be similar in some sense. Our MAXSwerve constants can be found at our github.
During this offseason, my team has also been working on getting a NEO swerve with TTB absolute encoder running and we were pretty successful and were able to get it driving and used 3512 as a reference.
here is a link to our repo, let me know if you have any questions.
P.S. be sure to stay on the “MyFirstBranch” part of the repo as that is the branch where we ended up getting a working drive.
I’d suggest publishing some numbers to a dashboard so you can see more closely. SmartDashboard.putNumber() will work. look at the steering goal, setpoint, and measurement. are they tracking together? look at the controller output. is it trying very hard? this sort of control troubleshooting is an important skill, and looking more closely at the data is the key.
