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
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.