3 plus/3 minus in WPILibj robotics library

WPILibJ is a library used for FIRST robotics code when programming in Java.  Helping the Stuypulse team gave me the opportunity to look at some of the code.  In honor of ship date this year, I decided to blog some thoughts on the library.  You can see the JavaDoc to follow along.

Good design point #1
The class names have strong ties to the “business.”  Class names like Joystick , DigitalInput and SpeedController are very clear and provide a mapping to a good concept.  They also encourage good object oriented code.

Good design point #2
For the most part the documentation is good and the classes logical.  Many classes have useful comments and tips on usage.

Good design point #3
There are patches released through the competition season.  Care is taken for changes to be backward compatible and not break existing code.  Much appreciated on a six week project.

Surprise #1
In the Image class, care appears to be taken for immutability (classes that cannot be changed.)  It has a package private constructor.  Only getters are provided.  The object can be written to a file, but you need to create a new object if you want to read from a file.  Then comes the surprise.  The image instance field is public!  And that public field is of type Pointer – a wrapper to native memory.   Eek.  Memory leak if you mess with it without being careful?

Surprise #2
The CANJaguar class had the biggest surprise.   When you instantiate an object, you pass the control mode.  Straightforward.  I expect the code to behave differently when different modes are passed.  Then you try to call setVoltageRampRate.  The JavaDoc clearly states what it does:

Set the maximum voltage change rate. When in percent voltage output mode, the rate at which the voltage changes can be limited to reduce current spikes. Set this to 0.0 to disable rate limiting.

Then there is what it does in reality.  If the control mode is kPercentVBus or kVoltage, a formula is used to set the ramp rate.  For the other three modes, the method does nothing.  That’s right nothing.  It doesn’t throw an exception or set it to zero or log an error or anything.  Which means you don’t realize it doesn’t do anything without reading the code.

Surprise #3
I can’t really call this a surprise as I’ve known about it since beta testing.  But I was surprised then.  Last year, there was a Dashboard class for custom output.  It was hard to use and they added a SmartDashboard class this year.  And logically, they added an interface IDashboard for the commonalities between them.  There aren’t many commonalities, but that’s not what I find surprising about the interface.

To use the old Dashboard, you write:

Dashboard d = DriverStation.getInstance().getDashboardPackerLow()

To use the new SimpleDashboard, you write:

That’s right – the new one uses statics. This is where the interface becomes confusing. If we are calling static methods, an interface doesn’t make sense.

The worst bug
The worst bug we encountered wasn’t actually in the WPILib code.  It was in the underlying National Instruments code and affected all three wrapper APIs (Java, C++ and LabView.)  The Encoder class works in an illogical manner. In particular, it only lets you use the first, third, fifth and eighth encoders to get the rate of movement.  (No, that isn’t a typo.  It is a seemingly random collection of orders rather than every other.)  That’s if you are in one mode.  In another mode, the working encoders change.  We have to fool the low level code by creating dummy ones to the “real” encoders get the proper constructor call ordering.  While this was documented on chief delphi (the unofficial FIRST robotics forums), we wasted a lot of time assuming we were doing something wrong.

The longer text for the surprises doesn’t mean that the code is bad.  Just that there is more to write about unexpected things. All in all, I appreciate all the API gives us. Congratulations to team #694 (Stuypulse) on a great build season and for completing an awesome robot on time!

ipad FIRST robotics update

In early January, I blogged about Getting my iPad ready for FIRST robotics season.  It’s now enough later to revisit that and see how things worked out.

Overall, things have gone better than expected.  For the most part, the internet has been available making searching the internet easy.


Now that I’m relying on the iPad more to check my e-mail, I’m hitting the limitations of the built in mail client.  I learned that gmail’s web application is much better.  It lets me both trash and archive, easily view labels, etc


Having the manual on hand in a searchable format has been great!  I was surprised how helpful it was to be able to zoom in on the diagrams – can’t do that with paper.  We also had to remember not to touch when pointing and discussing things.  Wouldn’t want the screen to move.  I downloaded a bunch of other documents to the iPad as well that I might want to reference.

Git Hub Viewer Lite

