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.
http://puu.sh/i50k9/bdb836e88d.png
**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.
Regards,
~Jaci
