Swerve Drive Prerequisites
Understanding Swerve Drive Fundamentals
Before diving into swerve drive implementation, it's essential to understand the core concepts, hardware components, and control systems that make swerve drive possible. This foundation will prepare you for successfully creating and tuning your swerve drivetrain.
Key Concept: Master the fundamentals of swerve drive: holonomic motion, coordinate systems, module anatomy, and field-centric control.
Swerve Module Anatomy
Each swerve module consists of three key components that work together to provide independent wheel control:
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
Proper wiring and CAN ID configuration are essential for a reliable swerve drive. We recommend the following standard configuration for 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
Understanding coordinate systems is crucial for swerve drive control. You need to know whether movements are relative to the robot or the field.
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
The good news: CTRE's swerve implementation handles all kinematics calculations internally. You don't need to manually compute wheel states!
The CommandSwerveDrivetrain class uses Phoenix 6's built-in kinematics to convert your desired chassis speeds (Vx, Vy, omega) into the appropriate module states automatically.
🎮 Understanding Chassis Speeds
Chassis speeds represent the desired velocity of the robot as a whole:
Vx (Forward/Back)
Linear velocity in the X direction. Positive = forward, Negative = backward. Units: meters per second.
Vy (Left/Right)
Linear velocity in the Y direction. Positive = left, Negative = right. Units: meters per second.
Omega (Rotation)
Angular velocity (rotation rate). Positive = counter-clockwise, Negative = clockwise. Units: radians per second.
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
You now understand the fundamental concepts needed for swerve drive:
- Holonomic motion and independent module control
- Module anatomy: drive motor, azimuth motor, CANcoder
- Coordinate systems: robot-centric vs field-centric
- Gyro requirements for field-centric control
- Critical safety practices and zeroing procedures
- Swerve kinematics and control
- Odometry
- Pose estimation
Next, you'll learn how to use Phoenix Tuner X to generate a complete swerve project and bring up your drivetrain.