Team 846 2018 Code Base

Team 846 is proud to release their code for our 2018 robot, Wes!


  • The only robot in all of FRC to use the Scala programming language through the Potassium framework, which contains our core architecture and control algorithms as game-independent code
  • Ahead of time compilation of Scala code to native ARM32 binaries, powered by student contributions to the Scala Native project
  • Multi-cube pure-pursuit autonomous routines for all scale/switch assignments as well as robot starting positions, along with an adaptive trapezoidal motion controller for smoother path following
  • Transparent offloading of control algorithms to Talon SRX/Victor SPX across all subsystems, including layered controllers
  • Type-safe units of measure powered by the Squants library, with student contributions
  • High coverage unit and simulation-based integration tests for everything from gyro calibration to pure-pursuit path following
  • React.js based web dashboard for viewing streaming telemetry data from the robot

*]The entire history of our code base available publicly

It’s always been odd to me that you programmed in Scala. Were there any particular advantages that influenced the decision to use it?

The core reason was our functional-programming based architecture, for which Scala was a clear choice because of FP concepts being native to its language through features like the collections library. We don’t use any super theoretical functional programming concepts, but using functional transformations on streaming data is something we found works well for implementing our control algorithms as modular pieces.

Along with this comes many nice features for increasing modularity, like traits for multiple inheritance and a more advanced type system that enables APIs like simply calling


to get a stream of integrated values with the units of the integral automatically inferred. We really took this principle of modularity to heart with Potassium, with a self imposed rule the past two years to not include any control algorithms in our yearly code base but instead always contribute them to the reusable code base. This was especially helpful for 2018, since we started out with a lot of algorithms around drivetrain control ready to go.

Scala is also a language that has a lot of research, something that paid off this season with Scala Native. Using the JVM introduces quite a bit of overhead, especially with memory usage, so Scala by default comes with that as well. With Scala Native however, we were able to compile all our code AOT to binaries that booted a lot faster (up to 1 minute including auto preloading on JVM down to < 5 seconds) and used a lot less memory (60+ mb down to < 15mb). The best part of all this was it required almost no changes to both our 2018 code base and Potassium, since Scala Native comes with all the core Java APIs ready to go and has nice cross-platform build support (fun fact, you can also compile Potassium applications to JavaScript code!).