Low Cost, Traction Swerve

Over the past summer, 5205, Full Metal Jackets out of Concord, MI decided to hop on the swerve bandwagon and start prototyping our take on a Swerve Drive design. Our goal was to make a dirt cheap swerve drive with little to no compromises. That meant no complicated machined parts, no custom gear sets. Everything had to be off the shelf. What we came up with is similar to the design here:

But it doesn’t really use a differential gear. Instead, it relies completely on traction between the two independently drive wheels and the ground to do the steering. Thus we are calling it a Traction Swerve. Most of the structure is laser cut sheet metal. The swerve bearing is comprised of 4 V groove rollers riding in a laser cut hole. We have a single encoder, which we custom built using a laser cut slotted disc 8" in diameter and 3 IR sensors. Gearing is a little slow with a 4" diameter wheel and a 10:1 gear ratio. Each Swerve is using 2 mini-cims to drive and turn. We’ll essentially be running an 8 mini-cim swerve drive. We’ve been running an 8 mini-cim mecanum drive for the past 2 season with pretty good success. (Some would argue we’re on the edge of constantly browning out and they might be right.)

When we started designing this we were concerned with control-ability. The two videos link below is our initial testing. I think it shows that Traction Swerve is highly viable. Our next stage is to build 4 of these and place them onto a bot and drive it on the ground. This will ultimately prove viability. We plan on swapping to 775’s and going with a COTS encoder.

The first video shows the serve on a test bed we designed and built to test performance of a single unit. This is under manual control. Essentially it is being driven around via joystick like a normal tank steer bot. It’s a little jittery.

The second video is under PD (no I) closed loop feed back via the single custom built ring encoder. The joystick is giving the angle command and the algorithm is controlling the motors to turn to the target angle. The resolution of the custom built encoder is only 1 degree. From the video you can see that we probably get about 2 degrees of accuracy. We tried adding some “I” gain but found that it made it a bit jittery. We only spent about an hour tuning this so there might be a gain setting that would work better. It’s tracking fairly well from what we can tell.

Appreciate all questions and comments.

1 Like

