[FRC4ME]

Oh, we've had some good ones this year...

At DC, we went through an entire qualifying match nearly unable to drive because I misplaced a decimal point ("but I'm only slightly changing one number; it can't possibly fail!").

There was once at the end of a long night when we couldn't figure out why this line of code failed:

if (0 > DBL_MIN)

That should have said -DBL_MAX - i.e the largest representable negative double precision floating point number; DBL_MIN is the smallest representable positive number. The funny thing is, when debugging the statement, we noted the value of DBL_MIN to be something like 2.17e-300. Our programming mentor (a senior programmer at CSC) and I must have stared at that number for fifteen minutes thinking "yep: that's negative". The number is obviously positive; just very small, but we could not see that. We came to the conclusion that the compiler had a bug in it (yeah, right) before realizing our mistake.

Our robot has a "tuning mode" that allows us to adjust traction control constants on the fly. This mode uses the double-throw momentary switch that normally rotates the turret to adjust one of the constants.

After a practice match at Chesapeake, our drivers complained that A) the turret didn't work and B) the drive system was acting very strange. At first we suspected battery problems, but then I realized I had left the robot in tuning mode: every time the second operator attempted to rotate the turret, he was actually changing the P constant for the traction control loop. No wonder it seemed inconsistent.

During Chesapeake, we had been setting the traction control to maintain a slip ratio of zero. After a qualifying match, one driver commented that the robot seemed to work much better going backwards than forwards. I looked in the code and realized that I had a sign wrong; when going backwards, the traction control was actually speeding up the wheels, not slowing them down. We quickly realized that a certain amount of slipping was much better than no slipping at all. To date this is the only helpful bug I have ever seen.

I once tried to download code three times before finally realizing the robot was turned off, the driver station was off, and the tether wasn't plugged in.

At the beginning of build season, we put two acetal wheels on our 2007 bot to simulate the rover wheels. This made the robot imbalanced and caused it to rock back and forth when (de)accelerating. We then tried to do a PID drive using velocity integrated from an accelerometer. The accelerometer was mounted such that the rocking motion of the robot caused it to rotate perpendicular to the axis of measurement, therefore horribly skewing the velocity measurement. This was quite funny to watch as the PID loop caused the robot to drive back and forth repeatedly, tilting the accelerometer just enough to make it stop and go back the other direction each time.