The Krypton Cougars are back in action. After their banner performance last year, the students were eager to learn from their mistakes and made an exhaustive list of everything they wanted to do better, presumably so they could pointedly ignore it.
Last year the battery was very hard to replace, causing much frustration during and after the competition season. One student ended up becoming the designated battery installation expert, and that could only be done in a timely manner if the robot was held up in the air. For 2017, the team decided that wasn't nearly difficult enough, and buried the battery even deeper in the depths of the robot. It now requires two or three students to replace a battery, after moving multiple robot mechanisms out of the way.
Last year the team divided their focus between too many things, and vowed this season they would streamline aggressively. When the game was revealed, the first meeting was to discuss what game elements the team would target and which they would ignore. The team decided that the fractional point value of fuel made it unnecessary, and that the forty-point gears and fifty-point climbing were much more important. They then spent half of build season designing a hopper and loader for fuel. Which leads us to the next improvement...
Last year the robot was not mechanically completed until the last moment. The programmers were forced to program on the car ride to the competition. We agreed that this year we'd finish all mechanical changes at least a week before the end of build season, giving our programmers and drivers the time they needed. Naturally, the mechanical team decided that prototyping the fuel hopper system took priority over programming and driver practice, leaving the programmers to test their changes in the gaps. An additional motor was added to the robot, for the hopper, the night the team arrived at the competition, which the programmers did not find out about until the night before. It was programmed at the competition. The drivers got no practice time.
With this auspicious start, our team could not help but have a great first competition. One thing you must do at an FRC competition, after getting your robot unpacked, is have the robot's on-board radio re-imaged for the field. Until this is complete, and your robot is inspected, you can't do much. There were already a few teams in line before us, and they seemed to be having trouble.
"Did you update your firmware?" the technical assistant would ask.
"Yes," they replied confidently. Then they'd plug in their radio, enter their team number, and then watch as a large error dialog appeared. Three teams in a row did this, so when it was our turn I was a bit worried.
"Did you update your firmware?" The last update we'd done had been the last week of build season. I hadn't seen a notice of any new changes, but how could all of these other teams not have updated their radios in three weeks?
We plugged in our radio, entered our team number, and hit the "Configure" button. A progress bar appeared on the screen. A few seconds later our radio was successfully imaged. We took it back to the pits and plugged it into the robot.
I suppose at this point I should mention that this is the first year our team has used a co-processor for vision. It's a second computer with 192 GPU cores, and it can process two different camera feeds for different targets and stream video feeds and target information back over the network to our drivers. It's one of the programming team's several amazing achievements this season. We rely on this vision information to drive our robot, both autonomously and when we need extra precision under human control. After the radio was re-imaged, this vital co-processor disappeared from the network.
By that time it was getting late in the evening, and Miranda had only had a short nap on the ride out, so I had to leave so we could put her to bed. Back at the hotel, I provided tech support via text message. The core problem was somewhat obvious. With …