Programming goofs!

[MaxMax161]

This year one of out auton modes was go straight, hang tube, back up, 180º turn. Sounds simple right? Well I forgot that there is a 50/50 chance that that 180º turn will slam your arm in to a minibot tower. Luckily due to a misplaced alliance partner we didn't hit the pole and smash our arm but boy was that code changed fast.

[Captain Slacker]

2008, at an offseason event, Team Paragon didn't have any programmers available to attend, so we chose a random code (we have a dial with a few different options for the drive team to choose on the field). When the match started, our robot went straight and we were all estatic that it was doing something that we thought would be productive. That is, until it kept going straight, knocking into the alliance station and knocking out all communication. That was a nice little delay....

[kaliken]

One of my favorites is a combination of programming and just plain old stupidity. And this one you can blame on the mentors!!!

In 2006 Aim High 294 was at the LA regional. We had programmed a second version of our autonomous to drive out make a turn aim and fire the balls into the goal. This was different than the one we did in AZ where we just angled it to the goal and fired.

We tuned it up to be working great on the practice field. We were nailing 5 out of 6 and we were ready to go...

We get onto the field and the students realize that the practice field was set up as a mirror image of the real field!!! unable to turn off the selected auto mode(switch wasn't ready) they angled the robot away in a funny angle so we wouldn't hit our teammates. What resulted was us firing 6 balls in rapid succession into the judges laps(err.. faces) who were oh so kindly sitting next to the field!!! Needless to say it took them by surprise but we ended up winning an innovation in controls award there! (not for the autonomous but for our HUD)

[simpsonboy77]

In 2008, I was the only programmer for team 41 RoboWarriors. Throughout the build season I was tinkering with the gyro so the robot could line up to knock the trackballs off better. Of course the best time to test these things are in practice matches on Archimedes.

The first time it didn't fail, but instead hindered the robot's ability to turn. After that match we removed the gyro, and I "thought" I recompiled and redownloaded the robot code. I didn't. The robot tried to read a sensor that was not there, and no matter what inputs I applied to it, it would not respond. The robot went full speed into our opponents drive station, knocking off 2 controllers, and damaging one joystick. At least this code was only operational during hybrid mode.

After that match I walked over to the opposing team and offered a joystick, and some velcro. I can't remember their team number, but if this was anyone's team let me know. I still feel bad about it, I took away one of their practice matches for my mistake.

[Businessman41]

We got to regionals and were ready to drive our robot. We discovered that the wires coming from the motor controllers were backwards, so we would have to drive in reverse(we only had a base, the rest was deemed illegal through incorrect materials.). We got the wiring fixed, only to discover that a right turn required moving the joystick to the left. I was confused because forward and backward worked normally. I fixed it by inverting the joystick input. It was not until after the competition that I discovered I put the signal wires into the wrong outputs from the sidecar.

[Egg 3141592654]

Well, I have one goof that was rooted in the programming, but was never actually my (the programmer's) fault. Our Autonomus code entailed the robot raising it's arm up to a set position and when it is done, the robot would move forward. The arm was controlled by a PID with pots for reference. I feared that the timed sequence which i kept the PID alive was too short, but I was assured that the times were appropriate. Sure enough, I was right.

1st match of the NYC regional that we were in, we watched the arm go up, keep going, snap all the pots, break the pins, and eventually flop over lifelessly. It was a sad time, but after a whole day of repairs, it was all happy again.

[Kiddmarshie]

Wow, thats a crazy mistake. I'm glad you shared that with us because now other groups won't make the same mistake that you did a few years ago. People are probably gonna thank you. However, that was a very silly mistake! Well, people learn from mistakes.

[LukeS]

In 2009 we never figured out the relationship between the code we wrote and what it did during autonomous. (LabVIEW)

In 2010 we had numerous cases where there was a one-line case statement, someone (Andrew, Jackson, me) would comment out the end, wipe out the "break;", and make it cascade through. (Java)

This year (Java) I've:
1) had a function that can be summarized as:
public double functionName(double in) {
double out = in
/* a lot of calculations altering out */
return in; // here lies the mistake
}
2) disabled the arm for writing autonomous driving on the practice bot, which lacked an arm by adding "if (true) return true;"* to the beginning of a method. Fine, until we got to competition and forgot to remove it.

BTW, when the announcer today said, "Looks like 1024's still having some programming problems.", we weren't; it was a hardware issue (an encoder wire had been mangled). (Not an excuse, still my problem, but it wasn't a programming mistake)

* the "if (true)" is necessary, because otherwise javac complains about unreachable code. I didn't want to comment it out, because then refactors of other things wouldn't change in it, and because that means 2 lines to edit.

