Swerve Drive: Omnidirectional Movement with YAGSL
Understand swerve modules and stand up a working swerve drivetrain quickly with the YAGSL library on Kraken/NEO modules.
Sign in to track progress, earn XP, and save lessons.
Swerve drive lets every wheel both spin and steer independently, so the robot can translate in any direction while rotating — a major maneuverability advantage for lining up Hub shots and weaving through traffic in REBUILT. It is more complex than tank drive, but modern libraries make it reachable for ambitious second-year teams.
How a module works. Each swerve module has two motors: a drive motor (speed) and a steering/azimuth motor (wheel angle), plus an absolute encoder (commonly a CANcoder) that knows the wheel's true heading even at power-on. A robot typically has four modules. Common COTS modules pair a Kraken X60 (integrated TalonFX) or NEO with an absolute encoder. The drivetrain also needs a gyro — the Pigeon 2.0 is a standard CTRE choice — to track field-relative heading.
The math, conceptually. Swerve kinematics takes a desired chassis motion (forward, strafe, rotate) and solves for each module's required speed and angle. WPILib provides SwerveDriveKinematics and SwerveModuleState for this, but writing it all from scratch is a big undertaking with many failure modes (offsets, inversions, gear ratios).
Why YAGSL. YAGSL (Yet Another Generic Swerve Library), developed by current and former BroncBotz (Team 3481) mentors, is designed so teams of all experience levels can run many types of swerve module from a JSON configuration instead of hundreds of lines of code. You describe your modules — motor types, CAN IDs, the absolute-encoder offset, gear ratios, wheel positions — in config files, and YAGSL handles the kinematics, odometry, and module control.
The single most important setup step is the absolute encoder offset: with the robot's wheels physically aligned forward, you record each encoder's reading and enter it as the offset so 'zero' means 'pointing forward'. Get this wrong and the robot drives in nonsensical directions — it is the classic first-swerve bug. After offsets, verify each module individually: command a small forward speed and confirm all four wheels point forward and roll the same direction.
The case study mindset. Many top teams now run swerve, but it is a deliberate jump in scope: more motors (8 vs 2), more CAN devices, tighter mechanical tolerances, and more to tune. The strategic question is honest — does omnidirectional movement win you enough in this game to justify the build and debugging cost over a well-executed tank drive? For a team ready for it, YAGSL plus quality COTS modules is a fast credible path, and pairing it with the AprilTag pose estimation from the next lesson unlocks automated alignment to the Hub.
Key takeaways
- Each swerve module has a drive motor, a steering motor, and an absolute encoder (e.g. CANcoder); four modules plus a gyro like the Pigeon 2.0 make a swerve drivetrain
- YAGSL configures swerve from JSON (motor types, CAN IDs, offsets, gear ratios) instead of hand-writing kinematics
- Setting the absolute-encoder offsets so 'zero = forward' is the critical first-swerve step; verify each module individually before driving
Lesson quiz
RequiredAnswer all 3 questions correctly to complete this lesson.
1.How many independently controllable motors does a single swerve module typically contain?
2.What capability makes a swerve drive 'omnidirectional' compared to a tank/differential drive?
3.How does YAGSL (Yet Another Generic Swerve Library) primarily let teams configure their swerve drive?
Answer every question to submit.