I’m not sure if Git Hub Viewer Lite or JDocReader is my favorite app.  Git Hub makes it easy and fast to view the code.  Looking at older code while being near the laptop with the new code has been very effective.


My other candidate for favorite application is JDocReader.  Having the robotics documentation on hand without having to changes streams from development has been great.  I don’t need to disrupt the main flow to test a theory.


iUnarchive is just a utility but it works for what I need it to.


There weren’t any lulls yet. We have a bigger group this year and there is another stream of work to jump to if one has a lull. Hence I haven’t used this application beyond trying it out.

Getting my iPad ready for FIRST robotics season

Last year, I started volunteering as a programming mentor to the Stuy Pulse FIRST robotics team.  Since kickoff was yesterday, I set up my iPad today for this season.  At least the beginning of it; I’m sure I’ll have more ideas as the season goes on.


The internet isn’t too reliable in a New York City high school.  There is (usually) wifi, but it doesn’t always work.  It’s also proxied through the Department of Education which doesn’t allow things like SVN or GIT connectivity.  Luckily one can at least view files through a browser.  There’s also way more team members than computers causing a lot of crowding around the screens.

What I set up

Use case Details Apps used Impressions so far
Skim game manual as soon as it is released and refer to it during discussions. Before kickoff, I downloaded the encrypted game manual and stored it in my dropbox for offline use DropBox

GoodReader ($2.99)


It worked.  GoodReader let me type in the password.  I was able to look up everything I wanted and a student on the team also referred to my iPad.  Also positive was the fact I had a cached copy, because usfirst.org promptly crashed right after the announcement of said password.


GoodReader doesn’t cache the password.  Even if you don’t close the app and your iPad locks, you get to type the password in again.  Which wouldn’t be so bad except the password was “5Time4For3Robots2to1Dance!”.  Nice and easy to type in on an iPad, right?

Be able to blog from the iPad There are some lulls when the programmers are waiting for use of the robot.  I want to be able to do other things during this time besides try to surf the net on a tiny BlackBerry. WordPress I’m very impressed  so far with the WordPress app.  I wouldn’t want to publish directly from the iPad because it is hard to type with 100% accuracy.  WordPress saves what you write as a draft accessible by both the iPad app and the regular internet.  This means I can patch up what I wrote in my browser before publishing.
Download the unencrypted game manual Entering the password repeatedly as been a royal pain.  I downloaded the unencrypted manual from a mirror (that grabbed it before the site went down). Dropbox

GoodReader ($2.99)

Very routine.  I deleted the encrypted file from my dropbox, added the unencrypted one and moved on.  The only snag was GoodReader still had the encrypted one open.  Closing GoodReader and reopening it, solved that.
View WPI Javadoc offline Unsurprisingly, we used the JavaDoc a lot last year.  It would be nice to reference it without competing for computer use with the person currently programming. DropBox

JDoc Reader ($3.99)

JDoc Reader was easy to set up.  I transfered a zip file with the JavaDocs via DropBox and chose “open in” JDoc Reader.  JDoc reader than imported it and provided a nice GUI for use.  I like that JDocReader lets you import any JavaDocs since these aren’t common ones. (Most JavaDoc readers I found were for specific docs.)  I didn’t download the JavaDocs for Java itself, but I will if we find we need it.
View WPI Python offline We are trying out Python as well this year.  The Python “API” is really just a large text file. DropBox

iUnArchive ($1.99)

Text Viewer (built in)

It’s awkward to open such a large text file.  Text viewer does it, but I’m still trying to get the hang of this.  (Will update this post when I learn how. For now it is a question)
View git This year we are using git instead of subversion.  (good idea since we can’t commit realtime) GitHub Viewer Lite Positive

The install was easy.  I entered my github username/password and it linked to my repositories and the like.


I was hoping I could save some files for offline viewing.  This doesn’t appear to be possible.  Not too important since team members will have checked out from home and have local copies of the repository on hand.

And of course, I have twitter etc already.  I actually had all of these installed except JDoc Reader.  I listed the ones with direct relevance to robotics.

I also probably need to add some manuals to DropBox.


Some of the students bring their own laptops so I expect the docs to be present.  This makes it easier for me to reference them.  And provides another copy for team members to use.

Note: followup posted