Category Archives: programming

Introducing Strongback

Remember last April when we presented at the 2015 FIRST World Conference and talked about designing testable robot code? We mentioned possibly creating a new open source library with that code, and that got a lot of interest.

Well, over the summer we extracted the code from our team-specific codebase, restructured and documented it, and even added a bit of functionality. We still have to finish the website, but we have a web domain and discussion forums. We also have a name: Strongback.

Strongback is a new open source software library that makes your robot code lighter and stronger. You use it along with the WPILib library on your FIRST Robotics Competitionrobot’s RoboRIO, but Strongback’s APIs and functionality mean you need less code to do more. Plus, Strongback makes it easier for you to test your code without robot hardware and can record real-time data while you operate your robot for later post-processing.

Strongback offers the following features:

  • Testable – Test more of your robot code on development machines without requiring any real robot hardware.
  • Simple API – Uses powerful language features of Java 8 to reduce and simplify code while retaining flexibility.
  • Useful frameworks – Strongback offers several separate frameworks that you can mix and match in your robot code and in your tests. Use what you want, and nothing more. Set up all of them with just a few lines of code.
  • Uses WPILib – Uses the WPILib classes underneath for safety and consistency.

Check out our code, read our documentation, and if you’re interested then join us! We’re looking for students and mentors to try using Strongback, contribute code and documentation, help with the website, and even design robot hardware for physical tests.

Follow us on Twitter @Strongbacklib, on GitHub, or join our user and developer discussion forums.


Programming with style

Learning to read and speak English, French, Spanish, or any other language requires learning vocabulary, spelling, grammar rules, punctuation, idioms, and tools such as dictionaries and thesauri. Learning to write — and especially to write well — takes lots of practice, requires reading and dissecting lots of other writing samples, and involves a lifetime of learning and practicing various techniques, terms, and even styles. And each kind of writing has its own style and format: consider the difference between non-fiction, fiction, poetry, and technical reports (just to name a few). Many of these areas, especially those that are more formal, have standard styles and formats with rules that make it easier for readers to consume lots of documents. For example, the MLA Handbook documents in great detail the style and format rules for research papers, and its used in many secondary schools, colleges and universities.

Learning programming languages

In many ways, programming languages are very similar to written and spoken languages: they have their own grammar, terminology, vocabulary, punctuation, and idioms. Learning to read a programming language is much easier than learning to write, since writing code requires mastering many these skills. Learning to write code requires practice and dissecting of other people’s code. And, perhaps not surprisingly, each language has preferred styles and formats, and some even have style guides to help developers format their code in similar ways.

Why is style so important? When multiple people read or work on the same codebase, the formatting of the source code has a very big impact on how easy it is for people to read, understand, maintain, and express the intent of their logic. Code is already complicated enough, and using consistent formatting and style eliminates as much variation and unnecessary complexity as possible. Speaking from experience, it’s very easy to start working on a codebase when it looks like code you might write.

Java Style


Java has been for many years one of the most (if not the most) widely used programming languages. It’s also powerful enough that a lot of companies use Java as their primary programming language. But it is also relatively simple with a small number of straightforward concepts, making it a great language for students to start with. Many of our students’ high school programming classes use Java, and our team uses Java to program our robots (you can get a glimpse of our code by looking in our GitHub repositories). In fact, many FRC teams  and now FTC teams use Java to program their robots, too.

The Java Style Guidelines is the Java-equivalent of the non-fiction writer’s MLA Handbook. It outlines many rules for how to format your code, making it easier for multiple people to read, understand, and maintain. But the Java Style Guidelines were first written in 1999 (yikes!), and while it provides a good foundation, it hasn’t been updated and it hasn’t adapted to the best practices that Java developers have learned in the past 20 years. The de facto style standards used today by many Java projects no longer matches what’s described by the aging Java Style Guideline.

At long last the OpenJDK community has proposed updating the Java Style Guidelines to better reflect the conventions that most people are now using. And in true open source style, they’re looking for feedback from you (and everyone else).

Do you really have to learn all these rules? Well, yes and no. If you’re a Java programmer, then you really should learn to read and write code that follow these format and style rules: it will save you vast amounts of time when reading code written by others, which is something that you’ll do probably more than anything else. And, when you write code that follows the common conventions, and other developers will think your code more professional. But in truth, most Java development tools will automatically format the source code, so you just need to set up your tools to follow the project’s conventions. For example, FRC 4931 uses Eclipse, and our formatting preferences are already similar to these proposed guidelines.

