Unit 7 · Lesson 1

Introduction to Swerve Drive

This is the lesson that separates hobby FRC from championship FRC. Swerve drive is mechanically complex, electrically dense, and demands more from your code than any mechanism you've built so far. It also unlocks capabilities no other drivetrain can match. This lesson builds the complete mental model before a single line of code is written.

By the end of this lesson, you will:

Explain what a swerve module is and name its three primary components from a programmer's perspective
Describe the advantages of swerve drive over tank drive — and be honest about the tradeoffs
Distinguish between robot-oriented and field-oriented control at a conceptual level
Trace the 20 ms control loop from driver input to hardware command across all four modules
Name the hardware stack used by 2910: drive motor, steering motor, absolute encoder, and gyro
Identify the twelve devices on a swerve drivetrain and explain why that number matters for CAN bus planning

What is a Swerve Drive?

A standard tank drive robot has wheels that can spin forward and backward. To turn, it spins opposite sides at different speeds. It is simple, reliable, and fundamentally limited: it can only go where it's pointing.

A swerve drive breaks this constraint entirely. Each of the four wheels sits inside a swerve module — a self-contained unit with two motors: one that spins the wheel, and one that rotates the entire wheel assembly to any angle. A wheel that can point any direction and spin at any speed gives the robot complete freedom of movement.

The result: the robot can drive sideways without turning. It can drive diagonally while rotating. It can spin in place while moving forward. Any velocity in any direction while holding any heading — simultaneously. No other drivetrain in FRC matches this.

🔍 LRI Perspective: "The complexity is worth it — but only if you understand it"

I've inspected swerve robots at every level, from rookie teams deploying their first module to world champions. The robots that fail at competition almost always fail not because swerve is hard to build, but because the programmer didn't understand the system deeply enough to debug it at 7am before qualifications. This unit is about building that understanding. You will write more code in this unit than any previous one. That code will only make sense if the mental model underneath it is solid. So we start here — before the code.

Tank Drive vs. Swerve Drive

🦾 Tank Drive Simple, reliable, well-understood

✓ 2–4 motors total — simple CAN bus

✓ Easy to build, wire, and maintain

✓ Robust — few failure points

✓ Simpler code — no kinematics needed

✗ Can only go where it's pointing

✗ Slow turns break autonomous timing

✗ Vulnerable to defense — easy to block

⚡ Swerve Drive Dominant at competition level

✓ Omnidirectional — any direction instantly

✓ Decouple heading from movement direction

✓ Smooth, fast autonomous paths

✓ Field-oriented control — driver-friendly

✗ 8–10 motors on the drivetrain alone

✗ Complex code — kinematics, odometry, PID

✗ More failure points — more to debug

💡 Why swerve dominates at worlds — not just because it can move sideways

The single biggest competitive advantage of swerve isn't the omnidirectional movement — it's field-oriented control. A tank drive driver must constantly reorient the robot to face the target before shooting or collecting. A swerve driver points the joystick at the goal and the robot goes there, regardless of which direction the robot is facing. Under competition pressure, that cognitive reduction is worth as much as the extra 20% of cycle speed.

The Swerve Module: A Programmer's Anatomy

You don't need to understand every gear and bearing in a swerve module. But you need to understand its three electrical connections — because each one becomes a software object in your code.

Click each component in the diagram to see its role in the system.

SDS MK4i Swerve Module — click a component

← click a numbered component to see its role in the code

The Full Drivetrain: Four Modules + One Gyro

A swerve drivetrain has four identical modules — one at each corner of the robot — plus a gyroscope mounted near the robot's center. From a software perspective, the system has exactly nine hardware objects you will program:

4 drive motor controllers (one per module)
4 steering motor controllers (one per module)
4 absolute encoders — CANcoders — (one per module)
1 gyroscope (Pigeon 2 on 2910 robots)

That's 12 CAN devices on the drivetrain alone — before any mechanisms. CAN bus planning (unique IDs for every device, bus utilization, update rate management) is not optional at this scale. It is a core part of the drivetrain's setup. We will address it when we build the SwerveDrivetrain subsystem in Lesson 6.

⚠️ The systems perspective: 8 motors spinning at the same time

A tank drive might draw 40–80 amps at full speed. A swerve drivetrain can draw 120–200 amps when all eight motors are under full load simultaneously. Current limiting on every drive motor, ramp rates on acceleration, and constant battery health monitoring are not optional. The electrical team needs to know — before the robot is built — that current limiting constants will be set in code, and that those constants need to be tuned collaboratively between programmers and the electrical team. The PDH's per-channel current monitoring (which you learned to publish in Unit 6) becomes a first-class telemetry channel on a swerve robot.

