Lesson 5.11: Swerve Drive Concepts

🎯 What You’ll Learn

By the end of this lesson you will be able to:

• Explain how a swerve drive module works (drive motor + steer motor = speed + angle)
• Distinguish between field-relative and robot-relative control and why field-relative is preferred
• Describe how odometry tracks the robot’s position using encoders and gyro data
• Explain kinematics — how desired robot motion is converted into individual module states
• Connect these concepts to your team’s CommandSwerveDrivetrain and TunerConstants code

Before You Start

Complete Activity 5.4: Inspect CAN Devices. Have your team’s code open in your IDE, specifically CommandSwerveDrivetrain.java and TunerConstants.java.

---

What Is Swerve Drive?

A swerve drive is a drivetrain where each wheel module can independently control both its speed and its steering angle. This gives the robot omnidirectional movement — it can drive in any direction while simultaneously rotating.

Your team’s robot uses a swerve drive with four modules, managed by CommandSwerveDrivetrain.java. Each module has:

• A drive motor (TalonFX) that controls wheel speed
• A steer motor (TalonFX) that controls wheel angle
• A CANcoder that measures the absolute angle of the wheel

That’s 12 devices just for the drivetrain (4 drive motors + 4 steer motors + 4 CANcoders), plus the Pigeon 2 gyro for heading.

---

🤔 Predict First

Before reading further: your robot has 4 swerve modules. If the driver pushes the joystick straight forward, what do you think each module does? Do they all point the same direction? Do they all spin at the same speed? Write down your prediction — we’ll check it in a moment.

---

Module States

A module state is the combination of speed and angle for a single swerve module. It’s the fundamental unit of swerve drive control.

Module State = (speed in m/s, angle in degrees)

For example, a module state of (2.0 m/s, 45°) means the wheel is pointed at 45 degrees and spinning fast enough to move at 2 meters per second in that direction.

Your robot has four modules, so at any moment the drivetrain is defined by four module states:

Module	Position	Drive Motor	Steer Motor
Front Left	Top-left corner	TalonFX	TalonFX
Front Right	Top-right corner	TalonFX	TalonFX
Back Left	Bottom-left corner	TalonFX	TalonFX
Back Right	Bottom-right corner	TalonFX	TalonFX

How Module States Create Motion

Different combinations of module states create different robot motions:

Desired Motion	Module States
Drive forward	All 4 modules: same speed, all pointing forward (0°)
Strafe right	All 4 modules: same speed, all pointing right (90°)
Rotate in place	Modules point tangent to a circle around the robot center, all same speed
Drive forward while rotating	Each module has a unique angle and speed — this is where kinematics gets interesting

---

Field-Relative vs Robot-Relative Control

This is one of the most important concepts in swerve drive.

Robot-Relative Control

In robot-relative mode, joystick inputs are relative to the robot’s current heading:

• Push forward → robot drives in the direction it’s facing
• Push right → robot drives to its own right side

This is how tank drives and arcade drives work. The problem? When the robot rotates, “forward” on the joystick changes direction. If the robot is facing away from you, pushing forward drives it away. If it’s facing toward you, pushing forward drives it toward you. This is confusing for drivers.

Field-Relative Control

In field-relative mode, joystick inputs are relative to the field:

• Push forward → robot drives toward the far end of the field (always the same direction)
• Push right → robot drives toward the right side of the field (always the same direction)

No matter which way the robot is facing, the joystick directions stay consistent. This is much more intuitive for drivers and is the standard for swerve drive teams.

How Field-Relative Works

Field-relative control requires knowing the robot’s heading (which way it’s facing). This comes from the Pigeon 2 gyro. The math is:

1. Driver pushes joystick → raw X and Y values
2. Read the gyro heading → robot’s current angle relative to the field
3. Rotate the joystick values by the negative of the heading → field-relative velocities
4. Feed the field-relative velocities into kinematics → module states

Your team’s CommandSwerveDrivetrain.java handles this transformation. The gyro heading is read from the Pigeon 2, and the joystick values are rotated before being passed to the swerve kinematics.

---

The robot is facing 90° to the right (toward the scoring table). The driver pushes the joystick straight forward. In field-relative mode, which direction does the robot drive?

Toward the scoring table (the direction the robot is facing)Toward the far end of the field (forward is always field-forward)It depends on the gyro calibrationThe robot rotates instead of driving

---

Odometry: Tracking Position

Odometry is how the robot tracks its position on the field. It uses wheel encoder measurements and gyro heading data to estimate where the robot is.

How Odometry Works

Every 20ms (50 times per second), the odometry system:

1. Reads wheel encoders — how far did each wheel travel since the last update?
2. Reads the gyro — what is the robot’s current heading?
3. Calculates displacement — based on wheel distances and heading, how far did the robot move?
4. Updates the pose — adds the displacement to the current estimated position

The result is a pose — the robot’s estimated position (x, y) and heading (θ) on the field.

Why Odometry Drifts

Odometry is never perfect. Over time, small errors accumulate:

Error Source	Effect
Wheel slip	Wheels slide on the carpet → encoder reads more distance than actually traveled
Gyro drift	Gyro heading slowly drifts over time → heading estimate becomes inaccurate
Measurement noise	Small random errors in each encoder/gyro reading → position estimate gradually diverges
Collisions	Robot bumps into another robot → wheels slip significantly

This drift is why advanced teams add vision correction (AprilTag pose estimation) to fuse with odometry — you’ll learn about that in Unit 6’s pose estimation lesson.

Odometry in Your Code

Your team’s CommandSwerveDrivetrain.java updates odometry automatically. The CTRE swerve library handles the encoder reads, gyro reads, and pose calculation internally. You can access the current pose with methods like getPose() or getState().Pose.

---

