Requesting Swerve Drive Help and Explanation!

[mrmatheou]

Hello,

I was a long time FIRST mentor that hasn’t been around FIRST the last 8 years but I am helping out my son’s team as their programming coach. We have a mk4i swerve drive with Rev Robotics NeoMotors and CanCoders from CTRE.

I was able to implement the 0toAutonomous sample code that is out there and make our drive train move with our hardware / joystick etc. This is my first time using the command-based programming paradigm using Java.

Although we do get a response from each of the wheels when moving the joystick in each direction, they do not go in the expected direction. Granted, we had to make changes to the code to use the Logitech joystick, use the CANCoders and Sparkmax speed controllers, Gyro (amount other things) but in general we are following the same code.

I have a feeling it has to do with the encoder values. I do not have a firm grasp on how the program is taking the raw data and processing it. I’m assuming that the SwerveModule.java and SwerveSubsytem.java get passed the Absolute Encoder’s values and these and can be used at the “set points” for the turning motors encoders to use to set the turn of that motor. If I am correct, then I think there may be something potentially wrong with what our absolute encoder values are. There is a correction factor used to offset the encoders that are in the constants.java file such as:

kFrontLeftDriveAbsoluteEncoderOffsetRad

but I’m not sure how to determine what values to put there. We have tried a few different values but quite often the wheels of the robot are fighting each other. For example, going forward on the joystick may result in the left front going in the opposite direction of the right front and the robot just skids most of the time no matter what direction is being commanded.

I am included a link to the entire VS project here but the key files would be

SwerveJoystickCmd.java
SwerveModule.java
SwerveSystem.java
Constants.java.

Any help on how to troubleshoot this issue and confirming or correcting my assumption on how the swerve drive works would be greatly appreciated. I’ve tried looking for this issue on CD and the internet in general, I would guess a lot of teams using swerve drive have encountered this but I have not been able to find the info to resolve it for our team.

Also, I have had to comment out some code having to do with odometer, Pose and Pose2d and other items because I think it’s not recognizing the associated imports so any help with that would be great too!

Thanks in advance for any help!

[Durgabo]

looks like the google drive link is not public. It said I had to request access.

[mrmatheou]

Sorry about that. Please try again. View access should be available. Thanks!

[gdefender]

I’m going to start by saying I highly recommend you check out YAGSL instead of writing your own boilerplate code.

That said, it doesn’t look like you’re setting the offset in the SwerveModule code at all. I recommend getting the offsets from the encoders (in rotations), and then using the MagneticOffset feature of the CANCoder.

You’ll also want to look at this document on the WPILib Coordinate System. I don’t have to go any further than your joystick code and kinematics to know you have this wrong. You’re not inverting all of the joystick axes. And your kinematics has the wrong signs.

[mrmatheou]

Thank you so much for your reply!

So I’m definitely not writing our own boilerplate code. (I can appreciate the complexity of this drive system and associated code so that’s something I’d try possibly in the offseason et.) I did come across the YAGSL code when I first started investigating swerve but then I came across the 0ToAutonomous series of YT videos. I modeled the code after this.

I tried to update our parameters to match our robot as best as I could and was hoping it would work. All the motors of each module do turn and spin the wheels, they just don’t work together at this point.

One follow-up question I do have is: how to I go about " getting the offsets from the encoders (in rotations), and then using the MagneticOffset feature of the CANCoder." ? I think that’s probably one of our biggest issues is making sure that the encoders tell the modules to start “straight” and use the “adjusted 0 degrees” as a reference point. I’m just not so sure how to create the offset to make this happen.

Thanks!