Introducing Strongback, a Java library for FRC robots

[randallh]

I'm pleased to announce the first release of Strongback, a new open source Java library that makes your robot code lighter and stronger. You use it along with the WPILib library on your FIRST Robotics Competition robot's RoboRIO, but Strongback's APIs are easier to use and make it possible for you to test your much of your code without robot hardware. The latest release works with the most recent 2015 version of the WPILib library, though we'll release a new version for 2016 on kickoff day.

To help you get started, we've created an online book called "Using Strongback" that goes into detail about Strongback, its features, and how you can use it on your robot. All of the code is open source and available on our GitHub repository at http://strongback.org, so you can fork it and submit pull requests. If you want a quick introduction, view the slides from a recent overview presentation. We also have a discussion forum if you have questions or report problems, and follow us on Twitter @strongbacklib to receive the news.

The Strongback project originated with FRC4931, who presented their approach for designing testable robot code at the 2015 FIRST World Championships Conference. When lots of teams at the conference expressed interest in the concept, team 4931 extracted the library from their 2015 robot codebase and created Strongback.

Now the Strongback project is operated as a community-centric open source project. We hope that many teams want to use Strongback and contribute to our community by using the library, asking or answering questions, reporting problems, writing documentation, fixing bugs, discussing plans, and developing new features. Find out more here.

We hope you take a look and that Strongback helps you create more robust robot code!

[Cel Skeggs]

Nice job! This looks interesting.

How would you compare it to existing frameworks, such as Toast, the CCRE, and pyfrc?

[randallh]

Our emphasis with Strongback was on testability: make it easy for teams to write good, testable code and simple tests that can be automated and run frequently (on laptops) to catch regressions. The API uses lots of interfaces (many of them functional) that isolate your code from hardware-related WPILib classes, making it very easy to unit test your code using Strongback's mock implementations. The API doesn't get in the way, either: it let's you write robot code in much the same way as with WPILib, except that you use Strongback's hardware interfaces instead of many of the WPILib classes. And to keep things lightweight and minimal, we use a lot of lambdas and functional interfaces.

Additionally, since you can't unit test everything and its very difficult to realistically simulate real-world physics and sensor input values (especially in response to outputs), you still will need to test your code on the robot hardware. When you do this, you want as much insight as possible into what's going on in your code. This is where Strongback's data and event logging features come in: they provide a data acquisition system to record multiple channels of data every cycle of the code (e.g., 20ms by default) as well as spurious events like command state transitions. There is little overhead to this (Strongback uses memory mapped files to minimize latency), and these logs can then be converted into CSV files and imported into your favorite data analysis tool (we like Tableau) to understand and visualize the complete time history of activity.

Finally, Strongback is designed to be small and run all asynchronous operations on one thread and, along with the main thread, runs very well on the dual core RoboRIO. The asynchronous code was carefully designed to minimize thread context switches, resulting in quite reliable and consistent periods of execution. The makes control systems easier and more precise, since the actual delta-t is closer to the modeled delta-t of your control systems. (If your not careful, you can still overdo it by running more things asynchronously than can run in the configured period. In this case, Strongback logs warnings every time it falls behind; the fix is to run fewer things or to increase the delta-t.)

[virtuald]

It is good to see people focus more on software testing in FRC. It would be better for it to be built in... but alas.

[granjef3]

Wow.

Just finished reading the Using Strongback online book, and I think it's the best thing I've read this week.

This is amazing, absolutely amazing. This is the only library where I have read the entire documentation and never once been disappointed or confused. The design philosophy page seemed too good to be true... Lambdas?! Immutability?! Function Chaining?!

About the only thing that could have made me happier would have been an officially maintained snippet file for neosnippet in vim

Dealing with Java/eclipse for FRC coming from the simplicity I had with Node.js and React with vim has been pretty annoying, but this will significantly ease my pain.

I can tell this must have been a good amount of work for you guys, and your result is 100% beautiful. To everyone on 4931 involved with creating Strongback, good work!

PM or email me if you need any contributors from other teams, I'd be glad to help.

[randallh]

@granjef3: Thanks for reading and for the compliments. We've have been working hard on this for more than a year, so it's great to hear that you found it helpful. If you find anything that needs clarification, please file an issue on the GitHub repository.

Regarding Eclipse, Ant, and some of the other technologies, we wanted to stay aligned with what WPILib does as much as possible, even if we'd have chosen differently. We wanted Strongback to feel like a natural extension to WPILib.

We absolutely would love to have people join us and become contributors! In fact, we hope that is the case. This is an open source project, and we'll welcome everyone that wants to help. Having said that, our goal for this first release was to provide a basic but solid foundation of our original core ideas, so that a community can develop around it and take Strongback where the community wants to go. For example, there's lots of room for expansion, especially with vision, control systems, real time monitoring and analytics, and covering more hardware functionality (just to name a few). To those who have experience in these areas, please join us and share your knowledge.

