Team 254 - 2014 FRC Code
 

Hi everyone,

We would like to share the software that controlled Barrage in its quest for the 2014 FRC Championship.

Our robot ran Java this year as it did in 2013. To develop Barrage, we added a bunch of new features like waypoint navigation that drives smooth splines, an internal web server for debugging controllers and modifying robot constants, Cheesy Vision, single threaded autonomous scripting, and more. Check it out!

https://github.com/Team254/FRC-2014
and
https://github.com/Team254/TrajectoryLib

If you have any questions please do not hesitate to ask... We love talking about our work! Also please feel free to try/learn from/re-use this code as much as you see fit.

Thanks!

Re: Team 254 - 2014 FRC Code
 

Great work guys for doing this!

Re: Team 254 - 2014 FRC Code
 

Thank you so much for posting these; they're really an inspiration for our programming team. The trajectory generator and spline classes are really, really awesome.

I do have a few questions:

1. What is the negative inertia accumulator in Cheesy Drive? I've seen it in previous code releases, but I have no idea what it does.

2. Why didn't you guys use the included math libraries? I'm not following your code entirely.


BTW, I love the rainbow "Teh Chezy Pofs Deta Lawgr"

Re: Team 254 - 2014 FRC Code
 

Typically when you command a robot to rotate and then let go of the joysticks, it may continue to turn slightly due to inertia. The negative inertia in Cheesy Drive reduces (prevents?) this turning overshoot and makes the robot more intuitive to drive.

Re: Team 254 - 2014 FRC Code
 

How did the web app help with development?

Re: Team 254 - 2014 FRC Code
 

Thanks Tom, I look forward to reading through your code.

Re: Team 254 - 2014 FRC Code
 

Do you have any overall documentation on what the code is actually doing, a high level description document? It's not abundantly clear looking through the code how it all works, and what and why it's actually doing it (although in general it looks very well put together, partitioned, and coded).

Some questions:
What are the waypoints referencing and how were/are the derived?
What input is used to select a trajectory?
Are the trajectories/waypoints only used during autonomous or can you somehow pick a way point during teleop and minimize driver work-load?

Re: Team 254 - 2014 FRC Code
 

Yeah, we can put something together. We really just wanted to get this out before the summer and haven't quite had the bandwidth to put this together yet.

The waypoint system is for autonomous only. Basically, you can specify a list of waypoints where the start of the path is (0,0,0) in (X,Y,Theta). We calculate a spline that intersects each waypoint at the desired angle. From there we generate a set of (Position, Velocity, Accel) for each wheel at 0.01 second time steps along that spline. This calculation is done off board as the spline formation is pretty cpu hungry. We serialize the data and load it on to the crio as a text file which gets deserialized. The trajectory construction happens in the TrajectoryLib project in Main.java. The trajectories get deserialized and stored in memory in AutoPaths.java.

In autonomous, we load a path into the TrajectoryDriveController and set the Drivebase subsystem's active controller to that. (Each subsystem can have one active controller which controls it).

We do some driver off-load things, but mostly for the operation of the intake and shooter subsystems (for example there is a button that deploys the intake and runs automatically until we sense we've picked up the ball, we only shoot for certain presets once the wheel is settled at speed, etc).

Re: Team 254 - 2014 FRC Code
 

Ok Tom, you're going to have to help me understand some of these negative inertia steps as I really like the idea a lot.

Here you calculate what the negative inertia is between the last turn iteration and the the current one. So if you are turning full left and decide to stop the negInertia is 1 and the old turn value is now 0. Understood so far.
Next you determine your negative inertia scaling value based on high or low gear. Understood because you'll be turning faster in a higher gear and the robot is not going to want to slow down as quickly in high gear so more drift meaning a higher scaling value is needed. Still following.
Next you calculate what power you're going to need by multiplying your negative inertia by the scaling value and add this to the accumulator value. Then you add this value to your turn value to counter the inertia. Still following.
This is where you lose me. From what I understand from this next bit of code you are increasing/decreasing the inertia accumulator by 1 to get it closer to zero, if it is -1 <= x >= 1 then you set it to 0. This makes sense as you'll want the negative inertia to get smaller as the robot slows down. Where I'm lost is the fact that negInertiaAccumulator is never used again in this method, and it's a local variable so its lost after the method is complete. This means on the next run through of this method all of the negative inertia work is lost and the correction is only done for one iteration. What am I missing?

Re: Team 254 - 2014 FRC Code
 

That trajectory stuff is so cool. No wonder you guys are world champions. And it makes the actually robot code so much more simple. We might actually look into doing something similar but even for just straight lines. Should allow much more accurate autos. Plus the simpler the robot code the better.

Re: Team 254 - 2014 FRC Code
 

I don't know why they didn't use the included math libraries, which AFAIK would return the exact same values as theirs does, but "their" code comes from here.

http://developer.nokia.com/community...acos-asin-atan

Re: Team 254 - 2014 FRC Code
 

Good catch. That's a bug. The original C++ code from 2011 had the accumulator as a member variable.

Re: Team 254 - 2014 FRC Code
 

I've been playing around with the trajectory planning software, and I'm working on an application to quickly input waypoints, visualize output, then FTP to cRIO.

Right now, I'm got it set up so that I can input a bunch of waypoints and have it spit out graphs of robot position, and the trajectories are really amazing. The path is smooth and makes sense, and robot motion is super smooth.

There is one possible bug that I've seen. Sometimes it makes a path that travels the correct x and y distance, but doesn't start at (0,0). Usually it does. Maybe I'm just not understanding it right?

The only thing I haven't been able to make it do is a full 180 degree turn.

See some pictures here:
http://imgur.com/a/Q4RPw

The program-a work in progress- (which is fun to play with):

https://drive.google.com/folderview?...&usp=sha ring

How exactly does the calculation for finding the splines work? Would there be a way to modify it so that you can enter a waypoint that is just a position, and has no heading?

Re: Team 254 - 2014 FRC Code
 

So one of the caveats of the Trajectory generator that I forgot to mention is that it does not account for motor saturation. If you try to make a turn too quickly and the motors cannot keep up, it will go off path. We had thought about building something that could fix the cross track error but it was just easier to make safe paths.

Re: Team 254 - 2014 FRC Code
 

I'd like to try your program, but the file linked isn't working for me.

I'm not 100% exactly sure how 254's code works, but I'd be willing to bet it uses something similar to what is described in this article. They can just chain the splines together and end up with a continuous and differentiable (smooth) curve because they can set the slope at the beginning and end of each segment equal.