Stronghold - Day 1

The Krypton Cougars utilized a bold new strategy for this year's robotics competition, and arrived at the arena with a machine that was neither mechanically complete nor programmed. I wasn't in the arena the first evening and morning, with its flurry of activity, but I was kept in the loop via text message. The first problem brought to my attention was an old friend from previous seasons. Once our robot's radio was configured for use with the field, we could no longer connect to the robot from our laptops.

This doesn't seem to impact other teams. Perhaps they prepare their computer properly ahead of time, or maybe most teams just don't do much programming after their robot is configured to go on the field. It stood directly in the way of the Krypton Cougars's bold plan, however. In a stroke of brilliance, the team mounted a second radio on the robot, one for the field and another set up like we had at home. They stacked them, to make reading the signal lights as difficult as possible. Before each match, they would unplug one radio and plug in the other. After each match, they reversed the process. I'd like to say this arrangement didn't cause them any problems, but that would be very misleading.

Having solved their radio difficulties, they were free to complete their robot. While driving toward Philadelphia the morning of the competition, I received a text message informing me that the arm on the front of the robot could move up, but never down. After walking the programmers through common troubleshooting steps, I asked them to describe the blink pattern on the affected motor controller. They reported that when the arm wasn't moving it showed red lights, blinking in sequence: A limit switch was being triggered.

When the robot was designed, I hoped there would be limit switches at the top and bottom limits of the arms, both to avoid the arms moving beyond their expected range and to allow us to recalibrate the position periodically. The team had wired limit switches to the motor controllers, but attaching them to the robot had been left for some future date that never materialized. Instead, the limit switches were bundled up and dropped into the interior of the robot. The solder on one limit switch had been poorly applied, and the wires disconnected. Rather than fix the switch, the team tossed the loose wires in with the rest. Deep inside the belly of the robot, these wires had managed to cross, creating a short-circuit that was being read as a closed limit switch. Once these wires were separated, the arm moved downward with ease.

Kelly and I arrived at the high school shortly after noon. The parking lot was crowded, but we eventually found a space far from the school, where we unloaded our lifetime supply of baby gear and braved the bitter cold. Once Kelly and Miranda were safely in the arena, I headed for the pits.

By this time we had already had our first match, where our robot had put on a notable performance by spinning counterclockwise for the entire length of the match. While this had provided the spectators with much needed amusement, our team felt it was not a viable long-term strategy. There are many reasons why a robot might drive in a circle, but to continue doing so without input is rather unusual. We hypothesized it was caused by a sensor on the drive base not returning the correct speed. Rather than investigate the nature of the failure and correct it, we opted to turn off the sensors on the wheels and hope for the best.

This strategy was immediately successful. Without its sensors the robot drove in a straight line. Since the robot no longer knew its own speed, it went full force at all times, much like the students driving it. In fact, they were so excited by their new-found driving capabilities that they forgot the rules of the game and racked up twenty-five penalty points in their next match.

Up to this point in the competition, the robot's arms had been restrained with bungee cords until they could be tested. Spurred by their success, the team removed the bungee cords. During their next match, the shooter arm, now free of the bungee cords, ran into its own bumpers, ripping the shooter wheel sensor from its mount. The team decided they didn't really need a shooter wheel sensor anyway.

The next step was to fine-tune the motion of the arms. The pickup arm was too weak to lift the portcullis, so the programmers tried to increase its power. After a few changes, the robot stopped working entirely. The team frantically looked over the robot, testing every possibility. Network connectivity was good. The motors had power. The roboRIO was turned on. All the wires were still connected. Yet no commands were running on the robot. "What did you change?" asked a mentor in frustration.

"Nothing. Just numbers in the config file."

"How could that cause this?"

It couldn't, of course. The numbers only controlled the shooter system, yet all systems had stopped responding to controller input. Finally, after exhausting all other avenues, I asked the programmers to show me, rather than tell me, what they had changed, just in case, somehow, their configuration changes were responsible.

We worked through, line by line, until we came to a removed line:

#include "ControllerMap.h"

"Why did you remove that line," I asked in shock.

"We decided it didn't look right," they answered.

"Please put it back. It is what tells the program how to turn button presses and joystick movements into commands."

With the program back in working order, the team returned to the field to destroy more sensors. Within a few hours, all our sensors except the light sensor in the center of the robot were broken or disabled. Mechanical failures stacked up as the team drove with a reckless abandon better suited for the last match of the world championship instead of the first day of our first district competition.

Soon, though, the drive team reported a seemingly non-mechanical issue. "The arms aren't moving. We don't know why." The programmers pored over the code, but nothing seemed amiss. The drive base continued to work as normal, but the pickup and shooter system were unresponsive. When the programmers left to grab food, I picked up the driver station.

"Did no one notice that the second controller isn't showing up?" We tried unplugging it, plugging it into a different port, and even forcing a USB rescan, but the laptop continued to report that no second controller was present. The controller was dead. While a team mother rushed out to purchase a replacement controller, our team begged for a spare controller, and soon found a team willing to sacrifice a controller for the cause.

Reinvigorated, the team returned to the field. The robot, now nearly completely blind, was entirely dependent upon its drivers to keep it safe. The drivers, however, had other, more important considerations, and smashed the pickup arm into so many obstacles that it eventually broke free from the robot. Thrilled by their clever modification to the design, they decided they hadn't needed that either.