Swerve modules not responding to offsets at all?

Technical Java
1

We’re using Democat’s fork of SDS’ swerve-lib and offsets do not seem to be working at all. I’m calling the .withSteerOffset method and giving it our desired offset in radians. However, when we turn it on and enable, we get nothing. No change at all in the orientation of the wheel. We’ve tried waiting, redeploying, power cycling, all of which have still yielded no result. In case I’m just making a stupid mistake, here’s an example of how we’re creating our swerve module:

MkSwerveModuleBuilder backLeft = new MkSwerveModuleBuilder();
backLeft.withGearRatio(L3);
backLeft.withDriveMotor(MotorType.FALCON, ourID);
backLeft.withSteerMotor(MotorType.FALCON, ourSteerId);
backLeft.withSteerOffset(OurOffsetInRadians);
backLeft.withSteerEncoderPort(ourEncoderPort);

SwerveModule backLeft = backLeft.build();
2

You’re missing .withSteerEncoderPort(<port number>)
From our code:

 module = new MkSwerveModuleBuilder()
                .withLayout(tab.getLayout(getKey(), BuiltInLayouts.kList).withSize(2, 4).withPosition(0, 0))
                .withGearRatio(gearing)
                .withDriveMotor(MotorType.NEO, swervePorts.getDrivePort())
                .withSteerMotor(MotorType.NEO, swervePorts.getTurnPort())
                .withSteerEncoderPort(swervePorts.getEncoderPort())
                .withSteerOffset(radOffset)
                .build();
3

Sorry, we have that, I forgot it when I typed the example

4

Post your full code on github. Much easier for others to help.

1 Like
5

Do you have the CanCoders configured for BootToAbsolute? Also, I’ve been learning that you may have to wait 10 seconds after you enable for the offsets to be set correctly, which is weird and I’ve been talking with others about changing that. Alternately, you can call the resetToAbsolute() function on the module on a 1 second delay. See this thread: Democat SDS Swervelib with CANCoders?

6

So should I do something like boot to zero, wait one second, reset to absolute on each CANCoder?

7

No, BootToAbsolute is correct for the CanCoder config, that’s something you set in the CTRE config tool.

Caveat, I have yet to try these solutions out on our own robot later tonight, so I’m going off what I understand from others. The CanCoders need a bit of time to get booted up and so the reset of the encoders needs to be done a bit later than the initialization sequence. You could do it on enable, perhaps, or run a delayed command. Maybe this is what’s going on with your code, maybe not. You should post a GitHub link if you can.

8

Alright, I’ll link code soon. Thanks for your help so far :slight_smile:

9

GitHub - CAVALIER-ROBOTICS/2023_ProblemSolving: This will be swerve in 2017 Here you go :slight_smile:

10

Hey, sorry to take so long to get back to you. I did manage to glance through your code and nothing leapt out at me. I can tell you this, though, we’ve also been struggling with the Democat library and last night we took the plunge and switched over to YAGSL. Within a few hours we had a working swerve. Had to make sure the motor and gyro inversions were correct and if you have your robot on blocks, their driving code doesn’t like it, but it was so simple to get up and running.

This is the key file here.

You can find YAGSL here:

11

Please let me know about the experience and if there’s anything I could have done to make it easier!

(Also don’t be shy to contribute if you find an error, I may make the wiki editable by anyone soon.)

The default control scheme is designed to test your swerve drive, if it works you have configured your swerve drive correctly. The left stick controls translation and right stick controls orientation using gyro.

12

I think that the TeleopDrive command uses field oriented in the example code and when we pasted that in, we didn’t think to switch it off. Your field-oriented mode is actively trying to maintain heading. When the robot is on blocks that confuses it because the gyro won’t be moving. So, we needed to switch to robot-oriented but didn’t realize it. When we used our default driving command that doesn’t do active heading orientation it worked better. We have our field oriented mode on a toggle and use a BooleanSupplier to read it as part of the command, but your example command takes a simple boolean in the constructor. I think we will want to have a test-mode way to try out the drive train that defaults to robot-oriented.

Otherwise, It would be nice to have, for example, configs for known setups like MK4is or at least a list of known changes to make to the defaults? It was a late night, getting this going, but we worked through everything eventually.

But, those are just my notes, really I was super impressed with how easy this was to refactor into our code base and get working. We probably spent most of our time conforming our code to what YAGSL needed than working out config issues, but that’s more of an issue on our side.

1 Like
13

I will probably set up a known working config repo later today and I will be more than happy to include yours as the first contribution!

1 Like
14

You can probably tag it as MK4i, L1 gearing, Pigeon 2 gyro. The key thing was getting the gearing numbers from SDS and then inverting all the motors and ensuring the IMU wasn’t inverted, IIRC. We also adjusted the ramp rates down a bit. Everything else such as CAN IDs, module location and Abs-angles would be robot specific. We didn’t adjust any PID values or other values that just weren’t easily knowable.

1 Like
15

I copied your configs over (I think?) and created the configuration repository here. Hopefully this will help out alot of teams!

Thank you!

1 Like
16

I tried that library and our wheels just spun uncontrollably at high speeds when I pressed the joystick forward on my controller.

17

The default control scheme is left stick controls translation and right stick controls orientation based upon gyro and will spin until it reaches the desired angle. Also I am happy to help you configure it this weekend and you can based on GitHub - BroncBotz3481/YAGSL-Configs: Known working YAGSL Configs for COTS swerve modules.

18

Ours did something similar at first as well. You have to get your motor and encoder inversions correct as well as your absolute encoder offsets. You may want to make sure your encoders don’t have an old config offset setting in Phoenix tuner and restart the robot so they come up as a 0 offset internally. Then get the new offsets.

19

Nvm we got it. Our encoder ticks per rotation were configured incorrectly. Now all we have to do is get the steer angle PID working.