The Toast API

So I’ve noticed I haven’t really posted much about my ongoing development of the Toast API on ChiefDelphi as much as the /r/frc subreddit. Here are some of the exciting new features I’ve been working on.

An Introduction:
Toast is a modular-based robotics framework wrapping around WPILib. Toast is designed with the intention of making coding more accessible to FRC teams while still remaining a powerful tool for those that wish to get their hands dirty. Toast provides many tools ensuring the stability of your robot, and the modular workflow allows for teams to quickly and easily share their code and collaborate together.

**Gradle: **
Toast uses a flavour of the GradleRIO build system as opposed to eclipse plugins. The reasoning behind this is that the gradle build system is a lot more robust and can be used across many IDEs, including Eclipse and IntelliJ IDEA. Recently we added the Toasted flavour of GradleRIO which will automatically generate run configurations and environment specifications for each IDE to help teams get up and running with their module quickly.

**Simulation: **
Simulation now has support for the PDP and all PWM/DIO ports. Simulation will also automatically find classes belonging to modules in Development Environments. Simulation works by patching the HAL, meaning no external tools are required and the whole system works inside of the JVM.

**Modules: **
Toast works on the premise of Modules. Modules are collections of code (.jar files) that teams write and distribute their code in. These modules can be loaded by Toast and can work alongside other modules. This modular based system allows for teams to have an infinite arrangement of modules, perhaps one for Driving, one for Vision and one for Autonomous, or maybe a module for Debugging. It’s completely up to you. Modules are loaded reliably and can even have hard-dependencies (required dependencies), or soft-dependencies (optional dependencies)

**Crash and Logging: **
Debugging the code on the robot is something that has remained difficult for many teams. Toast fixes this. Toast comes with a full logging implementation built-in that will log the Time-stamp, logger name, thread name level and message. Logging and System.out/System.err streams are also written to file to be retrieved later.

Crash Handling is triggered when the Robot encounters an exception. The Crash Handler will nicely format the log as seen below, as well as safely shutdown the robot program. Modules can add CrashInfoProviders if they wish to add data to the crash log.

**USB Mass Storage: **
Toast has inbuilt support for USB Mass Storage (pen drives). Each USB drive contains a toast_autorun.conf file that specifies the behaviour of the USB device when plugged into the RoboRIO. The USB Drive can contain additional modules and run alongside the modules installed on the RoboRIO to allow for extended storage capacity. The USB Drive can contain modules that will override those on the RoboRIO, allowing it to act as a backup drive.

Data can also be dumped to/from the USB Drive, allowing for backups to be made or for easily loading data without having to SSH or SCP.

**Command Bus: **
Toast uses a custom implementation of a Command Bus. This command bus allows for users to type commands in the SSH prompt, remote console or even a webui to trigger commands on the robot. This is a way of humanly interacting with the robot. Commands can be used for anything, and modules can even register their own. A ‘script’ command is included by default to allow users to inject groovy code in the robot on-the-fly.

**Configurations: **
Configurations (also known as Groovy Preferences) are Toast’s way of handling configuration files. These configuration files are used by modules and will automatically generate. Users can edit these config files and the changes will be seen in the robot program. Additionally, code can also be run in these config files.

**Language Integration: **
Toast is written in Java, meaning it runs under the Java Virtual Machine (JVM). This allows for a variety of languages to be used all in conjunction with one-another. By default, Toast comes packaged with the Groovy SDK. This is used for Groovy Scripts, on-the-fly scripting and Configuration Files. Additionally, JVM languages such as Clojure, Scala and Kotlin can also be used if a module is written to handle them. All of these languages have full access to the JVM, including Toast’s and WPILib’s code.

Other languages are available, too. Ruby can be executed using the RubyOnWheels Module thanks to the JRuby project. LUA can be executed using the ToastLUA Module thanks to the LuaJ project. Ruby has full access to the JVM, too. These extra languages allow programmers to have a wide degree of freedom. Python and C++ are also planned in the future.

**Threading: **
Toast includes a ThreadPool implementation to avoid spamming the JVM with new thread creations/deletions. Modules can submit ‘workers’ to the ThreadPool to be executed when the pool is not busy.

Additionally, Toast also features the Heartbeat system. A Heartbeat system is a utility that Modules can submit listeners to. The Heartbeat will tick exactly once every 100ms. If a beat takes too long (longer than 100ms), the beat is skipped and each listener is notified of the amount of beat(s) skipped.

**Networking: **
Toast comes with the NetworkDelegate API. Since FMS only allows for TCP ports 5800-5810 to be open and forwarded, modules using networking might conflict for an open port. To solve this, NetworkDelegate exists to delegate the connections between ports 5805-5810. This protocol allows for modules to still have the raw Socket object, but will not conflict with each other.

**Final Notes: **
That concludes the outline for each of Toast’s new features.

For more information on Toast, you can see the Toast Whitepaper

Don’t forget to see the Toast Project on Github.

Nice job! This looks very useful - especially the module system.

How does this framework compare to other frameworks, such as pyfrc or the CCRE?

Hey there! Thanks for the interest c:

As for the comparison, between pyfrc and Toast is a pretty significant difference, namely language choice and runtime environment. The JVM exposes a lot of opportunities that aren’t just limited to Java, in fact a Python interpreter could be implemented in less than a few hours due to the Jython runtime environment, while still providing the hooks necessary for WPI and Toast’s inner workings without rewriting WPILib from scratch. This also has the added benefit of the features of Toast and any external modules also loaded.

As for CCRE, I can’t say I’ve seen it around before (I’m a rookie this year), but after glancing over the docs I’ll try my best to summarize. Toast is designed more as an addon rather than a framework, but has some necessary framework features that are necessary to have it work the way it does. I noticed CCRE’s implementation of the ‘Igneous’ system, which seems really awesome. With Toast, however, we package WPILib and most of the code for interacting with I/O is done through WPILib’s included calls. The philosophy behind this is to make programming as familiar and easy for new users so they ‘don’t have to learn another framework’. It also makes it easier for non-toast teams to help them out. Toast, at it’s core, is a module loader. We just so happen to include a bunch of other utilities that can be useful for people who want to use them. Most of these utilities ensure that modules are treated in a modular way, instead of the WPILib single-instance way. At heart, it’s a “Easy to get started with, while still remaining powerful for those who need it” framework.

If you want a less general statement, I’ll be glad to point you to the current version of the Toast Whitepaper. I hope I’ve been of some help, if you need anything I’d be happy to help :slight_smile: