Team 2910 Code Release 2019

Team 2910 is proud to release the code for our 2019 robot!

The code is split into two parts. The common repository contains swerve logic, trajectory generation, and swerve module implementations. The 2019 repository contains all the year-specific code.

Some features of the 2019 robot code include:

  • Vision targeting to help line up for placing/picking up hatches
  • Choice between driver controlled and hybrid sandstorm modes
  • Climbing macro
  • CAN communication on separate threads
  • Includes common library though Git submodule and Gradle subproject

Some features of the common code include:

  • Trajectory generation
  • Custom trajectory constraints
  • Ability to specify robot rotation along a path
  • Reusable base swerve code
  • Easily implementable swerve module base class
  • 5ms control loop

Questions are welcome!


Thanks Jacob


Did you use a Limelight this year for vision?

They did use limelights.

1 Like

We almost have the MK2 modules assembled and am trying to get the code ready. The readme file on github says we have to import the FRC Team 2910 Common code repository. We downloaded and installed the Git software. I entered, “git submodule add jester” into the Git Bash program but get an error stating, "fatal: not a git repository (or any of the parent directories): .git ". What am I doing wrong?

You need to make sure that the current directory is a Git repository if you want to use Git submodules. You can initialize a new repository in the current directory using the git init command.

Jonathano is correct, using the Common library as a submodule requires that you have a local git repo already initialized.

If you’re trying to clone the 2019CompetitionRobot-Public project, you don’t need to add a submodule, as it’s already added. Instead, you’ll need to run git submodule init and then git submodule update in the root of the cloned project.

If you’re making a new robot project, run git submodule add jester (note the -Public in the Github URL) in the root of your git repo (robot project), then follow the remaining instructions in the readme (adding lines to build.gradle and settings.gradle).
Alternatively, you can also just download the Common library (eg as a .zip from GitHub) and slap it into a folder called “jester” in the root of your robot project in lieu of using git submodules. You’ll still need to add the lines to your .gradle files.
In the end, you just need a folder structure of /jester/robot/src/... in the root of your robot project as well as the lines in build.gradle and settings.gradle to use the Common library. However you do that – git, manually, whatever – doesn’t particularly matter, though each method has its benefits and drawbacks.

For the MK2 modules, the driver is currently in the 2019CompetitionRobot-Public project, direct link to file. You’ll need to use this driver (unless you want to re-implement your own), and you can essentially copy it and just change the package path, assuming your dependencies are all imported properly. We haven’t transferred it over to the Common library yet, but will eventually.
Also take a look at for how we initialize and use these modules.

Let me know if you have any issues with this.


Thank you. The issue was adding -public to the Github url.

We are diving into 2910 codes now and trying to make it work for our nearly built MK2 Swerve drivebase.

The 2019CompetitionRobot code lists the angle motors being controlled by Spark speed controllers. I thought I remember you used all Spark Max speed controllers. Did you change to Sparks?

1 Like

The steering motors are NEOs so they were controlled by Spark Maxs. The Spark Maxs for steering were connected to the Rio via PWM. I am not a code expect, but I expect this is why the code lists them as Sparks.


Why did you choose to connect your steering motor controllers to PWM instead of thru CAN?

For the NEOs, all PID, motion profiling, and path following is being done onboard the RIO.

We used PWM for the steering motors for the theoretically lower latency. Please note that we did not actually verify if the latency was less than with CAN bus.

The spark maxs for Drive are on CAN because we are using the integrated encoders for odometry and to get the encoder data back to the RIO CAN is required.