Swerve Programming Help

Hi, I’m trying to get a head start on some code for our robot this year as we don’t have enough people for a “full time” programmer, so keep in mind that I am by no means experienced.

We are running the REV MAXSwerve Drivetrain with a Pigeon 2.0.

I had working swerve code this summer for our practice drivetrain, but we had been running the WPI_PigeonIMU (which as I understand is just the Pigeon) and I changed my code to work with a Pigeon 2.0

Any and all help is appreciated, I want to produce the best code I can for our team. So feel free to criticize all you want. I want to improve!

Here is my github repository link:

It looks like a good foundation to me. If you run into any trouble, post it here and we’ll try to help!

Oh sorry, It isn’t super clear in the original post, but I am having issues with the Pigeon 2 code. Idk what I should be using to get it to not “error out” right now where I am establishing the field relative code in the Swerve Subsystem I have errors

I pulled the code down, and the first thing I noticed is that you’re still using WPILib 2023. You should update ASAP. You have the 2024 version of Phoenix, and that won’t work with WPILib 2024. Besides, you’ll need to upgrade before competition, and the sooner you do it, the less code you’ll have to upgrade.

I see a couple things in the lines you’re asking about:

var swerveModuleStates = DriveConstants.kDriveKinematics.toSwerveModuleStates(
    fieldRelative
        ? ChassisSpeeds.fromFieldRelativeSpeeds(xSpeed.getX(), ySpeed.getY(), rot, m_gyro.getYaw())
        : new ChassisSpeeds(xSpeed.getX(), ySpeed.getY(), rot));

First, you changed the variables that the code is using for X, Y, and rotation speed. I didn’t dive into the code, but I think it’s safe to change it back to using the same values as REV’s template.
Second, the gyro rotation argument needs to be a Rotation2d object. Pigeon2 has a getRotation2d() method, you used it other places.
Try this:

DriveConstants.kDriveKinematics.toSwerveModuleStates(
    fieldRelative
        ? ChassisSpeeds.fromFieldRelativeSpeeds(xSpeedDelivered, ySpeedDelivered, rotDelivered, m_gyro.getRotation2d())
        : new ChassisSpeeds(xSpeedDelivered, ySpeedDelivered, rotDelivered));

I also noticed the code in getHeading() doesn’t match the comment. Rotation returned from the Pigeon will be continuous, meaning after 180° it returns 181° not -179°.

/**
 * Returns the heading of the robot.
 *
 * @return the robot's heading in degrees, from -180 to 180
 */
public double getHeading() {
  return m_gyro.getRotation2d().getDegrees();
}

You can solve this with this code:

public double getHeading() {
  return Math.IEEEremainder(m_gyro.getRotation2d().getDegrees(), 360);
}

If you aren’t already too committed to current approach, I suggest using YAGSL. I set it up during the off season of 2023 and it took about a week to setup (Would’ve taken a day without user error). It’s got great documentation and is a super simple way to setup swerve. @nstrike is the owner (I believe) so if you do decide to use yagsl, he’d be a great help.

1 Like

Thank you so much! I cannot overstate how much I appreciate you taking the time to pull my code and take a look. Both of the suggestions you made seem to work perfectly. I see what you mean now about the getHeading code, I probably should have caught that earlier. Thanks again!

I am not quite sure what TAGSL is, but I will look into it as soon as I get a free moment away from building our actual robot for the year. What is the advantage to that over the “REV” swerve code? Is it just easier or is there a different more important reason that I should be using it for my swerve code? Thanks for the response though, I will definitely have to take a look!

My team has used 3 different methods of making swerve in the past 2 years: swervedrivespecialties library, YAGSL, and the CTRE swerve generator. The advantages of YAGSL is that it’s compatible and easy to setup with any configuration. CTRE is nice and much quicker but only works when you have all CTRE devices on your drive base. Plus my team has been having trouble getting it to work with autos because of the way it is structured. YAGSL is great because all you have to do is copy the project from their CD thread then change the values in the configuration files. I’m not familiar with the REV swerve code so I can’t say it’s better but it’s definitely a great option if you haven’t picked a library.

We’ve got MAXSwerve support in PurpleLib.

Our team doesn’t use a Pigeon, but it should work just fine. Added benefit is AdvantageKit logging is built in.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.