Swerve Drive Prerequisites
Understanding Swerve Drive Fundamentals
Swerve drive makes a lot more sense once you know how the hardware and control systems fit together. This page covers the concepts you'll lean on when creating and tuning your drivetrain.
Master the fundamentals of swerve drive: holonomic motion, coordinate systems, module anatomy, and field-centric control.
Swerve Module Anatomy
Each swerve module has three key components:
Drive Motor
Controls the wheel speed and provides forward/backward motion for the module. Typically a high-power motor like Kraken X60 or Falcon 500.
Purpose: Translational velocity control
Control: Velocity PID or voltage control
Sensor: Integrated encoder for speed feedback
Turning Motor
Steers the module by rotating the wheel to the desired angle. Requires precise position control with absolute encoder feedback.
Purpose: Wheel direction control
Control: Position PID with Motion Magic
Sensor: Absolute encoder (CANcoder) for angle
CANcoder
Absolute position sensor that tracks the steering angle. Critical for module zeroing and maintaining accurate wheel orientation.
Purpose: Absolute angle measurement
Type: WCP ThroughBore or CANcoder V2
Units: Rotations (0 to 1.0)
Hardware Setup & Wiring
A consistent CAN ID scheme makes wiring and debugging much easier. This is the standard configuration we use on all our robots.
Recommended CAN ID Scheme
- Drive Motors: 1, 3, 5, 7 (FL, FR, BL, BR)
- Steer Motors: 2, 4, 6, 8 (FL, FR, BL, BR)
- CANcoders: 9, 10, 11, 12 (FL, FR, BL, BR)
- Pigeon 2 Gyro: 13
Why Use a CANivore?
A CANivore is a USB-to-CAN adapter that creates a separate, high-speed CAN FD bus.
Benefit: It allows you to run your swerve motors at a much higher refresh rate (250Hz vs 50Hz on the native RIO bus). This significantly improves the responsiveness and smoothness of your swerve drive control loop.
Coordinate Systems & Reference Frames
Every drive command is relative to something, either the robot or the field. Which one you pick changes how the robot responds to the sticks.
Robot-Centric (Robot Frame)
All movements are relative to the robot's current orientation. Forward is always toward the front of the robot.
- Forward:Robot moves in the direction it's facing
- Strafe Right: Robot moves to its right side
- Use Case: Precise maneuvering, driver preference
- Control: More intuitive for beginners
Field-Centric (Field Frame)
All movements are relative to the field. Forward is always away from your driver station, regardless of robot orientation.
- Forward: Robot moves away from driver station
- Strafe Right: Robot moves right on the field
- Use Case: Competition driving, intuitive control
- Requirement: Needs gyro for robot heading
Gyro Requirement for Field-Centric
Field-centric control requires a gyroscope (IMU) to track the robot's heading. Without an accurate heading, the robot cannot determine which direction is "forward" relative to the field.
Common gyros in FRC:
- Pigeon 2 (CTRE) - CAN-based, highly accurate
- NavX (Kauai Labs) - USB/SPI, popular choice
- ADIS16470 (Analog Devices) - SPI, WPILib support
Swerve Kinematics & Control
Kinematics is the mathematical relationship between the desired robot motion (velocities in X, Y, and rotation) and the individual wheel states (speed and angle) needed to achieve that motion.
📐 Forward Kinematics
Converts individual wheel states into overall robot velocity. Used for odometry and determining where the robot is moving.
Given: [FL, FR, BL, BR] module states
Calculate: Robot velocity (Vx, Vy, omega)Example: If all modules point forward at the same speed, the robot is moving straight forward with no rotation.
📐 Inverse Kinematics
Converts desired robot velocity into individual wheel states. Used for teleop driving and autonomous path following.
Given: Robot velocity (Vx, Vy, omega)
Calculate: [FL, FR, BL, BR] module statesExample: To strafe right while rotating, inverse kinematics calculates the unique angle and speed for each module.
🔧 CTRE Handles Kinematics Automatically
CTRE's swerve implementation handles all kinematics calculations internally, so you never compute wheel states by hand.
The CommandSwerveDrivetrainclass uses Phoenix 6's built-in kinematics to convert your desired chassis speeds (Vx, Vy, omega) into the appropriate module states automatically.
🎮 Understanding Chassis Velocities
Chassis velocities represent the desired velocity of the robot as a whole:
The ChassisVelocities type
ChassisVelocities, and its fields are vx, vy, and omega — three numbers describing how the whole robot moves.Vx (Forward/Back)
Vy (Left/Right)
Omega (Rotation)
Odometry & Pose Estimation
Odometry is the process of tracking the robot's position and orientation on the field by integrating wheel movements over time. Accurate odometry is essential for autonomous navigation and field-aware control.
🗺️ Pose2d: Robot Position on the Field
The robot's pose consists of three components:
X Position
Distance along the field length. X increases as you move away from the driver station. Units: meters.
Y Position
Distance along the field width. Y increases as you move to the left. Units: meters.
Rotation
Robot heading (which direction the robot is facing). Represented as Rotation2d. 0° = field forward.
Field Coordinate System
The field coordinate system origin (0, 0) is at the right corner on the blue side of the field. X increases as you move away from the driver station, Y increases as you move to the left, and rotation is counter-clockwise positive.
How Odometry Works
📊 Wheel Odometry
Primary odometry source using encoder readings from swerve modules.
- Inputs: Module positions (distance traveled + angle)
- Process: Forward kinematics converts module deltas to robot motion
- Integration: Accumulates motion over time to track pose
- Accuracy: Drifts over time due to wheel slip and measurement errors
📸 Vision Odometry
Secondary odometry source using camera and AprilTag vision targets.
- Inputs: Detected AprilTags with known field positions
- Process: Camera calculates robot pose from tag positions
- Integration: Fused with wheel odometry for drift correction
- Accuracy: More accurate but only works when tags are visible
🔀 Pose Estimation with Sensor Fusion
CTRE's CommandSwerveDrivetrain includes built-in pose estimation that fuses wheel odometry with vision measurements using a Kalman filter approach.
This provides more accurate position tracking than wheel odometry alone, automatically correcting for drift when vision targets are visible.
📝 Odometry Code Examples
What's Next?
Ready for Implementation
That covers the fundamentals: module anatomy, robot-centric vs field-centric control, gyro requirements, kinematics, odometry, and pose estimation.
Next, you'll use Phoenix Tuner X to generate a complete swerve project and bring up your drivetrain.