Team 254 2013 FRC Code

[Tom Bottiglieri]

Hi everyone,

Now that the official 2013 FRC season has come to a close, we would like to share the software that drove Overkill with the FIRST community. We have released our code to the public every year since 2010 and the programming sub team is especially proud of the work they have put together for the 2013 submission.

This year we made the switch from C++ to Java. We did this as the Java tools can be run on any platform and are freely available to download on the Internet, which made it very easy for our students and mentors to hit the ground running and contribute commits. Java is also taught in the school, so we figured this would be a great way for students to apply the skills they are learning in the classroom.

https://github.com/Team254/FRC-2013

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!

[Kusha]

The link is 404ing for me.

EDIT: Now it's working, thanks 254!

[JesseK]

Works fine here.

[Tom Bottiglieri]

Originally Posted by Kusha

The link is 404ing for me.

It took a second for the repo to go public (we use Github's private repo feature to develop our code). Check again now!

[hiyou102]

The auto hang code is amazing!

Originally Posted by Tom Bottiglieri

(we use Github's private repo feature to develop our code).

Do you guys use the educational offers that GitHub has? If you don't, you should consider it. My team got a 2 year bronze plan for free that way.

Also, why does your code style talk about enums, even though they aren't available in JDK 1.4?

[Pat Fairbank]

Originally Posted by hiyou102

Do you guys use the educational offers that GitHub has? If you don't , you should consider it. My team got a 2 year bronze plan for free that way.

Also, why does your code style talk about enums, even though they aren't available in JDK 1.4?

One of our leaders got in touch with GitHub a few years back and got us free private repos. We have more than 10 so I'm not sure what plan we're on, but we haven't been sent a bill so I'm not about to complain.

We ported the style guide over from our C++ one before discovering the (many) limitations of Java ME. Enums aside, we could have made the constants management stuff a lot cleaner with generics and reflection.

[joelg236]

Originally Posted by Pat Fairbank

We ported the style guide over from our C++ one before discovering the (many) limitations of Java ME. Enums aside, we could have made the constants management stuff a lot cleaner with generics and reflection.

Generics... I wish...

[joelg236]

I did a diff on your CheezyGyro class, and the only important change was making initGyro() public. Is this only to calibrate the gyro when you want to? Why didn't you just adjust it in the wpilibj and compile with the custom version?

[BigJ]

Originally Posted by joelg236

I did a diff on your CheezyGyro class, and the only important change was making initGyro() public. Is this only to calibrate the gyro when you want to? Why didn't you just adjust it in the wpilibj and compile with the custom version?

Then anyone checking it out would have to have the modified WPILibJ

[joelg236]

Originally Posted by BigJ

Then anyone checking it out would have to have the modified WPILibJ

I suppose so. Although who would compile it? Not everybody has an Overkill

[BigJ]

Originally Posted by joelg236

I suppose so. Although who would compile it? Not everybody has an Overkill

Any other 254 programmer with a new dev environment?

[joelg236]

Another question, I haven't seen a single final variable, even in cases where I can't see a good reason not to. Any reasoning behind that or is it just because you know you won't write code to mess with them?

[xmaams]

You actually can use the DPad up and down if the switch on the controller is set to D. Then it is axis 6.

[JesseK]

Originally Posted by joelg236

I did a diff on your CheezyGyro class, and the only important change was making initGyro() public. Is this only to calibrate the gyro when you want to? Why didn't you just adjust it in the wpilibj and compile with the custom version?

In industry, modifying the source of an external library is a bad practice that should be avoided if a better technical solution exists.

The bigger issue is if the other library receives updates from the original source. Then you have to re-implement the changes into the updates. If the custom change were in runtime logic (not detected by a compile error, like the Poof's would be) then your robot wouldn't act correctly, causing a lot of wasted time in trying to figure out why.

Here's an example of a situation where I was forced to modify COTS code at work. It required a full write-up and sign-off by the program manager. This type of thing isn't detected by a compiler, but it caused several runtime Exceptions when we tried to load the map format.

At work, we use NASA WorldWind. WorldWind has some static file name extensions that are hard-coded to lower case. On Linux, the files we have are upper case, and case matters on Linux. One of the map formats we use contains the upper-case file names in a header table embedded within a single file binary file -- not possible to change. Additionally, if the issue were brought up to NASA, the fix would likely be seen in WorldWind 1.5 or 1.6, whereas we're using 1.4. WorldWind 1.5, at the time the decision was made, was having hotspot issues on Linux -- so waiting for a fix in an update was considered a risk. Thus, we had to modify WorldWind's code (added .toUpperCase() in the proper spots). We then CM'ed the specific patch files so we would know exactly what changes had to be made in the future. Any time we want to update WorldWind (perhaps in the project's next iteration), we can pull the patch files out of the code repository and analyze if they're still relevant.

[dellagd]

As a Java programmer, lets just say this has fulfilled the second letter of this great organization we compete in for me.

*picks jaw up off of floor*