The 2010 FRC season has just completed,
which included Java as a programming option for the first time. We
don't have full statistics of which teams used which languages, but
we conducted surveys at several regional competitions (where “we”
mostly means National Instruments and my trusty assistant).
The sample data shows about 16% of the
teams used Java to program their robots. There was a lot of regional
variation, from 0% Java use at the Dallas and Detroit regionals to 37-40%
at the Boston and Manchester regionals. But that same 16% Java
average held true for teams at the Championship competition.
Extrapolating from that sample, world-wide there should be about 288
teams that used Java this year.
The middle of the US is looking pretty empty! We should get complete data after FIRST
conducts its “kit of parts” survey.
The Java teams did well. Some
Java teams won their regional competitions, and Java teams were in
the 2nd place and runner up positions at the world
championship! In fact, the number of Java teams in the Quarter finals
through to the Championship matches roughly tracked the percentage of
teams in Atlanta running Java.
We received feedback from in-person
surveys and on support forums. Teams were very happy to be able to
use Java because it was either taught in their high school or was
well understood by the mentors. They also liked the NetBeans
development environment and having a “safe” programming language.
But it wasn't all “teflon wheels and
traction control” (a FIRST phrase synonymous with “good”, which
I just made up). There were
definitely areas that teams wanted improved. Some common issues:
Needed more documentation:
“Big picture” overview of a robot (IterativeRobot)
- Cookbook recipes – how to setup and use a gyroscope (for example), and how to use the data
Image processing was too slow.
Careful tuning of the camera, robot code, and the Dashboard running
on the laptop was required to get reasonable performance. This
should have been pre-tuned, and the systems should have more
More diagnostics. Many, many, many
robot failures look like either “watchdog” or communication
errors, when in fact they may be wiring, low voltage, hardware,
networking, USB, field system, or software failures.
Need to log more data to detect or rule out error scenarios.
Need to present data in a way that makes diagnosis easier
Installation/version match issues
Built-in installation sanity
checks were added, but more can be done
Bugs in WPILib and Java IO
Late CAN bus implementation
I spent several days at regionals and
at the Championship helping Java teams with issues. The most
frustrating case was a Java team with intermittent field
communication errors, but we couldn't narrow the issue down to
hardware, software/Java, networking, or field issues. Another team had
some robot logic issues I was able to help with, and several teams had issues that were
resolved with wiring or component swaps. I was relieved that
the Java system itself didn't seem to be the cause of serious
Beyond looking for teams that needed help, I really
enjoyed learning what teams were doing with their robots. One
industrious team programmed their robot three times, once in C++,
couple of teams switched from Java to C++ because the CAN interface
for Java wasn't complete, but another team simply reimplemented all
of the Java CAN interfaces themselves!
The first year of Java for FRC went
well. Not without a hitch, but not bad. We'll be working with WPI to
improve the system for 2011, especially in the areas of diagnostics and
performance. And I'd like to see the use of Java for FRC world-wide
match the 30% use that we saw in New England.
I'll add in the usual disclaimers here
– speaking for myself, not for Oracle, Sun Labs, WPI, or FIRST. Any
erroneous data would be due to me.