We'd also love the community to define one or more "test platforms" (see this issue), which basically are published open source designs for physical hardware and test code that works with that design. The goal would be that multiple teams could independently build their own version of these test platforms so that, when Strongback is getting close to a release, multiple teams could independently run the verification tests on their hardware and submit their results. Essentially, it's a form of collaborative and distributed quality assurance for the library itself, helping us know that the Strongback releases will be solid for teams that use it.

Anyway, there's lots we (the whole Strongback community) can do, and it's yet another way that teams within the FIRST family can collaborate, work together, and show that everyone can benefit.

[otherguy]

I'm still working through the documentation and code, but wanted to say thanks for the effort you've put into this project. At least from what I've seen so far it's a well considered design that is very well documented.

I'm going to try using this project on some of our 2015 code to see how we could best utilize it in the coming season.

Thanks again for sharing.

[Joe Ross]

Originally Posted by randallh

The latest release works with the most recent 2015 version of the WPILib library, though we'll release a new version for 2016 on kickoff day.

Assuming the rules stay the same, you'll probably want to release a day earlier.

[randallh]

Originally Posted by Joe Ross

Assuming the rules stay the same, you'll probably want to release a day earlier.

First, look for a few patch/minor releases over the next few months. We want to be sure that all teams using Strongback can quickly get all the latest fixes. To that end, upgrading Strongback is very easy (just download the new distribution and extract over the top of your existing installation), and we are very careful to maintain backward compatibility of our APIs.

And to prepare for the 2016, Team 4931 (who founded Strongback) are participating in the 2016 WPILib Beta program so that, over the next few months, not only can we help test the WPILib software but we can also make sure Strongback is ready come kickoff. But even if we were to release Strongback early, we're not going to see the official 2016 WPILib software until everyone else does on kickoff day, and only then can we verify that the latest released version of Strongback works with it or, if there are problems, release another version.

[virtuald]

Originally Posted by Joe Ross

Assuming the rules stay the same, you'll probably want to release a day earlier.

The rules only state that the software has to be available in a public space before kickoff. Given that it is developed in a public repository, any commit could technically be considered a 'release'.

If they were developing this in a private repository, then yes, a release a day earlier would be required.

[randallh]

Originally Posted by Joe Ross

Assuming the rules stay the same, you'll probably want to release a day earlier.

I wanted to address this in particular. Rule R13 in 2015 was as follows:

R13. Software and mechanical/electrical designs created before Kickoff are only permitted if the source files (complete information sufficient to produce the design) are available publicly prior to Kickoff.

This only refers to software developed prior to Kickoff; it doesn't place any constraints on software developer after Kickoff. If something akin to this rule does appear in the 2016 game rules, then teams could use any past or future version of Strongback, since its source is and will remain freely available on GitHub (including all the files necessary to build the JAR files).

[Tparbotmail]

It's not entirely clear how to download this to a Windows laptop running eclipse in the getting started chapter. Are we supposed to us eclipse? Thank you.

[randallh]

Originally Posted by Tparbotmail

It's not entirely clear how to download this to a Windows laptop running eclipse in the getting started chapter. Are we supposed to us eclipse? Thank you.

My apologies. It absolutely does work on Windows, and I've updated the Getting Started section with instructions for downloading and installing on Windows.

[Tparbotmail]

Thank you Randallh I will look at this tonight. Do you know if there is a way to upload the Java code to the rRio using a Linux or OS X machine? I am really uncomfortable with the dependencies this program has on Windows.

[randallh]

Originally Posted by Tparbotmail

Thank you Randallh I will look at this tonight. Do you know if there is a way to upload the Java code to the rRio using a Linux or OS X machine?

Unfortunately, you do have to use a Windows machine and the NI software to update the roboRIO firmware and image the roboRIO. But once that is done, you can use Windows, OS X, or Linux to install the JRE and of course to deploy your robot code to the roboRIO.

To my knowledge, the WPILib plugin mechanism to deploy robot code just runs several Ant targets (e.g., `ant clean deploy`). When you add Strongback to your robot project, Strongback will change the project's `build.xml` file to override several Ant tasks, including `compile` and `deploy`, to be aware of and include Strongback (and other 3rd party libraries you add to `~/strongback/java/lib`). Strongback also adds several new Ant tasks, including `test` that compiles (if needed) and runs the project's JUnit tests. So deploy via the WPILib plugin should work, although our team prefers to run the unit tests, commit code to Git, and deploy using command line tools.

Originally Posted by Tparbotmail

I am really uncomfortable with the dependencies this program has on Windows.

Are you referring to the need to use Windows to set up and configure the roboRIO? If so, then I do agree that it'd be nice to be able to do all that on Windows, OS X, or Linux.

But I hope you're not referring to Strongback, because as I mentioned above it is just a Java library and you can develop and deploy your robot code using Windows, OS X, and/or Linux.

Best regards