So have a look at the OpenJDK’s proposal for an updated Java Style Guide. And if you don’t like one of the rules, give some feedback to the OpenJDK team.


Making progress on our testable robot code library

We are making progress on pulling out of our 2015 robot code the component framework, command framework, and data recorder system that we talked about in our Designing Testable Robot Code presentation at the 2015 FIRST World Championship Conference in St Louis last month.

Our goal is to get it into a minimal state as a self-contained library, and then open it up for contributions, improvements, and help. We’ve already settled on a name and purchased a domain name for the website, and we’re trying to get a simple site running.

Stay tuned! We’ll have more progress over the next few weeks.

Designing Testable Robot Code

Today at the 2015 FIRST World Championship Conference, Randall Hauch and Zach Anderson presented “Designing Testable Robot Code” (see slides below or the available PDF).

In the hour-long talk, they described how Team 4931 created new hardware abstractions to decouple the subsystem and command classes from the WPILib hardware classes. Traditionally, robot code directly use the WPILib hardware classes for the robot’s actuators and sensors, but doing this makes it very difficult to unit test the subsystems. Using the abstractions makes it possible to unit test the subsystems on developer machines without having any RoboRIO or physical hardware.

Testing on the robot with the RoboRIO and associated hardware is also important, and the team created a data recorder to capture in real time the discrete and continuous inputs, control outputs, and changing command states while the robot is being operated. The data log can be transferred off robot and passed into data processing and analytics (Team 4931 used Tableau), making it very easy to quickly visualize the behavior of the robot and control system outputs.

The team also proposed creating a reusable open source project where FRC teams can collaborate on this reusable library that sits on top of the standard WPILib for Java library. Team 4931 will refactor and clean up their current code and will donate it as a starting point for the project.  Almost a dozen teams expressed interest in participating, so stay tuned over the next month or two while we kick off this new project.

Thanks to everyone who attended! And best of luck to those competing at the 2015 World Championships in St. Louis!

Using Java to program the RoboRIO in 2015

Last year Team 4931 used Java to program the cRIO, and it worked great. All of our codebase is on GitHub, where the “CompetitionRobot” project is the program we used for competition. (There are several other projects, but most just show different styles of programming the robot.)

In 2014 we used Java 6 or 7, Eclipse Kepler, GitHub, Git, and Ant; see our instructions for setting up the tooling and the steps we used throughout development to branch, commit, and create/review/merge pull-requests to coordinate the changes to the code. Here’s a presentation that covers the concepts of Java development and how to use Git and GitHub:

We expect much of this to be similar for 2015, though we expect a number of changes:

  • Java 8 – Note that any code developed using Java language features introduced in Java 1.4 or later will not be deployable to a cRIO. We think the many(!) features in Java 8 are worth having RoboRIO-specific code, and we’re diving in headfirst.
  • Eclipse Luna with FRC plugins – Instructions should be released by FIRST on (or hopefully slightly before) kickoff.
  • Git – Be sure to use the latest version that fixes the security vulnerability announced on Dec 19.
  • GitHub – This is unchanged, though we’ll be using a different repository
  • Ant – We anticipate that the FRC plugins will still use Ant under the covers, so we install the latest and plan to augment the build file so we can run JUnit tests.
  • RoboRIO – There are a lot of changes here, nicely summarized by Team 2168. For example, it looks like we should be able to SSH and FTP into the RoboRIO to access files, install software, and more. The RoboRIO also includes a web server, which will be important to clear sticky faults and to adjust the CAN parameters. There’s also mDNS, which should make it easier to connect from development machines, since everything can use DHCP as normal. We’ll still probably use a few static IP addresses for specific devices, like onboard cameras.

For the most part, we’ll probably continue with everything we did last year, including using command-style code. We may use some Java 8 features in our code, but since the WPILib doesn’t really use any of these features (like lambdas, functional interfaces, collection streams, etc.) we’ll be limited to using them in our codebase. We’re definitely going to use collections and enums, though.

We do plan on making a lot of changes to make the whole codebase as testable as possible, especially off-robot. We also hope to build a real-time data collection system so we can monitor and record the performance metrics of the robot in real time.

We’ll provide an update when FIRST releases the instructions for the Eclipse plugins.