[Cel Skeggs]

Originally Posted by Joe Ross

How do you deal with the non-backwards compatible changes in WPILib?

Simple: we don't expose WPILib. FRC robot projects written using the CCRE access hardware through the Igneous class. This lets us smooth over any changes in WPILib.

Since the user project isn't the first thing that runs, the CCRE_Igneous_cRIO or CCRE_Igneous_RoboRIO module can register their own versions of the interface, so on the cRIO the interface is designed to work with 2014 WPILibJ, and on the roboRIO, the interface is designed to work with 2015 WPILibJ. When the user uses the "Deploy" target, it uses the roboRIO build system to download it (assuming that they have the required plugins), and when the user uses the "Deploy2014" target, it uses a heavily-modified version of the cRIO build system to download it, no plugins required.

In terms of the non-backwards-compatible hardware changes, we provide Igneous.isRoboRIO(), which lets the user program figure out which one is being used. Since a robot with the roboRIO and a robot with the cRIO would have different port numbers either way, we require that the user program chooses the correct port numbers itself. New modules such as the PCM are handled via methods such as Igneous.usePCMCompressor(), which will throw a helpful exception if used in a cRIO environment.

We've used this to make last year's code downloadable to both targets, and when our code ran on a cRIO at Girls' Generation and Rookie Rumble (offseason events), it used the exact same code that I've been downloading to a roboRIO for testing.