FRC971 Spartan Robotics 2016 Release Video

[thatprogrammer]

Originally Posted by AustinSchuh

We have our own framework for designing robot code. Our code is broken up into somewhere around 10 processes, each responsible for one part of the robot. 1 process is Autonomous mode, 1 process is the joystick code, 1 process is the hardware interface, 1 process is the drivetrain, 1 process is the shooter, 1 process is the vision udp listener, 1 process is the superstructure code, etc. Each of those processes communicate with our own PubSub message passing code. That means, for example, that the drivetrain will listen for Goal and Position messages, and publish Output and Status messages. (look in //frc971/control_loops/drivetrain:drivetrain.q for the actual definitions). This lets us be resilient to crashes, and keeps the interfaces between modules very well defined. For example, with 0 changes outside the hardware interface layer, we switched from running all our code on a BBB in 2014 to it all running on the roboRIO. We also are able to generate simulated Position messages and listen for simulated Output messages in our unit tests so that we can exercise the code without risking the real robot.

I'm curious about how this is being done. What file or class is used to actually join everything together and work as the "main" class that feeds all the others to the roboRIO itself? How are the WPILIB classes incorporated into this? Thanks!