The 2910 Hardware Stack

Before writing code, you need to know what hardware you're writing it for. Swerve code is not generic — it is coupled to specific motor types, encoder interfaces, and gyro models. Here is the standard 2910 hardware stack for swerve:

Component	Hardware	Interface	WPILib / Vendor Class
Drive Motor	Falcon 500 (TalonFX) or Kraken X60	CAN bus	TalonFX (Phoenix 6)
Steering Motor	Falcon 500 (TalonFX) or NEO (SparkMax)	CAN bus	TalonFX or SparkMax
Absolute Encoder	CTRE CANcoder	CAN bus	CANcoder (Phoenix 6)
Gyroscope	CTRE Pigeon 2	CAN bus	Pigeon2 (Phoenix 6)
Module Chassis	SDS MK4i or MK4n	Mechanical	No class — geometry constants only
Power	REV PDH	CAN bus	PowerDistribution

The module chassis (SDS MK4i) defines the physical geometry: wheel diameter, gear ratio, and the wheelbase measurements. These become constants in your code — they don't change unless you swap modules. The gear ratio affects how encoder ticks convert to wheel rotation. The wheelbase defines the module positions used in kinematics. Getting these constants wrong means your robot drives incorrectly at a scale that's hard to diagnose without understanding the source.

Robot-Oriented vs. Field-Oriented Control

There are two ways to interpret a driver's joystick input on a swerve robot. The difference is profound in practice — one is disorienting under pressure, the other is why swerve drivers feel like they're flying.

👇 Click each card to understand the control mode

🤖

Robot-Oriented

tap to learn more

Relative to robot's front

Stick forward = robot drives toward where its front is pointing. If the robot is facing the wall, stick forward goes into the wall. The driver must constantly think about which direction the robot is facing. Works the same as tank drive. Used occasionally for precise close-range maneuvering.

🏟️

Field-Oriented

tap to learn more

Relative to the field — 2910 standard

Stick forward = robot drives toward the opponent's wall, regardless of which direction the robot is facing. The robot's gyro continuously adjusts module angles to maintain field-relative movement. The driver thinks in field coordinates, not robot coordinates. Dramatically lowers cognitive load in competition.

🔢

The Gyro's Role

tap to learn more

What makes field-oriented possible

Field-oriented control requires knowing the robot's heading at all times. The Pigeon 2 gyro provides this. The code rotates the driver's field-relative velocity vector by the robot's current heading to produce robot-relative commands the kinematics can understand. If the gyro is wrong, field-oriented control is wrong. The gyro reset button is not optional.

The 20 ms Control Loop: From Driver to Hardware

Every 20 milliseconds, a pipeline executes that transforms a driver's joystick position into four specific motor commands across eight motor controllers. Understanding this pipeline is the mental model that makes all of Unit 7's code comprehensible. Click each step below.

Swerve control loop — 20 ms per cycle — click each step

🕹️ Driver Input Joystick axes read

→

🧭 ChassisSpeeds vx, vy, ω

→

📐 Kinematics Math layer

→

🔢 Module States 4× speed + angle

→

⚙️ SwerveModule Per-module PID

→

⚡ Hardware 8 motors commanded

← click a step to understand its role in the swerve control loop

This pipeline executes 50 times per second. Steps 1 through 4 are nearly instantaneous — they are math and data transformations. Step 5 (the SwerveModule class with its PID steering controller) is where the work lives. Unit 7 will build this pipeline piece by piece, starting with kinematics in Lesson 3 and ending with the complete drivetrain in Lesson 6.

Unit 7 Roadmap

This unit builds the complete swerve drivetrain from the ground up. Each lesson adds one layer of the architecture. By Lesson 12, you will have a fully functional field-oriented swerve drive with odometry, pose estimation, and the debugging skills to fix it when something goes wrong.

Unit 7 — Drivetrains & Swerve Drive

Introduction to Swerve Drive ← You are here

Mental model, hardware anatomy, control modes, and the 20 ms control loop pipeline

Swerve Hardware Overview

CAN bus planning, CANcoder configuration, offset calibration, and Pigeon 2 setup

Swerve Kinematics

SwerveDriveKinematics, ChassisSpeeds, SwerveModuleState, toSwerveModuleStates()

Swerve Odometry

SwerveDriveOdometry, Pose2d, field position tracking, and why it matters for auto

The SwerveModule Class

The complete per-module class: drive motor, steering motor, CANcoder, PID, and optimize()

SwerveDrivetrain Subsystem

The top-level subsystem: four modules, kinematics, odometry, and the drive() method

7–12

WPILib Classes · Robot-Oriented · Field-Oriented · Pose Estimation · Libraries · Debugging

