Feb 25, 2017 - Our finished CAD model

Stop Build Day has come and gone….

And our robot has been finished.

Introducing Hurrier!

The Hurrier

This is our robot, complete with intake, a gear handler made out of PolyCarbonate, a shooter with help from Team 95, and a climber!

After 6 weeks, we have produced this small, but elegant machine.

Our model is made out of Solidworks 2017 with the help of our CAD mentor, Mr. Best! For our robot reveal video, click this link.

Our code is still being refined to perfection! We have started to work on getting vision for the high boiler, refining values for our LIDAR sensor into something we can utilize, and controlling the shooter so we can accurately shoot and score. We also are finalizing our LED code so we can signal the driver if they are too far off in one direction on the gear peg or boiler.

Still more updates to come!

Jan 29, 2017 - Our Vision Processing

For our vision processing this year, we are using a Raspberry PI model 3B, running raspbian.

Getting Started


All you need is a raspberry pi (any model) with any debian-based OS (and possibly redhat/fedora see install.sh) and then clone the repo:

git clone https://github.com/LN-STEMpunks/WOPR-JR-Vision

Go into that directory:

cd WOPR-JR-Vision

Now, install the needed packages:


You should be ready to go!

For our default config, run:

python src/grip.py --show

We use lab.conf to define specific ranges of colors which represents the tape when lit up.

Then, we filter contours we find using a fitness function (roughly like this), which is the angle at which the contours are on a line plus the ratio between the areas of the contours, plus the difference in area of the contours, plus the distance from the center Y line.

The two points with the lowest score from this fitness function is assumed to be the contours that make up the gear peg.

This means the ones which minimize the functions are the ones that are:

  • Roughly in a flat line across the picture
  • Closest in area
  • Closest to the middle horizontal line

Then, we take their centers, average them, and predict the spring to be there (it is in the exact middle). From there, we light up some https://github.com/lnstempunks/WOPR-JR-Vision/blob/master/leds/main.ino to show if we are on target.

Through an analogous process, we will find the goal and publish it.

Jan 10, 2017 - 2017 Season Plans

Well, the 2017 FRC reveal video has been played, and our team is now in the process of creating the robot designs.

It seems unclear whether or not we focus on gears, or shooting fuel.

Here is the reveal video where FRC explains the game. If you are reading this, you’ll want to know what we are talking about.


Regardless of our robot’s function, programming has things we can do.

This year, we plan to try out Python (using robotpy).

Currently, we are using VexBot as a base, which we will mainly copy the code for whatever this years bot is. VexBot is implemented in both Python and Java. We are weighing the quality and usefullness of each to make a decision, but we hope to maintain both with equal features.

We plan to implement vision tracking for the high goal for fuel shots (using reflective tape), and auto-lineup of gear docking. This is likely using OpenCV, or a custom solution in C++/Java. We also may use a coprocessor, such as a Raspberry PI, or Jetson TX1 (which we have about 8 raspis, and 1 jetson) to track and post on networktables.

Python v. Java

For our team’s career, we have been using both Java and Python. While the team had problems with robots written in python (there were likely other problems, not just python), we are excited to try it this year.

Robotpy includes many resources, such as WPILIB implemented in python, opencv installers for roboRIOs/other ARM devices, network tables in python and JS, and more. It also includes a simulator, which allows us to simulate joysticks on the computer, without needing to be at the robot. It has much better support than the Eclipse default one distributed with WPILIBJ, and supports pygame inputs. You can also simulate joystick controllers without one plugged in; you can click buttons and twist joysticks on the screen, and it runs as though it is on the driver station. These features make it extremely easy to consider python.

If you are a new team considering python, you may want to consider it for a few reasons:

  • Python is less verbose, and is indentation based. This forces teams to use good formatting
  • The simulation feature saves a TON of time before you need to actually deploy and use the driver station

However, there are downsides to python:

  • Not officially supported by FIRST
  • Is interpereted, not compiled, so a piece of code that has never been tested may crash your robot (tests fix this)
  • May be slower

For the first point, that can be seen as a downside, but robotpy is quite stable. For example, the 2017 version was available the same day that FRC announced it’s version for STEAMworks.

The second point is probably the biggest concern: If code crashes in Java or Python, the robot stops working. However, with python some errors won’t be caught at deploy time. This means that code that hasn’t ever been tested won’t be caught at compile time, and might kill the robot.

This means it is important to write tests. Don’t worry, robotpy includes this by default. It is good practice to have tests in both Java and Python, but it is much easier to include tests in python.

The third point is true on many benchmarks, but operating a robot doesn’t take a lot of horsepower (as far as virtual horsepower goes).

Java, however, does take up much more resources for running an equivalent program in python, due to the JVM overhead. Essentially, Java will take up more RAM, and be faster at some operations (not mathematical). Python will use fewer resources, but will not run as fast. Interestingly, pure math benchmarks give python as a clear winner (because the bignum libraries are implemented in C, not Java). But, robots don’t need to be good at bignum libraries.

Python will work fine for robot code, and python won’t be bottlenecking performance.


We use github to host our projects, and slack to talk about them–.

I am still debating whether or not we should use two branches, an unstable and master, or just a master. On VexBot, we are just using a master, which I think will simplify things. We will just have to find out.

We might even use 2 or 3 branches: One for java, and one for python, and one for github-pages.

We plan on using GitHub issues to fix the robot, and using this website (or github-pages on the robot’s repo) to document how the code works.


We believe that documentation is important, so this year we are going to develop a user manual for our robot. We hope to put out a style guide so other teams can do it as well.

It will be written in LaTeX, and compiled to a PDF so that the drive team can print it out at competition, and so that in future years, we can look back and see how to use previous robots.

If we create a user manual every year, that will set a useful standard.

We also plan to have a partially complete changelog throughout the year, including daily changes. We can compile this for use in end of season awards.