Introducing a Learning and Prototyping Framework for FRC Software Development

For the past year, I have been volunteering as a mentor for a robotics team at a nearby high school. This team has focused on building robots for the FIRST Robotics Competition for several years. The competition runs every year from January to April. For the first six weeks, each participating team builds a robot, roughly the size of a dishwasher, to compete in a game against robots from other teams. The game changes every year and can range from fast-paced basketball-like matches to precision-intensive construction challenges.
   The latter game type was the one that I had the pleasure of working on with the team for the first time. For the six weeks of build time plus extra hours spent between our competitions, I helped the students and other mentors develop the electronics and software that made up the control system. Since this was a project targeted for high-school students, a lot of that involved taking pre-built modules provided by approved vendors and fitting them together into a system that allowed a pair of human operators to drive the robot.
   Though the process of constructing this control system was relatively easy to manage, my small control systems group and I struggled with a problem that I have encountered before in previous projects: a lack of prototyping and testing techniques. The control system is firmly centered around a large, clunky, expensive controller board called the roboRIO of which our team had only two: one for the robot and one for backup. Destruction or loss of either one of these boards would be a huge blow. In addition, the software utilities and development tool suite were limited to Windows, which in my opinion is a terrible platform for learning how to program. These are only a couple of the factors that I believe resulted in our group having to wait weeks until the robot's hardware was finished before the software could be properly tested. All through the build season I yearned to break free of this suffocating environment.
   After the robot was completed and the team returned from the competitions, I eventually found the time to ponder an alternative development system that would be suitable for prototyping robot code as well as teaching new students the basics of programming. I started with one basic requirement: that code written for the normal system should be able to run unchanged on the new system. That meant re-implementing the main control system C++ API, WPILib. An additional constraint that I adopted was that the robot's hardware should be relatively cheap and easy to modify and expand. After considering a number of educational robotic kits, I settled on the RedBot by SparkFun. The reasons for this choice include the platform's huge popularity, a plethora of plug-and-play sensors and actuators, Arduino compatibility, and affordability. The fact that it's design files have been open-sourced is another significant benefit.
   After nearly three months of sporadic work, I'm finally ready to present an initial status report. Most of the time has been spent on the new implementation of WPILib. It is currently developed only for Linux, though a Windows port is at the top of the to-do list. At this point, only a small fraction of WPILib's interfaces are available for use, including digital output and input and driving capabilities. A lot of work went into the underlying architecture that runs the user's program on a PC base-station while communicating with the robot via a minimal serial protocol. The robot itself runs a simple control loop written in the Arduino language that gets packets from the base-station, pokes the necessary hardware, and spits packets back. More technical details on this architecture as well as plans for future development will soon follow in another post.