CTRE Swerve API - Module Angle Setpoints Rapidly Flip by 180 Degrees

Hello! My team is having some issues with CTRE’s swerve api. The target angle setpoints of the module rapidly flip by 180 degrees for some reason when we try to control them. Even using setControl with SwerveRequest.PointWheelsAt has this issue. Any idea how to solve this problem? Code is at this link: GitHub - Team5924/FRC-2024 at drive

Thanks!

2 Likes

Have you confirmed that all the CAN IDs of your motors/CANcoders are in the locations you expect them by blinking them one by one using Tuner X? I’m guessing based on your constants that you are using the (non-flipped) Swerve X modules with the 5.14 driver gear ratio, is that correct? Using the Tuner X Swerve generator to only generate the constants for these modules, the only difference I see is that you set the kCoupleRatio to 3.5, but the defaults I got are 8/3. If you change this, does this fix your issue?

When you ran the Tuner X swerve steer verification test, did your steer motors all spin counter-clockwise as seen from the top of the robot? If not, it’s possible that your steer motor invert is incorrect.

I’ve confirmed all CAN ids. You are correct that we’re using SwerveX. Changing kCoupleRatio to the correct value doesn’t change the issue. We had it at the default earlier since it’s optional but also tried manually setting the value.

Yes, we’ve confirmed that the inverts are correct. Since my last post, we have reverted our code to the unmodified code generated by the CTRE Swerve Generator, which has the same issue in real life. The swerve code only works in simulation still.

Try periodically printing the current state of each module’s angle, as well as each module’s CANcoder’s absolute position to the dashboard. Then try to turn each module wheel by hand. Do all the modules report a turn of 360 when rotated once? And do the angles of each module/CANcoder correspond to their expected position?

Yes, they report a 360 and accurately report the position. I’m also outputting the target angle and the current angle and the angle seems to oscillate at a position different from the target angle.

Is your code on GitHub updated? I don’t see where you are doing this, except for within your DriveFieldCentric command, which only prints out the current state and does not output each module’s CANcoder seperately from the module’s current state. Additionally, this being in the command means it will not print out when the robot is disabled, which is part of what I’m trying to figure out.

Yes, it’s been updated but I haven’t pushed that code. Right now it’s also just attempting to set the module angles to pi/2

In Tuner X, for all of your swerve motors and CANCoders, are they all on your CANivore? And if so, did you name your CANivore “drive”? Each device should state this on Tuner X when connected to your robot.

Yes, we did name it “drive,” and they are all on the CANivore.

Update - I used our swerve code from last year that doesn’t use a swerve library and it works on this hardware. So doesn’t seem to be a hardware issue either. Still cannot figure out CTRE Swerve API

Do you have a link to the swerve code that is working that I could look at?

Did you use the ctre project generator directlu or did you try to customize/create your own.

We didn’t know about the generator and had similar problems. All of them stemmed from inconsistant use of inches and meters in the tunerconfig. The one that made our robot work similar to what you are describing is that we decided to make the x an y offset meters as that is what pathplanner and the drove class uses. But we didnt remove the conversion to meters when the drive class was created. This means your swerve modules are on top of each other and all sorts of bad things happen.

I had a similar issue after setting up CTRE swerve, turns out I didn’t know the difference in Clockwise and Counter clockwise. It also helped that I had CTRE swerve generate a new project instead of porting it into one.

1 Like

We tried customization at first, but when that didn’t work, we tried directly using the generated project. Both had the same issue. We’re giving up on using CTRE Swerve API and will just use our own custom code.