The full competition-ready drivetrain stack from basic driving to vision-fused pose estimation

🔌 System Check — Before This Unit Begins

Verify your development environment before writing any swerve code:

Phoenix 6 installed: Run WPILib: Manage Vendor Libraries and confirm CTRE Phoenix 6 is installed (not Phoenix 5 — they are different APIs with different class names). The vendor URL is https://maven.ctr-electronics.com/release/com/ctre/phoenix6/latest/Phoenix6-frc2025-latest.json.
CTRE Tuner X installed: Download from the Microsoft Store or CTRE's website. Tuner X is how you configure CANcoder offsets and Pigeon 2 settings — you cannot swerve-drive without it. Confirm it can detect your CAN devices.
All 13 CAN IDs planned: Before any wiring, document your CAN ID assignment in Constants.java. Suggested: drive motors 1–4, steering motors 11–14, CANcoders 21–24, Pigeon 2 on ID 30. Write these before build season.
Phoenix 6 simulation support: If you are using the IO layer from Unit 6, the Phoenix 6 sim library must be installed separately. Run WPILib: Manage Vendor Libraries → check "Install Simulation Libraries" under Phoenix 6.

Knowledge Check

1. A swerve drive robot is driving field-oriented at 50% speed toward the far wall. An opponent robot bumps it hard from the side, rotating it 45°. The driver doesn't move the joystick. What happens next?

A The robot continues in the direction it's now facing — 45° off from the original path.
B The robot self-corrects: the gyro detects the rotation, the code recomputes field-relative module angles, and the robot resumes its original direction toward the far wall.
C The robot stops because field-oriented control requires the driver to re-enter input after any disturbance.
D The robot rotates back to its original heading by reversing the 45° turn.

2. Each swerve module has a drive motor, a steering motor, and an absolute encoder. Why is the absolute encoder critical at robot startup, while a standard relative encoder would not be sufficient?

A Absolute encoders send data over CAN bus, which is faster than DIO ports used by relative encoders.
B An absolute encoder reports the wheel's angle in a full 360° range even after power-off and power-on. A relative encoder starts at zero every boot — so the robot would have no idea which direction each wheel is pointing when it first enables, making steering control impossible until the wheels are manually homed.
C Absolute encoders are more accurate than relative encoders for the angles involved in swerve steering.
D Relative encoders can't handle the 360° range that swerve steering requires.

3. The kinematics layer sits between ChassisSpeeds and the four SwerveModuleState objects. What exactly does it do, and why can't you just send the same speed and angle to all four modules?

A It filters out noise from the driver's joystick input before sending commands to the motors.
B Kinematics converts the robot's overall desired motion (a single velocity vector + rotation rate) into the unique speed and angle each module needs to produce that motion. During a turn, for example, each module must point in a different direction — outer modules travel faster than inner ones — and only the geometry-aware math of kinematics can compute those four distinct states correctly.
C It scales the motor speeds so they don't exceed the maximum voltage the battery can supply.
D It converts speeds from percentage output to meters per second for the motors to understand.

💪 Practice Prompt — Building the Mental Model

Map Your Swerve Hardware Before Writing Code

Open Constants.java in your project and create a Swerve inner class. Define the following as public static final fields: CAN IDs for all four drive motors (1–4), all four steering motors (11–14), all four CANcoders (21–24), and the Pigeon 2 (30). Add a comment for each group explaining which physical module it corresponds to (e.g., // Front Left Module).
Draw a top-down diagram of your robot on paper. Label each corner with its module name (FrontLeft, FrontRight, BackLeft, BackRight) and write the CAN IDs for each device at that corner. This diagram is the physical map to your code — tape it inside the robot's battery compartment or the pit laptop. Every programmer should be able to look at this and know where each device is.
Look up the gear ratio and wheel diameter for your team's swerve module (MK4i L2 is 6.75:1 with 4" wheels; MK4i L3 is 6.12:1). Add these as constants: kDriveGearRatio, kWheelDiameterMeters, and the derived kWheelCircumferenceMeters. Add a comment explaining what the gear ratio means physically.
Measure (or look up) your robot's wheelbase: the distance from front wheel center to rear wheel center, and the track width: distance from left wheel center to right wheel center. Add these as kWheelBase and kTrackWidth in meters. These will feed directly into the SwerveDriveKinematics constructor in Lesson 3.
Stretch goal: Open CTRE Tuner X and identify each CANcoder on the robot. Read the "Absolute Position" value for each one with the robot in its "forward-facing wheels pointing forward" position. Write these values down — they are your encoder offsets, the values that tell the code where "straight ahead" is for each module. You will use these in Lesson 5 when building the SwerveModule class. Storing them now saves you from doing this under time pressure during build season.