Decision on swerve

Our team is thinking about using swerve for the (Hopefully occuring) 2021 game if it would provide a significant advantage. Is there anything that we should consider before trying it, and what should we be aware of if we do it?


Do not try swerve for the first time during a competition season. If possible (probably not soon with everything going on) make a summer/fall swerve bot. My team did this Summer 2019 and we found that our slightly modified COTS Swerve modules had more maintenance issues that needed to be resolved before it was viable for us. If we had done the same during a competition season we would have been stuck with a very unreliable drivetrain. Also keep in mind that swerve is more challenging to program than most drivetrains so if your team doesn’t have a ton of programming experience it will be challenge.


Teams like 1323, 2767, and 2910 didnt become swerve masters overnight. It took them years to design and master not only the development (both mechanically and programmatically), but also in driving it. Even the best robots can get bogged down by inexperienced drivers.

Youll need spares, more than you would with a WCD. While a bit extreme, 2910 went through 7 NEO’s alone during 1 event in 2019 because it kept shearing the motors scoring in the cargoship. Its also not uncommon to see whole modules being replaced, which should also influence how you design around the robot itself to give easy access.


Thank you. We were planning on trying it out during the off-season, but obviously that’s not the most reasonable thing at this time. Thanks for the heads up! As for programming, several of our programmers are obsessed with it, and while I can’t speak for their abilities, they have spent a lot of time looking into the code.

1 Like

Ok, I didn’t realize how much of an issue replacing motors were. We were anticipating (for no particular reason) 2-3 failed modules during a competition, and planned on bringing around 4-5.

Also we were hoping to manufacture our own swerve modules. Do you think it would be best to try and design one from scratch, or base it off of existing designs?

Here’s my response from another thread:

It’s possible to do, but you’ll have to give your programmers lots of time with a breadboard, and give them time to make it work on the actual robot when it’s ready to go on.

We’ve had success with the AndyMark modules. One the benefits of those is that in 2018 we got them less than a week after kick off and that allowed the programmers to start testing with them right away. If you want to machine them, then IMO you need to make ones to practice with before build season so the programmers can practice with the swerve modules.

1 Like

Of course! Programming swerve can be challenging but it is documented on the internet and if your programmers are as enthusiastic as you said I’m sure it wouldn’t be too much trouble. An offseason test robot, if possible, is definitely the way to go. As @MikLast said, its not a quick road to success but if your team can balance driver training and development it is definitely worthwhile.

1 Like

Thank you, we were planning on having all the kinks worked out during the off-season started so it would be as painless as possible during build season. One of our worries with using a COTS solution is the price, as they can get pretty pricy for just 4, not even including spares or anything. Could you give any advice for the cost in particular? Also seeing that you are a programmer, what specific issues did you have with programming swerve?

1072 practiced with swerve in the 2020 preseason, and implemented it for the robot this season. Some lessons:

  1. Absolutely go COTS. The ability to buy more modules at any time is great. We bought 4 to practice with in the preseason, then 4 fresh ones during the season for the competition robot. I would say that 8 modules is a minimum, and ideally you should own 12 so that you can keep a chassis for programming and spares at all times. Buy an extra set of 4 wheels and plenty of tread to keep your supply topped up- you have to replace all 4 wheels at once.

  2. Use the WPIlib kinematics, motion profiling, and odometry libraries. Odometry especially was very painless. MP took a while to understand how paths were generated, but once we got a hang of it, making paths wasn’t too difficult. The high software barrier to entry is all but gone now, and combined with great COTS mechanical solutions, swerve is a much smaller challenge than it once was.

  3. WCP Falcon Swerve and SDS MK2 modules are the only modules I would consider. Custom offers few advantages and is much more effort for a beginner, especially in the early weeks of the season when there’s a lot to do. Both of those options are tried-and-true. We went with WCP v1 modules because of their lower cost, availability in the preseason, and possibility of upgrades to Falcon in the future.

  4. Loctite EVERYTHING. We had a lot of screws fall out of our modules. If you don’t loctite your modules, you’re practically asking for things to fall apart while you drive. Loctite them with blue or red Loctite on initial assembly.

Overall, I was pretty pleased with our choice to go with swerve, but it definitely took a lot of effort to get going. If your setup isn’t at 100% before the season starts, swallow your pride and go with WCD. One of the reasons we selected swerve was because it typically took us 2-3 weeks in the past to get going with a WCD. The swerve was driving about 10 days into the build season. Not the fastest, but also not nearly as bad as swerve was even four years ago.


In 2018, we tried to use the MA3 absolute encoders using a PID loop on the Talon itself, but the MA3 encoders have a weird deadzone, so you can’t run the PID on the talon. More info here: How to measure angles larger than 360 degrees by MA3 encoder?
We ended up using the MA3 encoder to zero our quad encoder, which is built into the AndyMark modules and then still used the PID loop on the talon. If we wanted to, we could do a PID loop on the RIO using just the MA3 encoder, but I’m happy with our solution.

We also had many other problems that were solved quickly, but that’s going to happen when you’re doing anything new, no matter how much research you do on it. That’s why I have to stress that getting programmers time to practice with new stuff is important. Since you’re doing this in the off-season, it sounds like that won’t be a problem.


Thanks for the tip!

Do you have any good documentation to look at for the WPILib motion profiling, kinematics, and odometer? I’ve never been able to find those and get them to work so I’ve always had to resort to custom coding these functions.

1 Like

WPIlib has some examples here, we worked off those and added a wrapper class I believe. It looks like our Github is private at the moment, but we should be making it public at some point.

EDIT: Here’s the tutorial for making a Trajectory that we used. The basic concept is to generate a trajectory and tell the modules to follow it, then add an extra target velocity to each module based on the “true” position of the robot. If the odometry says we’re -0.1m off in the x direction, we add a small positive x vector to the Trajectory-commanded velocity vector for each module.

Kinematics and odometry
Motion profiling

1 Like

Thanks! I don’t think I ever properly went through the actual documentation pages…looks like WPILib’s added most of the code we’d require.


That’s interesting… we’ve run our MA3 encoders on Talon SRX’s with our swerve and never had any issues that I know of. For reference we have run the Swerve Specialties MK1 for a couple of competitions now, the only change being NEO’s instead of cims for the drive motors at our latest competition.

I can’t recommend the Swerve Specialties modules enough though, they’ve been great for us and are so easy to get running. The hardest part is, as mentioned by most, the programming. But we were able to get our drive entirely re-written in about 2 days using the new WPI libraries.

1 Like

I would like to reiterate that this is a highly unusual situation caused by the specific geometry of the bumper cut outs in the game elements and our lack of planning for them in our robot design. 2910 has used swerve in the past 18 competitions (off-seasons included) and I am confident saying that in the majority of them we didn’t replace any motors on the swerve modules.


To piggy back onto this. 1323 has used swerve drives in 2015, 2017, 2018 and 2019 and we’ve never swapped out a motor or module on the competition robot.

The most we’ve had to do is switch out tread or wheels. We’ve tried to use the biggest and widest wheel that fits to help with better auto position and wheel wear.

To add to this discussion I’d recommend running steel gears on the practice robot and aluminum on competition (steel if weight isn’t an issue). The brushless motors really chew through the driving gears (rotation looks brand new).