Swerve Drive

Introduction

Translational Movement

Translational movement is very straight forward. Quite literally! Each wheel is aligned in the same direction, and moves at the same rate. If they are misaligned, the robot will start to diverge and slowly accumulate error (ie, go off track). This is normal but still undesirable, and can be fixed with odometry from camera systems.

The speed is determined by the wheel dimensions and the motor's effective RPM. This uses a concept called arc length. Essentially, it's the circumference of the wheel multiplied by the number of rotations. Only rotated the axle 1/3 of the way around? That results in a linear distance of 1/3 of the circumference.

It's important to keep this movement in vector format. In this way, the length or magnitude of the vector defines the speed, and the component's relative values decide the angle. The vector is describing the motion of the robot in either field relative, or robot relative coordinates. Typically the calculations are done in robot relative coordinates, and the controls are handled in field relative coordinates. This requires a coordinate frame shift the depends on the field position and layout. For the remainder of this article the terminology will be ambiguous as the math applies to both cases the same. However you, the reader, should pick one coordinate frame and stick with it.

Rotational Movement

Rotational movement is a more complicated beast. This component uses a blend of linear and angular terms. We must once again look to our arc length math and think of the motion as it's happening around a circle. We're using some of the same principles, distance over time is velocity, but we're goint to start describing some of it in new terms.

At each moment in time, rotational movement happens along a tangent vector. If you notice the above image, you can see the tangent vector in red is 90 degrees from the point relative to the origin. You can also observe that the distance between the tangent vector and the curve is larger the farther down the vector you go. What stops this from moving along that vector direction forever? The centripetal force!

The centripetal force is intrinsic to the design of the robot, not something to be calculated. It's the tension in the body as the wheels try to shoot off in their own directions, but the robot body keeps them a certain distance away from the axis of rotation (typically also the robot origin).

What all of this means, is that the rotation vector is always the same direction from the robot relative coordinates, the only thing that changes is the magnitude.

Combined Movement

Believe it or not, that's it. We have the only 2 velocity vectors we need for this sort of movement. Lets look at this in motion, and see how it plays out. The following demo shows a robot with 3 inconsistently placed wheels, and the calculated vectors to get it to move across the grid.

You may see an illusion where the center point is swaying back and forth towards the target point. This is an illusion due to the inconsistent placement of the wheels. You can place a ruler along the direction and see the alignment for yourself.

The blue lines are the lines to the robot center.
The red lines are the tangent vector.
The green lines are the translation vector.
The black lines are the effective vector.

PID Loops

The second critical aspect of making swerve drive swerve is something called PID loops. PID loops are a technique for stabilizing current, managing error, and staying on target. They are robot dependent values that take into account things like weight when helping the robot shift from one level of energy consumption to another. You can see a deeper dive into PIDs in another article here.

From this point, it's difficult to guide a specific way to convert these equations into motor movements and calibration profiles. Different hardware companies and offer different APIs and ways to convert these vectors into angles and and velocities, and internal pid controllers to handle precision.

• TalonFX
• SPARK / REVLib

Finally, an example of how you can interact with WPILib's SwerveDriveKinematics and SwerveModuleState APIs, and create a compatible interface with the motor vendors APIs, can be found elsewhere in this git account.