[Jeremy Germita]

Most recent goof:
Our first match on Galileo this year, during autonomous, our robot turned to the left and attempted to score the ubertube on the tower. Turns out that during my rewrite of the driveStraight code, I accidentally did this:

void driveStraight(double angle)
double error = angle - gyro.getAngle();
double pidOut = /*do PID calculations*/;
tankDrive(angle, -angle);

I accidentally wrote the raw angle to the drive as opposed to the pidOut calculation.

Also a comment to myself consisted of this:

/*
  TODO:
  -Clean up comments, spacing
  -Test new operator controls
  -Other stuff
*/

That was after a late night of coding sans Coca Cola

So nothing too drastic, just some silly stuff that I should have noticed at the time I typed it!

[Kevin Wang]

Oh, my team had a terrible goof this year. Our autonomous is based off of distance data from four encoders, one on each wheel. Our robot uses mecanum wheels, so we needed to write our own method for calculating the distance traveled based on each of the individual wheels. We also run a PID loop on each of our wheels to control the RPM at which each wheel turns. We often had to switch between speed control mode using PID loops and pure voltage mode, so one of our programmers decided to modify the code to allow easy switching from speed control mode and voltage mode using a boolean. However this code was written between bag and tag day and our first regional (NYC regional), so the code was untested.

When we got to the NYC regional, we found that that code was bad, so we removed it hastily. We were being stupid and decided to revert the changes manually rather than just reverting automatically using our version control system. So we missed a couple lines. First, we forgot to remove the declaration of the boolean, but deleted its assignment to a value. So now we had an uninitialized variable in our code. But then it turned out that other critical methods checked that boolean (including the method that gets the distance the robot has traveled). Those conditionals should have been removed, but since we were at competition and were time-constrained, we left those in. So that function would check an uninitialized variable, and therefore always return zero as the distance. Which means that while we thought that the robot was driving a defined number of inches, it would always drive forward until our timeout time of 6 or so seconds.

In short, what we thought was distance-based auton turned out to be time-based auton. We started out telling the robot to drive 192 inches. This wasn't enough, so we lowered it a bit. And a bit more. However that number actually didn't do anything; the robot would always just drive for 6 seconds and stop. By the time we were down to 175 inches at the end of our second regional (Hartford), we knew that something was up. We found out that that method always returned zero. By checking the code history, we discovered that distance-based auton didn't work at all in NYC either. The ironic thing was that our dead-reckoning 6 seconds forward auton worked well enough in Hartford that we didn't even notice something was up until the end. After the regional we reviewed the code, and came to the terrible realization that such a stupid error in our code led to us having a time-based auton for both of our regionals, and that all that shouting of "lower it by 3 inches!" on the practice field didn't mean anything. We fixed it after the Hartford regional, and we then had one of the most stable autonomous routines at Championships (when other robots weren't driving into us and jamming us up, which happened like 3 times in a row).

[TofuRama]

One of my favorite goofs was in 2010. I was in charge of autonomous and was trying to get the robot to go forward and kick. During the build our soccer balls were to close, so when we got to competition our robot didn't go the distance it needed to (barely). To try to fix it I had it wait an additional two seconds before it kicked. The result was that it kicked the alliance station wall. No driver stations were damaged, but I could hear the result from the back of the stadium. I now increment values by very small amounts when needed.

[FRC4ME]

In 2008 (Overdrive), I was a programmer for 339. Our autonomous had been working well for most of the regional, often crossing four lines. But during this match, things were different; the robot ran full speed into the opposing alliance's wall and rammed into their driver station, knocking one team's controls off the shelf. The refs warned us to either fix our autonomous or disable next time.

When we got back to the pit we quickly discovered we had lost the entire 5 V bus on our IFI controller. This bus provided power to the encoders, without which we had no idea how far we had driven. Unable to fix the problem immediately, we flipped our "disable autonomous" switch on and prepared for the next match.

Literally about two seconds before the match started, we realized something: the disable autonomous switch also requires the 5 V bus. Oops. We watched helplessly as our robot slammed into the opposing wall yet again...a rather embarrassing moment.


In 2009 (Lunacy), we had just finished a match and I asked the driver, did you notice any problems with the robot? He replied, "the drive system was acting weird, and the shooter wouldn't pivot." I initially didn't think these two problems could be related, but a quick look at the code proved otherwise. I had left the drive system in tuning mode, which reused the pivot control to change one of the PID constants. Hence, the more the driver tried to use the pivoter, the more out-of-whack the drive system became.