I’m a mentor in the third year Team 9100, and this year we wanted to build a swerve robot. In order to have as much done in this new venture before the January 4 FRC kickoff, we opted for a Swerve Drive Specialties MK4n kit ordered through AndyMark, and REV Neo Vortex motors with integrated Spark Flex motor controllers because they were the only ones that were in stock. Our initial research suggested a slight preference for Kraken X60 motors, but these were backordered, and we didn’t want to risk fulfillment delays. The Spark Flex controllers each have an integrated encoder, and we bought a Through Bore Encoder for the steering shaft.
We assembled the four swerve modules without much trouble (SDS’s instructions were almost flawless) and used 1”x2” aluminum extrusions with pre-drilled holes to create a 29” square swerve robot. I will use the REV client App to test each module early this week but I don’t anticipate any problems (famous last words ).
Now the hard part. We’re a small team (2 mentors – Al and myself) and I do the programming. I’m basically a C/C++ programmer – not a great one but I get the job done. For this year I just want to get a basic joystick-controlled “robot-centric-view” operation working. “Field-centric-view” will be for another year unless it’s not too difficult. We have a navX2-MXP that I used last year to keep our tank-drive robot moving straight in autonomous mode.
I looked around on the Internet and Chief Delphi for some example C++ code and found a few things that could be adapted, but before I plunge in to any of them, I wanted to get some advice from teams that have used REV motors/controllers in a C++ swerve drive robot. There was a code template for REV’s MaxSwerve, but it seems to be specifically for REV swerve kits and older motors/controllers; navX2-MXP has a C++ example for field-centric-drive, but it assumes Mecanum /drive and is 7 years old; there’s “Yet Another Generic Swerve Library (YAGSL),” but it’s written in Java. Finally, there is the “SwerveBot” example code in WPILib, which seems promising. It would be nice to have some written documentation to help navigate through the code and customize it.
Any guidance and/or example code would be greatly appreciated.
Thanks for responding, Nathan and Skyehawk. I’m not familiar with the capabilities of YAGSL. Is it easy to get a robot up and running with Field Centric Drive using YAGSL? Is there ample documentation and/or tutorials to get somebody started? Is it widely used? If there’s nothing comparable in C++, I’d give Java some thought.
For C++, the SparkMax Template is the only thing that comes to mind. You’d need to tweak a few lines to switch from SparkMax controllers to SparkFlex controllers, but it shouldn’t be too much work.
I second this. While C++ is a great language, I highly recommend switching to Java for FRC because:
It’s easier for students to learn.
Your students can earn an AP Computer Science A score for free .
Since the vast majority of teams use Java, you’ll get more support and access to a wider range of codebases.
If you’re open to switching to Java, YAGSL is your best bet.
Yes, and without having to write a single line of code.
YAGSL is the most well-documented swerve drive library out there, which is a big part of its success. There’s a complete guide on setting it up, fine-tuning the gains, and some really helpful troubleshooting tips.
i wrote dead simple cpp swerve code for mk4i regular neo that uses the neo relative encoder instead of cancoders. it might be a good starting point for you
it does initialize a pigeon2 gyro, but it has like zero references since there is no pose estimator so you can just delete that
I’d also recommend switching to Java. There’s so much inertia with java in FRC, there are tons of libraries and modules you’d likely have to port over. I don’t think the juice is worth the squeeze. (And I come from a C++/C# background)
The languages are very close in structure as well.
Thanks, catrix and LPryor, you make compelling arguments for switching to Java, especially since it makes YAGSL available. I may give that a try. Thanks, nevadexehs, for your C++ solution. I’ll look into that as well. Lots to chew on.
Good luck - my argument is always that FRC is hard enough without introducing handicaps! So I always say go for the path of least resistance, and innovate elsewhere.
I can also say the NSTRIKE does a phenomenal job of supporting teams with YAGSL, so if you go that route you are in good hands.
I’m with @LPryor here - coming from some previous teams that were C++, it was swimming upstream the whole way. The communal knowledge in FRC is too strong in the Java area to not take advantage of that. That’s coming from an old C UNIX kernel guy - sometimes you just gotta get on the train and my current teams are all Java.
YAGSL is your most likely ticket to success - no need to re-invent the wheel (I was part of a swerve drive effort more than 1/2 a decade ago in C++ and it was a lot of work to get right - not that complicated once you get the math in your head but not trivial because we were mostly alone it seemed).
Swerve is a solved problem now and there is some great stuff out there so leverage your resources and grab it IMO.
Which drive gearing did you run? IMO L2+ is not great with vortex as their low end torque did not seem to allow it to accelerate quickly and that also led to it having an insanely fast top end. L2 is probably a solid starting place for speed and acceleration.
Thanks, zog. I’m convinced. I’ve already started to jump in with YAGSL and Java, looking at various tutorials and the YAGSL documentation. Thanks, everybody. The FIRST community is very helpful, especially to new teams.
I got to the part where I have to load the vendor dependencies (Dependency Installation | YAGSL). After each dependency in the list prior to YAGSL, I successfully rebuilt the project. However, after specifying https://broncbotz3481.github.io/YAGSL-Lib/yagsl/yagsl.json as the location for the YAGSL dependency in “install new libraries online,” I get the following error when I rebuild the project:
… An exception occurred applying plugin request [id: ‘edu.wpi.first.GradleRIO’, version: ‘2024.3.1’]. Failed to apply plugin class ‘edu.wpi.first.gradlerio.wpi.WPIPlugin’. Could not create an instance of type edu.wpi.first.gradlerio.wpi.WPIExtension. Vendor Dependency YAGSL has invalid year 2025. Expected to be 2024. Reach out to the vendor to get a new version of the dependency.
From what I can make of the error the build expects a 2024 version of YAGSL, but the json file specifies version 25.1.1. I’ve been trying to find a 2024 version of a YAGSL json file that I can use to hopefully satisfy gradle, but I can’t find anything on the YAGSL website or anywhere else. I’m using the 2024 version of WPIlib so I can get a headstart on getting swervedrive working before the January 4 kickoff.
Any help is greatly appreciated, Ray Kimber, Team 9100
I did not know those youtube tutorials existed! Thats so awesome!
Anyways, YAGSL is updated to the 2025 season as it starts in a few short weeks and there have been alot of great changes from everyone! My personal favorite change to YAGSL is the addition of SwerveInputStream which makes controlling swerve drives a breeze for most teams! We also integrated the amazing maple-sim into YAGSL for physics simulation which adds a necessary layer of realism to sim.
I would highly encourage you to try out the beta if you’re not working with a real robot. If you are working with a real robot take a good look at the changes to REVLib just so you are the shellshocked come kickoff.
Thanks, nstrike. I’m hoping the tutorials, YAGSL instruction doc and a little help from all the good people of FRC get me up and running with our swervedrive. I realize that I’ll have to update all the vendor libs again, but using the 2024 versions allow me to get started now. Can’t wait for the new features!
).
.