It turns out *(https://www.chiefdelphi.com/media/photos/46628) a lot less original than even *(https://www.chiefdelphi.com/media/photos/46650?) thought. I’m glad to see that multiple teams have tested this kind of design and are proving its viability, even with a fairly crude controls setup, far simpler than I think most people (including me) anticipated.

When you do get around to building a full chassis, there’s some discussion in my oldest thread about possible weaknesses of this type of design. I hope that you get to test some of the weaknesses brought up there, including loss of traction and going up, across, and over bumps and ramps.

Not needing to do any speed control on the wheels makes the design a lot simpler obviously, but doing position control on the wheels as well may complicate that.

Would you be willing to share a bit more about your custom encoder and post the CAD for your module?**

As long as you guys keep making “yeet bots” like this year, I don’t care what kind of drive train it has, it will probably still be the funniest (yet scarily effective) bot out there.

Real talk, it’s good to see teams tackle swerve in a low-cost yet effective way.

This is innovative. I’d be curious to see how it works on a full size/weight robot. Thanks for sharing.

Very interested to see how your makeshift bearing handles under impact. Impressive design, can’t wait to see how it evolves!

Looks interesting. How long would you estimate the modules would take to machine and assemble in build season? You want to make sure you don’t underestimate the amount of resources it takes (both in time and manpower) that you will be devoting to this. Swerve is all but useless if its on a robot that can’t play the game well. Having limited to no parts that are complex to machine is definitely an important first step in making sure swerve doesn’t negatively effect rest of your robot.

I’m going to borrow this bearing concept for a little bit… I promise I will return it in the same or better condition that when I found it.

Slick testing mechanism btw, can you vary the load on the module/ change drive surface easily?

I think it took one of our team members about 3 or 4 hours to put one together. That’s probably because he did it wrong twice before getting it right. It was pretty simple to assemble and wire up. And there is virtually no machining. The only thing we needed to machine was a hole pattern in the gear that bolts to the wheel and the axle which we needed to cut to length and drill and tap each end. This is no milling on this at all.

Borrow away. Would love to see what you come up with.

Here is a new video of the swerve drive. We turned on the traverse forward part of the algorithm so that it will not only turn to the target angle but also move forward at the command speed.

That little wiggle the module does as the pid finds the azimuth is quite satisfying.

Just a thought for this type of drive surface indexed swerve module:

You could easily enough add a way to lock the azimuth for traverse of rough terrain, pushing, or loss of one of the motors. Menuverability would be hampered while engaged, but it wouldnt matter if a wheel came off the ground. You could also lock for known straight vectors (i.e. autonomous). Yes, complexity. But if you designed the module with the feature in mind it could probally be done for next to nothing in weight and packaging.

Using pnumatics or a servo you could engage a friction plate or some gear teeth on the azimuth frame (or saddle, or on the swerve forks, whatever you call it). If done right the force needed to be suplied by the actuator would be small.

Do you have the CAD / list of parts / whatever else for that test bench? Super cool.

Oops…wrong link. Here is the third video:

We are still gathering up our BOM. I’ll release CAD once we have it on the ground and running around. I don’t want to release something that is not completely validated.

Could you tell us a little bit more about how the encoder works?

We use three of these IR sensor:

https://www.alliedelec.com/optek-tt-electronics-opb490t11z/70048620/?&mkwid=srXRkfvCR&pcrid=277167151383&pkw=opb490t11z&pmt=e&product=&gclid=Cj0KCQjwidPcBRCGARIsALM--eM5V-AiSYYdYIy8X9SXW6g6XAolNyaNIwg8wciYvFIZd4FinzMk-nIaAqFyEALw_wcB

to create a quadrature encoder signal. The 3rd is the Z channel to detect a single home slit around the OD of the encoder disc.

We 3D printed an attachment head that bolts onto the stationary mount plate. The 3D printed part spaces the 3 sensors to the appropriate depth to read the slots.

We laser cut a 0.030" thk steel disc with 180 slots slanted at about 20 degrees. The slot width is about 0.050".

We had some early issues with aligning the encoder head to make sure it was concentric with the axis of rotation. After a bunch of playing around I think we finally got alignment down to about 0.010". That seemed to be good enough to provide consistent readings.

It also helps that we re-zero every time we see the Z channel go high.

To be honest, we don’t love this encoder design. We question its durability and reliability throughout an entire season of getting smacked around. We have a version 2 that we are making now that will have a hollow bore slip ring and allow us to pass a encoder rod thru the center. We’ll use a standard CTRE mag encoder which we know is fairly reliable.

Picture of the assembly is attached, I think (I’m still getting the hang of posting on CD):

https://www.chiefdelphi.com/forums/attachment.php?attachmentid=23534&stc=1&d=1536528791

On the subject of slip rings, we are wondering if a slip ring is even necessary. With as fast as this turns, we can limit rotational travel to +/- 360 degrees via software and never need a slip ring. Has anyone ever tried that?


I would not do this. You will hit the +360 or -360 limits far too often (if you are driving swervy and not tanky) and your modules will have to do a spin to reset back to 0. I would stick with the slip ring unless it is seriously constraining your design. If you are using 775s, you probably want to limit the motor power to well within the limits of the slip ring, so I don’t think the slip ring will limit you power. If you have the motor controllers on the rotating part, then you have 2 wires for power and return for each motor and the other 2 wires for CAN. So you should be all set in terms of the wires.

If you’ll let me propose an idea, this is how I designed an encoder mount for my traction swerves.

The mated gear is meant to be pressed onto the rotor housing of the slip ring.

It doesn’t look like your slip ring is mechanically fixed to the rotation of the module, but depending on how tightly the wires are bound that may not be a problem. Alternately, if you have talon SRXes on the module, you can put it on the module instead with a similar design and read the encoder through CAN.

Can you use a smaller module/pitch gear-set to help reduce backlash error on your azimuth encoder? The pitch looks a bit large to be for precision (IMO of course). I am taking a guess here, but is that gear a 3d-printed part? I know you can only push 3d geartrains so small…