Leading a Programming Team in FIRST Robotics

In my second year on the FIRST Robotics Challenge Team Rockford Robotics, I became the lead programmer. Each year FIRST Robotics creates a new game for teams to compete in. That year the game revolved around picking up balls and shooting them into your team's goal.

As the lead developer, I had to write software requirements, create designs, and assign tasks. I also was a communication bridge between the programming team and the mechanical. We had six weeks to design, build, and test the robot and code. Since this was my first time in a software leadership role, moving fast while efficiently was a challenge. There also was little time. Thus, it was not possible to complete all the features we wanted. Prioritizing became key. During competitions when bugs arose, time was even more limited. We would have anywhere from hours to even seconds to resolve a bug. There were also technical constraints. The robotics board we were required to use in the game had limited resources. Thus, the compute time for code had to be taken into consideration.

At the end of the season, we had successfully built the robot and written the required code.

The initial design was very clean and maintainable. We used abstraction to make everything from pulling input from the joystick to controlling mechanical subsystems.

I learned how to lead a team. I did this by writing clear requirements and plenty of communication. Asking others questions to understand the situation has always been my strategy, and this time was no different.

Previously I had used git for version control. This was the first time that the team would fully use git in the proper way. So, I learned about resolving merge conflicts, reverting commits, and all of the intermediate git features.

The project started with a clean codebase for most of the build season. When we started to implement a complex state machine and ran out of time, the code quality plunged. The code also was extremely unstable. In the off-season, we realized a state-machine of that complexity was unnecessary. This resulted in code that was more stable and clean.

The robot had to shoot balls into targets. We built a computer vision system that could track the target. The code was fully functional but not integrated into the robot. Due to time limitations and technical debt, this feature was never used.

If I were to go back, I would have prioritized the integration of computer vision. I also would have only accepted simple solutions as valid solutions. The complex state machine we built brought the whole code down. At the time, we thought we needed the code because it allowed us to hold multiple balls in the robot. However, a functional robot is better than one that is half-functioning.