Kinematics: From Desired Motion to Module States

Kinematics is the math that converts what you want the robot to do (drive forward at 2 m/s while rotating at 30°/s) into what each individual module needs to do (specific speed and angle for each of the four modules).

The Kinematics Problem

Input: Desired robot motion

• vx = forward/backward velocity (m/s)
• vy = left/right velocity (m/s)
• omega = rotation rate (rad/s)

Output: Four module states

• Front Left: (speed, angle)
• Front Right: (speed, angle)
• Back Left: (speed, angle)
• Back Right: (speed, angle)

How It Works (Conceptual)

The kinematics calculation considers:

1. Translation — all four modules need to contribute to the desired forward/sideways motion
2. Rotation — each module needs to contribute to the desired rotation, which depends on its distance from the center of rotation
3. Combination — the translation and rotation contributions are added together for each module, giving a unique speed and angle per module

This is why swerve drive is more complex than tank drive — each module has a different state, and the math to calculate those states involves trigonometry and vector addition.

Kinematics in Your Code

WPILib provides SwerveDriveKinematics to handle this math. Your team’s TunerConstants.java defines the module positions (how far each module is from the robot center), and the kinematics object uses those positions to calculate module states.

TunerConstants Is Generated

Remember from Unit 1: TunerConstants.java is auto-generated by CTRE Tuner X. It contains the physical measurements of your swerve modules (positions, gear ratios, offsets). You read this file to understand the configuration, but you don’t edit it manually.

---

The Gyro: Your Heading Reference

The Pigeon 2 gyro is the sensor that tells the robot which direction it’s facing. It’s critical for both field-relative control and odometry.

What the Gyro Measures

Measurement	What It Is	Used For
Yaw	Rotation around the vertical axis (heading)	Field-relative control, odometry
Pitch	Tilt forward/backward	Detecting if the robot is on a ramp
Roll	Tilt left/right	Detecting if the robot is tilted

For swerve drive, yaw is the most important measurement. It tells the field-relative control system which way the robot is facing so it can correctly interpret joystick inputs.

Gyro Calibration

The gyro needs to be calibrated (zeroed) at the start of each match. When the robot is placed on the field, the gyro’s zero heading should align with the field’s forward direction. If the gyro is miscalibrated:

• Field-relative control will be offset — “forward” on the joystick won’t actually be field-forward
• Odometry heading will be wrong — the robot’s position estimate will rotate incorrectly
• Autonomous paths will drive in the wrong direction

Most teams zero the gyro in their autonomous init or when the robot is first enabled.

---

During a match, your driver reports that pushing the joystick forward makes the robot drive at a 30° angle to the left instead of straight forward. The drivetrain hardware is working correctly. What's the most likely cause?

A swerve module's CANcoder is brokenThe gyro heading is offset by 30° — it wasn't calibrated correctly at the start of the matchThe kinematics module positions are wrong in TunerConstantsThe joystick is physically damaged

---

Putting It All Together

Here’s how all the swerve concepts connect in a single control loop (every 20ms):

1. Driver input → Joystick X, Y, and rotation values
2. Field-relative transform → Rotate joystick values by gyro heading
3. Kinematics → Convert field-relative velocities into four module states
4. Module optimization → Minimize wheel rotation (choose the shortest path to the target angle)
5. Motor commands → Send speed and angle commands to each module’s drive and steer motors
6. Odometry update → Read encoders and gyro, update the robot’s estimated position

All of this happens 50 times per second, and your team’s CommandSwerveDrivetrain.java orchestrates the entire process.

---

✅Checkpoint: Swerve Drive Concepts

Without looking at the lesson, explain in your own words: (1) What is a module state and why does each module need its own? (2) Why is field-relative control better than robot-relative for drivers? (3) What causes odometry to drift over time? (4) What role does the Pigeon 2 gyro play in swerve drive?

▶Check Answer

Strong answers:

1. Module state = speed + angle for one wheel. Each module needs its own because when the robot translates and rotates simultaneously, each module is at a different position relative to the center of rotation, so each needs a different speed and angle to produce the desired motion.

2. Field-relative is better because the joystick directions stay consistent regardless of which way the robot is facing. “Forward” always means toward the far end of the field. In robot-relative mode, the driver has to mentally track the robot’s orientation, which is confusing and error-prone.

3. Odometry drifts because of wheel slip (wheels slide on carpet), gyro drift (heading slowly becomes inaccurate), measurement noise (small random errors accumulate), and collisions (sudden large errors from impacts).

4. The Pigeon 2 gyro provides the robot’s heading (yaw). This is used for field-relative control (rotating joystick inputs to field coordinates) and for odometry (knowing which direction the robot is facing when calculating position updates).

---

Key Terms

📖 All terms below are also in the full glossary for quick reference.

Term	Definition
Swerve Drive	A drivetrain where each wheel module independently controls both drive speed and steering angle, enabling omnidirectional movement
Module State	The combination of drive speed (m/s) and steering angle (degrees) for a single swerve module
Field-Relative Control	A control mode where joystick inputs are interpreted relative to the field orientation rather than the robot’s heading
Odometry	Tracking the robot’s position on the field using wheel encoder measurements and gyro heading data
Kinematics	The mathematical transformation that converts desired robot motion (translation + rotation) into individual module states
Gyro (Pigeon 2)	An inertial measurement unit that provides the robot’s heading (yaw), pitch, and roll
Pose	The robot’s estimated position (x, y) and heading (θ) on the field

---

What’s Next?

You now understand the concepts behind swerve drive. In Activity 5.12: Trace a Joystick Through Swerve Math, you’ll trace a specific joystick input through your team’s CommandSwerveDrivetrain code — from raw joystick values through field-relative transformation, kinematics, and all the way to individual module motor commands.