Team 5402 did Swerve Drive for the First time this last season. We are using Team 364’s Swerve drive base code for our robot. But, I hate the fact that I do not know 100% how it works. It makes it difficult to debug problems. Does anyone have any great resources on how to make one by myself? I see some WPILib documentation but perhaps does someone have a flowchart on how it works or a visual representation? Or really any help at all on how it works so I can make the subsystem by myself?
Enjoy. It’s a fun project.
1 Like
To paraphrase Carl Sagan “If you wish to build a swerve drive from scratch, you must first invent the universe.”
2 Likes
Yeah it definitely appears so. I definitely do not have enough time to implement all of that math accurately in the time I have. I was more looking to use the WPILib methods. Like a flowchart of having all those ties together. The documentation is there I just need a little push to get my head grinding.
Our team did the same thing this year. I highly recommend this video. We used a combination of that, WPILib documentation, and looking at YAGSL code to figure out how to program swerve drive. I initially just used YAGSL, but I ran into the same problem of not knowing how it works, so I decided to write it from scratch. By no means am I saying that the way I did it is the right way to do things, but it just seemed the most intuitive to me, so here’s a link to the GitHub Repo.
Anyway, here’s my understanding of how swerve works. You first start with the x, y, and turn speeds from the joystick, and pass those into a controller class, SwerveJoystick in my case (probably not the best name, but whatever). Those speeds are then manipulated with throttle limiters and slew rate limiters. I also implemented a way to use different speeds if a certain button was pressed to give the drivers more control without sacrificing speed. The three velocities are then converted to a ChassisSpeeds object, then into an array of SwerveModuleState. Thankfully, these states are generated automatically based on the characteristics of your swerve drive, so you don’t have to do any of the math yourself.
The Swerve class contains 4 instances of SwerveModule (both custom classes, Swerve extends SubsystemBase) and some methods to control everything. The main control method is SetModuleStates(), which sets references for positional and velocity PID controllers on each motor controller.
The video linked above explains everything a lot better than I can, but hopefully this helps a little. Again, the GitHub for our swerve robot is linked above, which is a very barebones implementation of swerve. It takes a lot of testing, troubleshooting, and tuning, but, in my opinion, creating your own swerve drive code is absolutely worth it.
2 Likes
My recommendation that worked great for me: look at other team’s custom swerve implementations. Or if your team has done it before, look at that code. 364’s base is very well-written and a great resource for researching swerve code.
My team has two available Mk4i code bases that you can see (2022-Season and 2023-ChargedUp on The Beak Squad · GitHub). And I can try my best to explain everything from the ground up if you’d like.
1 Like
The way hochstetjac33 explained it was pretty good. I think I get more hung up about the whole “2D libraries” (like Pose2D and Translation2D) the most. I would like to make sure my implementation works with pathplanner. Any resources on how those work? I will definitely take a look at the code whenever I have time.
I don’t have any resources, but I think the 0-to-Autonomous series covers PathPlanner? If not I’m happy to explain that too (I went over it with 1038 this season, so if they’re active here ask them as well).
Additionally what confuses you about Pose2d and Translation2d? Translation2d is effectively an (x, y) point represented as a class, usually representing how far the robot is from its starting point. Pose2d is a combination of a Rotation2d (angle) and Translation2d, ultimately representing the robot’s position on the field as well as which way it’s facing. These two are independent in a swerve robot, as it can drive in any direction no matter which way it’s facing.
I was re-reading the documentation to see what I did not understand. One was what units it uses but after re-reading it it says meters (Ofc it does. Don’t know why I didn’t think of it!) Another part was how Pathplanner wanted the pose but I think I understand that now after taking a hard look at the documentation. I think I have a good starting point for this to work. It was just a big project with a bunch of smaller steps that seemed very overwhelming. Thank you for your help!
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.