Code Release

##Pre-ramble So last year, we didn't do a code release. This was for a couple reasons, but mostly revolved around the fact that my code was relatively sloppy and buggy, and generally didn't work. Motion profiling was still a work in progress at that point, and actually never worked within the competition season. I quietly moved our repo to public and continued working on it.

I'm proud to say that things have changed this year. Team 236 has made massive strides forward in every area, with improved scouting data analysis, design, wiring, and manufacturing than 2016, which has made this season a huge success. However, I'm going to try to stay on topic. Our code this year is far more organized and streamlined, which has allowed us to implement successful and accurate motion profiling along with some other steps forward. A key element in this process has been a more sophisticated git workflow, including feature branches and higher standards for commit organization. All this has been preserved in the final repo, so you can see the evolution of the code throughout the season.

##TICKTANK The crowning achievement of this year, however, has been the implementation and successful application of the TickTank module. TickTank is designed to be an extensible and modular tank drive, with a host of features included. I came to the realization last year that the drive subsystem had become essentially boilerplate code, and I had the idea that it could be logically unified into a module which would would handle all the drive code without needing to be modified for each robot. This idea became the TickTank module, which now contains a variety of useful commands.

Instead of needing to write a new implementation of the same old drive subsystem again, you simply create a Settings object, load it up with information about your tank drive configuration, and pass it into a TickTank object. Because TickTank extends Subsystem, you can treat it just like a standard drive subsystem and run the available commands on it (or write your own). Because the motion profiling code is included in TickTank, you can run motion profiles on your tank drive with minimal hassle. If you're interested, I recommend looking through the Robot class to see how the tank drive and motion profiling are handled there.

I'm really proud of the work we've done on TickTank and I would be honored to see it on your robot, especially with the progress that is coming up. You can see the TickTank code here.

##AUTO HANDLING Last year we had a persistent problem with the SmartDashboard. Too many times, it was not connected to the robot before the match and could not send or receive data. At the time, we used a SendableChooser on the SmartDashboard to select auto modes, so if the SD was not connected, the auto mode didn't run. Although we've mostly worked out our SmartDashboard issues at this point, we learned that we needed a better solution. The solution we found was 3 mechanical switches mounted to the side of the robot connected to DIO ports. The positions of the switches are parsed to a binary string, which is converted to a base-10 number to pick one of 8 different auto modes. I am proud to say that we did not have any issues with this setup all season. The code for this feature is in the lib.AutoHandler class, and the switches are polled in autonomousInit(). In the spirit of polymorphism, the AutoHandler class is designed for any number of switches on any selection of DIO ports, which should make it easy to use this on your robot if you so choose.