# A Crash Course in Swerve

Swerve Drive Systems are commonly seen as difficult to understand from a mathematical and programming standpoint. I’ve written a short guide that runs through the theory of how a swerve drive works, and some further considerations.

See the document here

Looks like a great starter pack for swerve! I like how you’ve helpfully included the atan function for dealing with non-square chassis.
You may want to look up gifs to describe motion or add an example for calculating the wheel angle, but even as it is, it keeps things easy to read and simple.

*@Jaci:

Let
L=2.5 feet,
W=1.5 feet,
and suppose I want the instantaneous robot motion to be straight forward at 5 feet/sec (i.e. Uy=5, Ux=0) while simultaneously rotating clockwise at 0.5 radians/sec around the center of geometry of the wheel pattern.

Using only the equations at the bottom of page 3, what is the numerical value of the speed and angle of the front right wheel?

You’ll note in the document that we are using arbitrary units coming from the joystick, so with the equations posted with the document you would not be able to specify a rotation rate in radians/sec, nor would you be able to specify a moving speed in feet/sec (or metres/sec, for that matter). The purpose of the equations in the document are to map using the native range of the joysticks provided in code. The input magnitudes for both rotation (omega) and speed (u) are on a scale of -1 to 1.

This is important because if you were to use |tangential vel| = angular vel * radius, any radius above 1.0 would drown out the driver’s joystick throttle without additional scaling to the joystick throttle. This is why, on page 2, I state we can use |tangential vel| = angular vel.

In order to make this work with proper units, you would use the proper |tangential vel| = angular vel * radius, and to pass in u values as feet/sec.

In both cases, output speeds above 1.0 will need to be scaled relative to the other wheels, since motors can only move so fast.

Robot dimensions are only required to find the angle phi of each wheel. The units are completely arbitrary as long as the ratios are equivalent.

*I thought that might be your answer. Suggestion? You might want to make that just bit clearer in the document. Maybe even include an example calculation showing how to use the equations with actual numerical values for desired vehicle translation and rotation rates.

There are applications for swerve where you want to calculate wheel speeds and angles for specific values of robot motion.

this is supposed to be fun. You guys are making my head hurt.

I’ve got a followup document planned, that goes more into autonomous swerve drive and motion planning. I’ll keep your suggestions in mind

I’ve added a footnote to the pdf that outlines what changes have to be made to make it work with real-world units, as well as a little more in-depth response as to why the radius was omitted from tangential velocity calcuations.

Oh but it is fun

For real though, swerve calculations are easy once you wrap your head around how turning works. The bulk of the work comes in tuning the system to your needs, like a closed-loop system like PID

.

If you have any questions, please let me know so I can update the document because chances are you aren’t the only one asking.

Awesome resource.

I’m a mechanical lead so I’m not too familiar with the controls; if you were using an Xbox controller, would you control, say, the front with one joystick, and the back with the other? Or would you control x-axis and y-axis on each stick? Our team uses the controller and not a joystick.

I’m asking because I’ve been developing a swerve of my own. Also while I’m here, if I had more surface-contact area on the robot, there would be more control/grip, correct? What if, theoretically, I fit four 2 inch wheels with tread on each swerve module; would that have any advantages? Would that increase or decrease the chances of tipping the bot?

Thanks.

We use an xbox controller. No idea if our controls are typical but here’s how they work :

One stick strafes the robot. That is, it controls forward, backward, left and right. Or various diagonal combinations thereof.
The bumpers control rotation left and right

The stick plus bumper triggers can be combined, keeping in mind the discussion above where you have to scale robot movement so that no wheel is going faster than its max speed.

We use the other stick for a “snap to heading” function. Push that stick in any direction and the robot rotates to face that direction.

An interesting part of swerve is deciding what “forward” is. Since the robot can rotate independently of whatever direction it is driving it can get complicated knowing which way is forward. To help drivers out, some teams code the robot to be “field-centric” (our term for it, at least). That means that no matter which way the robot is rotated pushing the stick up strafes the robot away from the driver. We do this by interfacing with an IMU (the NavX) to know the robot’s heading on the field at all times.

Another interesting part is that you don’t have to define the center of rotation to be the center of the robot. That is, the math works if you’re rotating around the center of the field, the center of your city, or somewhere in a different galaxy (individual results might vary). We found this hard for drivers to use, but in auto modes it might be helpful, say if your team builds a telescoping arm to hold an object out beyond the edge of the robot. Rotating around the end of the arm could be useful in some cases for fine control.

No one would do that!

Ohh wait…

Jaci, I suspect at least one of our students will be in touch with you about path planning and swerve before too long.

I wondered if anyone else used a “snap to heading” function like that. I wrote one for our recycle rush bot in the offseason, and the more I practiced with it, the more I liked using it exclusively for rotation. I wish I finished it in time for the actual competitions but oh well.

That said, ‘standard’ controls are close to what you have here, but with no snap to heading function and with rotation on the right stick x-axis instead of the triggers.

Like this, for example.

Halo auto-rotate

Hey Ether, ever been to Durham, NC? We’ve got cookies and brownies if you want to come.

**No, but next time I visit here, I’ll stop by.
**
*
*

Call me, we’ll show you a swerve-y time.

That’s right on the border between vinegar-based and red BBQ sauce territories. Have an answer ready if you’re asked which one is correct.

All I know is we’re not doing it a second time.

Hey, that’s my town. Whatever I say there is correct.

Looks great. Here’s my million AUD\$ question though…

Say you run your desired linear and angular velocities through your kinematics equations and you come up with desired wheel speeds and angles for each of your wheel modules. So far so good. Now let’s deal with the fact that motors have constraints on their maximum velocities.

What if the combination of inputs results in an overall wheel velocity that exceeds the free speed of the motor for one or more of the modules? Easy to fix…you can scale each of wheel velocity commands proportionally such that no motor exceeds its maximum, and you preserve the direction and curvature of motion (generally the parts we care most about when driving a robot).

But wait, steering motors have velocity limits too. We know that a module can’t just teleport from one angle to another. The module is steered by a motor that also has a maximum speed (ignoring torque/acceleration for the time being).

If I impose an angular velocity constraint on module rotation, what is your proposed approach (in terms of both steering and traction commands) for obtaining motion that is smooth but still closely matches the driving commands?

(To be clear: I don’t know of a one-size-fits-all “right” answer to this question for the case that the wheel contact patch is centered on the axis of rotation of the module, as is the case in most FRC swerve implementations)