Team 254 Presents: FRC 2016 Code

[maxwelly]

Hi everyone, Team 254 is happy to share the code base for our 2016 robot, Dropshot.

This year, for the first time, we provide detailed code documentation in the README file and in each Java class. We explain each class and its interactions with other components. In this repository, we also include the code for the CheesyVision computer vision app for Android.

Robot Code: https://github.com/Team254/FRC-2016-Public

[thatprogrammer]

Excellent code!
Just one immediate question:Why did you chose to just post this now despite this being public on your GitHub repo for quite some time now?

[dirtbikerxz]

COOL! Thanks for the CODE guys! Definitely useful too look at. Now all we need are the CAD files. Feel free to pm it to me any time .


Anyway, good job on this guys.

[Bkeeneykid]

I can't wait to give this to our programmers to ogle at. Awesome work every time, 254!

[Poseidon5817]

Originally Posted by thatprogrammer

Excellent code!
Just one immediate question:Why did you chose to just post this now despite this being public on your GitHub repo for quite some time now?

Same, I read all their code weeks ago

[Cothron Theiss]

Originally Posted by thatprogrammer

Excellent code!
Just one immediate question:Why did you chose to just post this now despite this being public on your GitHub repo for quite some time now?

Originally Posted by Poseidon5817

Same, I read all their code weeks ago

It looks like some of the CheezDroid code was updated recently. They may have wanted to do some final cleaning and get everything out there before doing the CD release.

Originally Posted by dirtbikerxz

Now all we need are the CAD files.

...

Originally Posted by Travis Covington

We have no plans to release the CAD of the robot but are happy to answer any questions you have.

I'd love to look through their CAD files, but I can understand why they don't release those.

[kylelanman]

The work you did around kinematics, poses, and latency compensation was truly remarkable and inspiring. Dropshot was my favorite robot to watch and the best designed robot for Stronghold in my opinion.

I do have one question. Why were JNI and the C++ OpenCV libs used oppose to the Java OpenCV libs? If I recall correctly Jared said at the world championship talk that the performance between the C++, Java, and python OpenCV libs were essentially the same.

[Jared Russell]

Originally Posted by kylelanman

I do have one question. Why were JNI and the C++ OpenCV libs used oppose to the Java OpenCV libs? If I recall correctly Jared said at the world championship talk that the performance between the C++, Java, and python OpenCV libs were essentially the same.

3 reasons:

1) We found that of the various methods available for grabbing and decoding an image out of the camera buffer, this was the fastest.

2) It let us minimize memory allocation and buffer copying in the most performance-critical part of the code.

3) We already had a working C++ vision prototype for the Tegra, so all we had to do was copy and paste.

[Turing'sEgo]

This is an extremely large project in the scope of FRC (but excellently done). How does the team handle development? Do you follow a development methodology? I assume you have multiple students working on various parts at the same time, how does version control work? Check out with merge requests?

Non-sequitur question: Where do you programmers ultimately end up beyond frc? Year after year quality code is released (and has been since at least 2011), and the knowledge your graduated programmers must have is well beyond that of your typical freshman cs student.

[Jared Russell]

Originally Posted by Turing'sEgo

This is an extremely large project in the scope of FRC (but excellently done). How does the team handle development? Do you follow a development methodology? I assume you have multiple students working on various parts at the same time, how does version control work? Check out with merge requests?

Non-sequitur question: Where do you programmers ultimately end up beyond frc? Year after year quality code is released (and has been since at least 2011), and the knowledge your graduated programmers must have is well beyond that of your typical freshman cs student.

It's pretty informal. We all worked on our various pieces and commit to head/email patches as we go (occasionally there's a long-running branch, but we try to avoid that). Typically in the lab or at competition, we had one person on a laptop and push all of the changes at the end of the night (and we take another computer and find a quiet spot to iron out a problem in parallel if it takes more time, then merge). We did occasionally have build breakages or regressions (most of our students are new to git) but nothing that was ever particularly impossible to iron out.

I can't really answer the second question very well - I have only worked with the team for 3 years so all of the programmers are either still on the team or in college. Perhaps someone else can speak to history before that. More generally, I can speak to the team's approach to programming the robot for the last 3 years. Programming an entire 254 robot to the level of performance the team demands is a challenge for experienced software engineers, let alone high school students (and on our team at least, it seems that the more capable and brilliant the student, the more other demands are made on their time by school, the team, or other activities). We try to divvy up tasks among the team based on interest, ability, and time commitment; both students and mentors make direct contributions to the code.

For younger students, it is expected that by and large their job is to learn, be self-starting/pursue additional learning opportunities, and make small contributions as they are able. The more experienced students should take ownership (or at least, co-ownership with a mentor) over some area of the code. For example, in 2014 we had a student (now in college) take ownership over our autonomous spline-following routine (deriving all the math and peer-programming the implementation with me). He definitely graduated high school knowing more about robot navigation than most college graduates. Similarly, a student last year made great contributions to our vision algorithm; he now knows more about computer vision than most college students.

Most of the programming students from last year are returning this season (and some of the mentors are stepping aside), so I'm looking forward to seeing what they do next year!

[Alon]

Thank you guys for your great contribution to the FRC programming community.
We can all learn from you team

[Tom Bottiglieri]

A quick note on the vision app and the motivation behind using Android.

We started the year under the mindset that we could build a protected zone shooter, but quickly realized with some prototypes and strategy sessions there was serious value to be had by building a small robot that could both go under the bar and shoot from anywhere near the tower. We knew this would require a very good vision system for our robot and got to work trying to make something to run on the NVIDIA Jetson board. This board proved to be very capable of processing frames (in fact, the best performance we got all year was an early prototype running on this board), but had some issues with power up/down reliability. We debated using a computer with a battery built in, but settled on Android because it was cheaper and "cooler".

The app was designed to work well on the hardware we selected for the robot (Nexus 5), but we have seen weird bugs on other devices. For instance, the framerate is worse and the picture is upside down on my Nexus 5X. I'm sure there is a perfectly reasonable cause for this, we just haven't felt the need to fix bugs for platforms that weren't on our robot. If you find bugs in the app or make it work on a new platform, feel free to submit a pull request and our students will review it.

[Eugene Fang]

Originally Posted by Tom Bottiglieri

the picture is upside down on my Nexus 5X.

Apparently the camera module in the 5X is upside down due to packaging reasons. There's a software flag that apps are supposed to read to get camera orientation, but many (like the Augmented Reality feature in eDrawings) don't do it right...

[kingca]

How were you guys able to calculate the traction?

[Jared Russell]

Originally Posted by kingca

How were you guys able to calculate the traction?

I'm not sure what you're referring to? We did have a "traction control" mode that used closed-loop speed feedback along with a gyro to cross defenses while remaining straight, but this didn't require calculating traction.