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
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 https://github.com/FRCTeam2910/Common.git 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 https://github.com/FRCTeam2910/Common-Public.git 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 DrivetrainSubsystem.java for how we initialize and use these modules.
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?
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.
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.
The modules are assembled and our code is responding to the joystick inputs as expected. However, the wheels rotate when the robot is enabled. So driving and strafing is always of by about 45 degrees. I’m assuming we need to tune the offsets and maybe change the gyro settings. That leads me to two questions…
How would you set the offsets?
We have mounted the NavX upside down. In this orientation it reads the yaw(Z) as plane parallel to the floor. Do we need to change the code since the 2910 NavX was mounted differently? If so where in the code would we make this change?
Anything else we would need to tune before it is ready for the field?
Fixed… We had to recalibrate the gyro. Then we could guess and check until we got the wheel modules aligned correctly.
New issue and we should be running…
The back left wheel module drive motor should be spinning in the same direction as the front left, but it is opposite. Where in the code can I invert the direction of the back left wheel module?
If you want to flip the direction that the wheel spins my recommendation is to add 180° to your offset. That’s what we do in our code
Also, when we set our wheel offsets first we set all our offsets to zero and upload that. Then we align all our wheels so that theoretically if we drove in that direction we would move forwards (I recommend using a straight piece of material such as 2x1 or something to make sure they are straight). Then we set our offsets to the angle read by the modules multiplied by -1. You multiply the angle by -1 so that when the offset is added to the measurement from the encoder we would get 0 when the module is pointed forward. Then, as I said before, if any modules drive the opposite direction add 180° to the offset.
Another note, all our angles are in radians so you’re gonna want to use Math.toRadians/Math.toDegrees to make them more friendly
How did you guys end up implementing the swerve drive? We’re trying to figure out 2910s code but can’t get it to work. Is there any way we could see what you did? Thanks!
Jacob Bublitz @Kaboomboom3 has joined me to help with programming support. Jacob has made Java base code for robots with MK2 Swerve Modules using NEOs. The code is made to work with Xbox or Logitech F310 gamepads.
You will just need to configure some basic things:
Team number
Wheel base
Track width
Can IDs (for drive motors)
PWM ports (for steering motors)
Analog ports (for steering encoders)
Calibration offsets for module steering angles
The base code is already working, but there is a little more testing/documentation we want to do before we release it. It should be live on the Swerve Drive Specialties github before the end of October.
Any way we could get an early release of the code (ASAP)? We have an off-season event Nov 4 (Robot Rewind). We have modified 2910 code but it can be kind of touchy. I’d love to test a more stable code at Robot Rewind.