Our team is in the process of creating our own swerve base but I am torn on what to use. The 3 main libraries I am aware of are SDS democat, 346 Falcon base converted for Neos, and YAGSDL. We have used both SDS and 346 with varying success, but have yet to try YAGSDL. I’ve been out of the loop for a bit so I’m not sure if any game changing updates have been made to any of these.
My goal is to make something that a new programmer can pick up easily with little experience, but will allow them to have the control needed for more advanced stuff once they get more familiar with programming. One of the main things it needs to be able to do is support odometry and such for path planner.
The one that I am the most interested in learning about would be YAGSDL. Not only cause its new to me, but seems to have grown pretty popular fast, so there has got to be a reason why.
SDS library is no longer maintained, I wouldn’t recommend using it.
I state the following as an author of a swerve library myself, and I have yet to use any of these options, so take everything I say with a grain of salt.
YAGSL has a much lower barrier of entry through its intuitive configuration UI. Based on its features, YAGSL will generally be your best choice if you want the best and most reliable performance, as it utilizes second-order kinematics. Based on your needs, this is likely what you’re looking for, as it is easily usable by pretty much anyone familiar with basic programming, but any advanced programmers can mess with the internal workings of the library, and implement custom things if you want.
364’s swerve has a higher barrier of entry–you do need to know how to write basic code and modify constants. It seems more configurable (as it’s a base code, NOT a library) so you can easily mess with anything you want at all. For the really high level programmers this might be a better option for modifying everything they can with ease.
REV’s swerve is the same story as 364 except it only really applies to MAXSwerve.
Based on what you mentioned, I will definitely try to setup a YAGSL version and compare it to our 364 and see how things work. Our programming group this year are all rookies so having something where people could be able to configure stuff without tons of training would be a godsend.
I will add a caveat to that. We had an already running swerve on a sds mk iv base. As a happy coincidence, their example used the same hardware so there was no tuning required.
The setup took us some days, don’t remember exactly how long. It was fairly involved and took a while to debug and get right, especially because i was doing it and had next to no frc experience lol. It was our first time doing swerve, so that of course will have changed things a bit. We based our code off of 1706’s.
Error- we did not in fact base all our code off of 1706’s. We got a lot from the rev maxswerve template that was ported to python by @virtuald. Sorry for the wrong info.
We took last year’s robot that had Falcon SDS MK4 modules and were able to create a drivable swerve drivetrain subsystem in about 30 minutes using CTRE’s Pheonix Tuner X with Phoenix v6 and their swerve generator. This included the time to update all the hardware to the latest firmware. We were using the 2024 Beta version of WPILib and Pehonix Tuner X. It was about a month ago, so I don’t remember all the details of what we download and from where but it wasn’t too hard to do.
In about 20 minutes were able to integrate Path Planner into the project, but we had help from someone that had already done it before. They started with the CTRE swerve drive example program and copied over a configuration file from the CVTR swerve project that was made with the CTRE Swerve builder. I think they made a couple other minor tweaks and then it was up an running. I don’t have the code with me right now to state exactly what was changed. Here’s a Link to the example code project.
I know we were helped a bit by someone that had already done it, but all and all I thought the CTRE swerve generator was very easy way to get started. So if you have a CTRE based drivetrain, I’d highly recommend it.
I will try to get the code pushed up to github during lunch today and make it public and post the link.
We didn’t attempt to implement anything other than getting it driving and doing a simple path so I’m not sure if there’s any issue with using it in a command-based project. The CommandSwerveDrivetrain is a subsystem so I would think you could just move it into a Subsystems folders and just have to modify a few package definitions.
We also maintain an example project that uses our Swerve Library for reference:
It uses command based programming with the help of the CommandSwerveDrivetrain helper class
This along with the documentation we provide is meant to cover enough to get you up and running, let us know if you’ve got any questions!
Here is the link to our code. It’s basically CVTRE’s SwerveWithPathPlanner example code with a couple of modifications. The TunerConstants.java file was copied over from the project created from the Swerve Project Generator.
I appreciate your answering. I have seen a post on CD showing that tuner can help tune the motor constants like kV, kS, kA, and PID, is that true? Or I need to use advantage scope to tune those constants.
Yep! You’ll probably want to look at how to use the config, plot, and control page on Tuner X.
The general idea is that you can control a device (either through Tuner or through your robot code), and plot the signals you care about (Position, Velocity, Acceleration, Closed Loop Error, Closed Loop Proportional Output, Closed Loop Integral Output, etc). Then you can change the PID gains on the fly with the config tab and see if the new PID gains are closer to what you want.
Once you’re happy with the results, you copy the gains to your robot code and you’re done.
General Tuner X documentation that covers how to use the pages: