Team 254 Presents: FRC 2018 Code


Team 254 is proud to present the code for our 2018 robot: Lockdown. If you have any questions, feel free to ask!

Some highlights from this year’s code:


Link to the repository:

double scale = 1.2 * p0.getTranslation().distance(p1.getTranslation());

I understand performing sine and cosine on the heading to get the individual dx and dy components. But why did you multiply by 1.2 * euclidean distance between the two points?

I want to congratulate you all on the wonderful season you all had! We implemented the non linear trajectory follower (software mentor Jared Russell posted a link to the paper in the FRC Discord a couple months ago) and we are liking its performance so far!

Thanks for the resources!


Fun! Some pretty cool stuff here for sure. I’m certainly a fan of all the nifty controls stuff we see out of you guys. Thanks for publicizing!

public static final double kJazzHandsEpsilon = 2.5;

I have found my new favorite public static final double.

public final static double kPoopyShootSetpoint = .40;

What about this one?


I am guessing that Mario (the student who wrote all of our spline code) found that this led to better-looking paths. When fitting parametric quintic splines to a start and end pose, it’s important that the ratio of dx to dy on the endpoints is consistent with the cos/sin of the heading, but the precise magnitude of the values can be anything.

This is also true of the second derivatives (the ratio must match the desired curvature, but the magnitudes are a free parameter). In our 2014 code (and in Pathfinder), the curvature at knot points is generally set to 0 so this isn’t a problem. In our 2018 code, Mario wrote an optimizer to choose second derivatives that minimize the rate of change of curvature (maximize smoothness) over the path. You could imagine doing something similar for the magnitudes of the dx and dy components.


This was the perfect constant for powering the intake motors so that they couldn’t push out the cube with another cube in the way, but just enough so the cube would come out when you backed the robot up. Good for placing a cube in a precarious slot where you couldn’t open the intake arms and risk knocking a cube off.


I notice you have a shuffleboard save file checked in. Do you have any feedback or suggestions?


This might have been answered somewhere else maybe even a long time ago since this also applies to your previous code bases: Why do you use a separate thread for autonomous? Is this so you can have slightly smoother turns and speeds or so it won’t crash the entire robot?

To me it seems like making everything that autonomous uses thread safe wouldn’t be worth the hassle but I’m guessing there’s a reason for this?


I’m interested in the materials that surround your code. It doesn’t use much of the WPIlib base, from what I can tell, mainly just uses it for the hardware layer. How are you introducing your new students to this architecture?