Team 5895 Code Release for 2016

[AGPapa]

Peddie School Robotics is happy to share the code for our 2016 robot.

This software is heavily inspired by 254’s past code releases (thanks!). Some changes from 254’s past code include the lack of complex inheritance structures and extensive use of the new Java 8 functional interfaces. This was the students’ first year in FRC and I’m very impressed with how quickly they learned and how much they accomplished.

Our autonomous framework made it easy for students to write and test their own autonomous routines using the same subsystem method calls used in teleop. The “Waiter” class in particular uses functional interfaces to let the robot reach any arbitrary condition before moving on to the next command.

Take a look at our repo here and let me know if you have any questions about the code.

[thatprogrammer]

Thanks for the code release, some of the code is really nice! That said,I'm not following how your vision works. It appears your X and Y values are being fed to you by smartdashboard somehow (Is your operator manually entering the defense position they are on?).

[virtuald]

Thanks for publishing, added it to the robot code directory!

[AGPapa]

Originally Posted by thatprogrammer

Thanks for the code release, some of the code is really nice! That said,I'm not following how your vision works. It appears your X and Y values are being fed to you by smartdashboard somehow (Is your operator manually entering the defense position they are on?).

Vision processing is done on the dashboard side (which was written in LabVIEW). It just uses the example vision code from NI.

It's not the prettiest code as it was a plan C backup after the JetsonTK1 (with power issues) and GRIP (which doesn't work for USB cameras), so I don't think we'll reuse it next year. Either way, I've attached it if you want to look at it.

Originally Posted by TimTheGreat

You guys should take a look at autonomous selectors, just to get rid of clutter. You have everything neatly organized into classes, why not go that extra step and make each separate autonomous it's own class as well?

Agreed, this was my first year with Java in FRC, and the team's first year with FRC and Java in general, we'll definitely split auto into separate classes next season.

Also, looking through some of your intake update method, it seems to always be running, since you don't have a stop mode. Am I reading this right? Seems a little dangerous.

The intake is stopped in the "has ball" state.

[TimTheGreat]

Originally Posted by AGPapa

The intake is stopped in the "has ball" state.

But what happens when the robot doesn't have a ball. On the field it might be good to always be intaking, but what about in the pit?

[AGPapa]

Originally Posted by TimTheGreat

But what happens when the robot doesn't have a ball. On the field it might be good to always be intaking, but what about in the pit?

Ah, ok, I see.

Yes, the intake is always running when it doesn't have a ball. In the pit we cover the sensor with tape before enabling it to trick it into thinking that it has a ball.

We wanted as many systems to be autonomous as possible, so the driver could focus on more important tasks than manually hitting a button to intake a ball. During a match you always want to pick up a ball if you don't have one, so the code just automates that away.

[BeckonedCall]

Originally Posted by AGPapa

We wanted as many systems to be autonomous as possible, so the driver could focus on more important tasks than manually hitting a button to intake a ball. During a match you always want to pick up a ball if you don't have one, so the code just automates that away.

Being a driver myself, I can understand wanting to automate as much as you can. I can only imagine that leaving the intake on must have drained the battery. Did you ever have issues with brown out or severe voltage drops during competitions?

[DonorConohue]

Originally Posted by BeckonedCall

Being a driver myself, I can understand wanting to automate as much as you can. I can only imagine that leaving the intake on must have drained the battery. Did you ever have issues with brown out or severe voltage drops during competitions?

Very rarely. The intake was run by a single minicim.

[AGPapa]

Originally Posted by BeckonedCall

Being a driver myself, I can understand wanting to automate as much as you can. I can only imagine that leaving the intake on must have drained the battery. Did you ever have issues with brown out or severe voltage drops during competitions?

Originally Posted by DonorConohue

Very rarely. The intake was run by a single minicim.

Just to elaborate, the intake isn't under much load when it's running and not actively picking up a ball, so it's current draw is close to the 3A free current of a miniCIM. (Actually, because we're not running it at 12V, it could be less). This current draw of the intake is dwarfed by the amout of current that the drivetrain, or even the compressor would be drawing.

In a two and a half minute match, really the only way to drain a battery is to repeatedly stall a motor. Brown outs and voltage drops also happen when there's a big spike in current draw (like when a 6 CIM drive gets into a pushing match), a small motor pulling ~3A wouldn't cause those things.

[TimTheGreat]

I like the state machines for teleop. Kind of similar to RobotPy's statefulAutonomous. Take a look at it here. It basically allows you to divide autonomous functions into states, and you can advance based on time or whenever you feel the state is over.

I really liked this feature of RobotPy, and since I wanted it for FTC, I mostly ported to Java. Take a look. It works pretty much the same way. As long as you implement the interface, all should work.

You guys should take a look at autonomous selectors, just to get rid of clutter. You have everything neatly organized into classes, why not go that extra step and make each separate autonomous it's own class as well?

As unorthodox as it is, I like the sped, speed, and speeed. Any reason you didn't declare the double before the switch, then assign a value to it with each case?

Also, looking through some of your intake update method, it seems to always be running, since you don't have a stop mode. Am I reading this right? Seems a little dangerous.