Yet Another Generic Swerve Library (YAGSL) Beta

Hello World!

YAGSL is a Generic Swerve Library (AN ACTUAL LIBRARY!) that aims to simplify the process of creating a comprehensive and complete SwerveDrive’s with best practices from MANY SwerveDrive examples.

The documentation wiki is here.
An example project is here.
Library is here.
Javadoc are here.


  • Second Order Kinematics with limited state-space estimation.
  • Uses closed-loop PID exclusively.
  • Dashboard for each swerve module.
  • Support for both Falcon’s and Neo’s without changing any of the code base.
  • An actual library as opposed to template code.
  • Documentation, yes even javadocs.
  • Varying Encoder support.
  • Does not require a CommandBased project and could be implemented in a TimedRobot.
  • Implements WPILib’s classes RobotDriveBase and MotorSafety.
  • If a module is inaccessible/broken the Swerve Drive will still work.
  • Advanced tuning for motor controller output limits and supply amps.
  • Simulation support.
  • Low CPU utilization.

The easiest way to create a SwerveDrive is through a JSON configuration tree/directory which allows for a single small line to create the entire SwerveDrive.
SwerveDrive drive = SwerveParser.fromJSONDirectory(new File(Filesystem.getDeployDirectory(), "swerve"));
There are other ways to create the SwerveDrive but that is the easiest.

The library uses WPILib classess to ensure MotorSafety and compliance with the same parent class used for DifferentialDrive’s.

The library creates it’s own dashboard (which can be optionnaly updated in a periodic function with varying degrees of verbosity) that helps with tuning and debugging.

There is support for both Falcon’s and Neo’s WITH THE SAME CODE BASE alongside support for multiple different encoders both integrated, on the CAN bus with or without a CANivore, or directly from the roboRIO.

This implementation utilizes SecondOrderKinematics in an attempt to provide a better control system for the Swerve Drive. In addition to some state-space modeling for position estimation.

There is complete support for simulation with NEO’s however falcons require more testing/development. The configuration should be very easy for any team to use and robust enough to be applicable to most Swerve Drive’s.

I am looking for teams willing to test out YAGSL and give me feedback on what needs to be improved or configurable.

This thread will serve as another way to report issue’s if you do not submit one via github.

I hope everyone enjoys this!
Thank you!


The only configuration I have been able to test is a SDS MK4 L2 with all Neo’s, CANCoders, and a Pigeon2. Currently the only supported gyroscope is a Pigeon2. I may add NavX in the future however. I need more teams to test on their configuration!


Whoa, I didn’t actually think you’d go with my name suggestion. Schweet!


I liked it. Thanks for the recommendation!


Updated features and linked directly to swervelib.

Updated with github pages javadocs Overview

1 Like

Are there plans to support adding vision measurements to the pose estimator, or a way to expose that?

1 Like

Absolutely, I just forgot to make the PoseEstimator public!


Thanks, additionally, would we be able to set voltages to individual motors for each swerve module? We use a custom characterization command so we need voltage control over motors.


I don’t think i have one to set voltages directly but I do have one to set percentage from -1 to 1.

Is voltage compensation enabled or controllable to make this useful?

1 Like

It is! You can control it via the setVoltageCompensation function

Just added that now

Great to hear. This also doesn’t appear to support drivetrain characterization values like kS, kV, and kA. Perhaps I missed that in the docs.

I am honestly not sure how to implement that? Is there any reason it couldn’t be implemented via a SwerveSubsystem or equivalent?

The drivetrain characterization values allow you to dynamically calculate feedforward for each module. I believe 364’s template has an implementation.

Like this?

or this?

It appears I did it twice :sweat_smile:

Yeah, typically with a SimpleMotorFeedforward, but we do have measured kS, kV, and kA instead of just calculated values.


I really like the idea behind this; I think you’ll find that the architecture you’ve chosen is quite difficult to maintain in the long-term, however, due to the the tight coupling between the SwerveMotor abstract class and the particular shape of the REV API. I’d look at ways you could generalize that. You may also want to distinguish steering motors from drive motors.


I can make the feedforward public and able to be redefined. That would match BaseFalconSwerve. Or would it be better to have it configurable via JSON too?

1 Like