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:
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?
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.
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.
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.
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.
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.
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.