so we’re trying to get our swerve running on our robot and we’ve found that one drive motor is running slower than all the others. I’ve already tried replacing the spark max and neo. Our code uses yagsl (currently version 2024.4.8.3). There are no differences between the config jsons that shouldn’t be there.
code:
GitHub - 3100-Robotics/robot-2024: code for our 2024 robot
any ideas on why this is happening?
Lmk when you solve it 
1 Like
ok so update, turning off cosine compensation fixed the weird speed issues but we’ve realized we have a different problem. when we try and drive forward all the wheels will point sideways with the front wheels having the bottom rotate in and the back wheels having the bottom rotate out.
1 Like
You’re using MAXSwerve right?
MAXSwerve needs the absolute encoder offset to be +/- 90 to achieve correct orientations. (I have no clue why, but it’s a thing…) Rotate the absolute encod3r offsets by 90 to make them all spin forwards when you want it to go forwards.
you do realize that I was the one to tell you that right? That only applies if you use the brackets that come with maxswerve to align it because they make the wheels point in one direction relative to the corner of the module instead of all pointing forwards.
as for my problem, we eventually got it mostly working by adding 180 degrees to the offsets of the front left module and the back right module. Though now we have a different problem (doesn’t stop the robot from driving just lowers performace)
if we drive the robot forward a little bit, stop, then drive to the side, the robot will actually drive towards the other side or a very short amount of time, then reverse direction and drive the correct way. Almost seems that it is initially guessing that it should go one way, realizes that it shouldn’t, then corrects itself. Ideas?
Sorry i forgot that you were the one to tell me. I thought it was Technologyman! 
i still have no idea why this is necessary, leading guess is the mounting of the throughbores but idk why.
This makes absolutely no sense since that logic isn’t conditional anywhere? Is it a little bit like all modules rotated 360deg or something of that manner.
Shouldn’t be that. These are mechanically exactly the same as the ones we used in the offseason.
no IIRC the drive motors themselves are the ones that are reversing direction.
1 Like
Posting here just for ease later.
The only thing that I know of right now that could cause this is some kind of filter on controller inputs (like SlewRateLimiters), but that doesn’t fit your description perfectly.
I just simulated your code to try to find an answer and came up with nothing. You should update your version of YAGSL and disable cosine compensation to see if that works.
Disable cosine compensation with SwerveDrive
It’s because REV created a single calibration tool, so all modules are calibrated to the same position. However, when they’re installed on a robot, the modules end up pointing in different directions, because each module is in a different orientation. So for MAXSwerve an offset in code must be used.
I think it would be nice to have a similar tool for SDS modules as well.
I have the offsets for MAXSwerve in PurpleLib.
I actually like this system, as it simplifies setting the modules to a “locked” position as well, and it’s trivial to add/subtract an offset to your rotation. For example, to lock into a circle/diamond, I can just set the lock position to Pi / 4, and the offsets take care of offsetting it to be correct for each module.
1 Like
I have already done both those things I’ve just not pushed them to the outside world of github yet.
1 Like
Lmk on discord what’s going on. This case is very odd especially since you are capable and should have been able to solve this on your own.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.