MinSwerve: A swerve module for (almost) anyone

Everyone wants swerve. Teams with swerve want more, teams without want something.
However, given the continuing supply chain limitations, even on a good day a complete MaxSwerve chassis is over $2k. That’s a significant chunk of change for just about any team.

My team personally struggled during the 2023 season to get a well driven swerve drive, and didn’t have any time to implement any more complex autos or auto-alignment algorithms.
While the details of that are better saved for another day, a large factor came from the fact that we didn’t have time to test our modules and a robot in the offseason.
I saw a gap there that I could try to solve. Over the summer I designed and prototyped a small module, cheap enough to not make a major impact on our budget.

Enter MinSwerve. A largely 3D printed swerve module, designed to be compatible with a FRC control system, without costing an arm and a leg.

All of the parts for the testing module pictured were printed on consumer Ender 5 printers, using regular PLA.
Weighing in at around ~600g and 5"x5" per module, it’s small enough to be built into a FTC sized frame.

I only currently have the single module printed, but plan to print a full chassis worth and install a full FRC control system (minus the battery) for testing.

This gives drivers a chance to get used to the feeling of swerve and how to best take advantage of it as compared to tank drive, and gives programmers a small chassis that they can still test their real autoalignment or autonomous code with.

Will this replace an identical second robot or chassis? No.
For low resource teams, or teams that don’t have the room for a second robot? I hope this makes an impact for them.

A full BOM can be found here, and outlines the pricing for a full chassis of modules.

The JGB37-520 serving as the drive motor uses the same spur gearboxes as FTC motors, just with a smaller base motor driving it. It also includes a quadrature encoder that can be wired to a TalonSRX or Spark Max to provide odometry information.

While the yellow TT motor is often rated to only run at 6-9V DC, I’ve run them off of a 3S Lipo without clear issues. Given that this motor should seldom need to run at full speed, the cost and weight tradeoff felt reasonable.
Due to the weight of the SLA batteries used in FRC, I would recommend the usage of a 3S lipo or similar until more testing has been performed.

The AS5600 absolute encoder is a nearly identical chip to what is used in the Thriftybot Absolute Encoder, meaning that code is directly compatible. The breakout boards linked do require slight modification to allow for analog output, which requires removing one of the SMD configuration resistors.

While I haven’t yet been able to perform long term testing on the module, I decided to release it now in order to gather feedback and allow other teams to perform testing if they so desire.

A .step file can be found here. I designed this in Solidworks, but if there’s a way to convert the source files to a more open CAD platform like Onshape I’m all ears.


Woah amazing job, very nice! Can’t wait to see how it performs as a full 4-module swerve drive!!! :heart:


GOATED!!! Great work

Thoroughly enjoy this design!

Since you are 3D printing the gears, have you considered using a herringbone-style gear instead of a normal version?


same for helical bevel gears, that would be really cool.

1 Like

As I make the transition over to Onshape with the rest of my team, I’ll likely end up remodeling it to include both the herringbone gears and helical bevel gears.
My initial focus was on getting something built using a basic geartrain, but using those gear sets would probably help with torque and long term wear, since this is designed to be largely PLA.

Have you looked into the possibility of using a continuous rotation servo for steering and one of the FTC-legal motors (AM, Rev, GoBilda) for driving? This might actually be a really nice module for FTC if it can be adapted to use FTC components.


I don’t see why it couldn’t be done. I don’t have easy access to continuous rotation servos at the moment, but if I could find a Rev SRS, I could probably try it with the tons of Rev Smart Servos we have floating around the shop.

The gearbox on the drive motor is the exact same one used in the AM NeveRest classics, although that speed would be painfully slow. It could easily be adapted to work with the planetary offerings from the various brands. Their hex output shafts would also likely remove the need for a shaft adapter. The increased height of the motor would however require a flip to the top side, like in a SDS MK4 module.

Only concern there might be the usage of the AS5600 absolute angle encoders. They can provide an analog output that could be fed into the Control Hub, but I’m not sure about the legality there. FTC COTS rules seem to be a whole can of worms.

1 Like

I’m working with the same AS5600 modules. Is there a reason you’re not using the I2C interface?

I2C has a really bad time in frc at least, so I’d advise against this.


This counts as a valid SENSOR as it conforms to <RE05c>, <RE11a>, and does not fall under <RE16>


re i2c being bad, I’m aware of the issue with the main i2c port, but I thought that the mxp port was free of that issue, and I’ve used it without trouble. could you say more about the issues you’re thinking of?

The mxp port has separate issues. It’s been known to have long delays when reading from it. My general rule is avoid it entirely.


It’s also my first time hearing that the mxp had a issue big enough to not use it. There some where you can point to read up on it?

I can’t find the original thread, and it also looks like WPIlib is not updated: Known Issues — FIRST Robotics Competition documentation

Basically just don’t use the MXP I2C, making too many reads from it causes it to freeze up.

1 Like

OOOH so I2C over mxp, not mxp port itself? I was about to say, do we need to change off of the navx.

1 Like

Other than the variety of issues with using i2c from the RoboRio, the commonly available breakout boards don’t use the AS5600L variety, which means that all the chips are hardcoded to the same address. This would limit you to only using 1 encoder.

The analog output seems to work alright for the Thriftybot Absolute Magnetic Encoder. If it works fine for them, I don’t see why it wouldn’t work here.

1 Like

I agree that this is an issue in FRC, but there shouldn’t be! I2C is an industry standard bus and implemented successfully everywhere. So why is it so poorly done in FRC?

Hopefully the new controller will finally get it right.

[Edit] After reading past your post, I see that my reply is basically a redundant rant. Sorry.


yeah, I get that, we use analog encoders everywhere, and we’re not super happy about noise.

I think this is the thread about i2c mxp.

1 Like