We finished building and wiring up our drive base yesterday for swerve but are running into some strange errors. We switched out our NEO V1.1 drive motors for NEO Vortex motors on kickoff and are now having some problems. When we test out the drivebase, all the swerve wheels spin mostly as expected, but they do not turn or orient. When we first flash a motor controller, we see some movement from the module turning the wheel, but then it fails to react to any further commands (either from the controller or just hardcoding the module orientations in an autonomous command). When touching the steering motors, we can feel that they are in use and being actively held in place.
We’ve verified that all of the motors are connected through CAN and have tried swapping out motor controllers and motors to no avail (not that we expected it to work since all 4 modules have the same issue).
Logically, this seems like a code issue but the code we are using is basically straight from last year’s robot, just with the game specific bits stripped out, and changing our drive motors from SparkMax’s / V1.1s to SparkFlex’s / Vortex’s (and it’s the steering motors we are having trouble with anyways, not the drive motors). The code base we are using is posted here on our github. The code actually on the robot is identical to what’s on github other than changing the drive motors in our SwerveModule class to SparkFlex’s by uncommenting the lines linked. This code was originally built on the MaxSwerve library and the swerve logic remains intact, other than some refactoring/renaming for clarity. We extracted out the important commands from our code last year and made this library as a starting point for future seasons, but also tried using last year’s code on the robot and encountered the same issue.
TLDR: Drive motors for swerve work, but the steering motors don’t turn at all unless they were just flashed. It’s not a CAN issue and the code was used last year so it’s probably not that either. Is there some configuration step we might have missed for our spark maxes or any other potential root causes for this? What debugging steps could we try next to try and diagnose this issue? Is there something we are missing in the code for changing the drive motors from V1.1’s to Vortex’s (that would only impact the steering motors for some reason)? Any input or advice would be greatly appreciated as the students and I spent a couple hours trying to figure this out without making any progress.
You need to use the new Rev libraries and firmware.
For example you still have CanSparkMax - it is now SparkMax.
SparkPIDController is now SparkClosedLoopController.
Plus configuration is very different.
1 Like
We haven’t yet updated to the 2025 versions of everything - our plan was to verify that everything was in working order before refactoring and updating. Any ideas on what could cause just the steering motors to hold steady (or some troubleshooting next steps)? Any advice is greatly appreciated
With the robot disabled and on blocks, turn each wheel by hand and check that the display shows them increasing positive for what would be a robot left turn. Also that they display from 0 to 360 or ±180 in degrees (2 pi in radians)
If that works, enable the robot, which should put the wheels in a position lock and you shouldn’t be able to turn them by hand. Be very careful trying the latter.
Also check the gyro
1 Like
Thanks for the tips. Though I forgot to mention it in my post, we did verify that the absolute encoders were seeing the current state of the wheels (and set all of the zero points).
Would an issue with our gyro cause this? It’s not something we’ve looked into yet, but shouldn’t the wheels still turn side to side when trying to rotate in place or strafe side to side even without a functional sweve?
The gyro wouldn’t cause this. I don’t see much display code in your project. You need to add some SmartDashboard.putNumber instructions.
Also Check the SparkMax lights for error indications.
1 Like
Thanks for the advice. What sorts of things should we be logging / looking at on smart dashboard?
All the lights on the spark maxes/flexes show as expected
You need to display the actual angle from the angle encoder.
Something like this in DriveSubsystem periodic()
SmartDashboard.putNumber(“FLActualAngle”, frontLeftModule.getPosition().angle.getRadians());
You also want the target angle being sent to each module.
Typically we add this to the SwerveModule
public double getTargetAngle(){
return desiredState.angle.getRadians();
}
Then this to DriveSubsystem periodic()
SmartDashboard.putNumber(“FLTargetAngle”, frontLeftModule.getTargetAngle());
1 Like
You’re using .getRightX() a lot in your drive default command. We’ve had problems with some gamepads not recognizing that and had to change to getRawAxis(2) or (4)
drive(-getLeftY(), getLeft(X),getRightX())
would be a typical swerve jog
We added in logs yesterday and can see that the target angle is being set as expected and that the absolute encoders are detecting a different angle. I am at a loss for what could be causing our steering modules to lock on to an incorrect angle
Do you have any offsets in your absolute encoder?
How far apart are target and actual and is that consistent for any target?
1 Like
The targets move around as we expect they would as we move our joystick around in a circle. The actual’s are all around either 0/2pi or pi/2 radians and all the modules face the same direction, not moving at all to match the actuals. We do have offsets build in to the code and can see the adjustments for those
Try setting the turningConfig.positionWrappingInputRange to
-turningFactor/2, turningFactor/2 instead of 0, turningFactor
Why do you have chassis angular offsets specific to each module and 90 degrees apart?
The only angular offset should be the difference between the absolute encoder reading with the swerve wheels lined up straight and 0.
The REV MaxSwerve modules ship with a form that fits over the module and locks the wheels facing to the left. That form lets you ensure each angle is lined up exactly 90 degrees offset from the ones next to it. That way, instead of manually finding the offset, you can just set them according to how much they are rotated from the starting one (so the wheels in the form don’t line up straight, but are not straight in a predictable pattern).
We did end up finding the problem though. We had rewired our motor controllers to use powerpole connectors instead of wagos, and apparently we had faulty connections in all of them. We ended up rewiring everything and now the robot drives as expected. Thank you so much for your help. Your suggestion to add logging on the desired and actual states was what lead us to look in the correct direction.
Glad you figured it out. Good luck this year.