Re: Programming goofs!
 

Here's a recently posted one:
http://www.chiefdelphi.com/forums/sh...threadid=93952

Re: Programming goofs!
 

I wish I could do that, but then we wouldn't have an autonomous. I'm not going into another "Why blame the programmers?" thread, but we don't ever get much time for autonomous, if any at all.

Re: Programming goofs!
 

Trying to run the gripper, and forgot to include "== 1" on C++: it don't work!

Motors run best when plugged into output #7 AND program set for #7 instead of #9.

Copying everything you think you might need for the Cypress unit straight from Chief Delphi.

Re: Programming goofs!
 

A major goof for us was my ego.

Re: Programming goofs!
 

My favorite was when our team almost... almost... became the first team to score autonomously at the Portland regional playing Rack'n'Roll. A bit of a malfunction in our ultrasonic rangefinders, combined with a bit of over confidence in our mecanum drive code... and if only we'd let go of the tube. It was match #2, in front of the entire stadium in Portland, on the first weekend of competition.

Start the match... burn three doughnuts, then score a tube right in front of all the judges. If only we'd let go, it would have been so, so sweet.

http://www.thebluealliance.com/match/2007or_qm2

Jason

Re: Programming goofs!
 

My biggest programming blunder so far has to be in 2010. I was adjusting some of the numbers in our autonomous program to make sure that the robot would reach all of the soccer balls. After I finished and had left, the rest of the team replaced the battery and ran the autonomous mode. The robot plowed through all of the soccer balls and drove over the bump and into the middle of the field. So, I learned that it can be pretty important to check your battery voltage even while testing! Luckily, none of this happened during any actual matches; I had time to fix all of my mistakes the next day.

Re: Programming goofs!
 

At Knoxville, when deploying, we would suddenly back away from the tower when on the field, but we were fine in the pit and on the cart. The motors were not moving, so we were bafffled. During Purdue, we originally had it so it would automatically drive forward when we deployed our minibot, since newtons law does not exclude us, but our driver decided that he wanted to drive himself, so we removed it. Or so we thought. While inspecting the issue late Friday, we watched the jaguars, drove forward into a pole, and hit the deploy button. The jaguars turned off while we deployed, the compressed bumpers expanded, pushing us backwards, then matched the joystick after we finished deploying. As it turns out, originally, we added a check, are we deploying? to our drive code. If we were, ignore the joystick. That code was never removed after we removed the drive code, so it was "DriveSafety-ing" and killing our motors. It cost us quite a bit, we were not able to deploy successfully during Knoxville and the end of Purdue.

Lesson: remove ALL code related to something :)

Re: Programming goofs!
 

The year before I was on the team (2008), 1569 had a pretty major blunder in atutonomous. With four mech wheels, with a cim on each, that robot really earned it's name of Mach 5. The programmers cut the power to half for teleop for the drive train, but forgot to do so in autonomous. It slammed full speed into the opposing alliance's wall, apparently knocking their control boards onto the ground! Luckily no real damage was done, and we learned to limit the code everywhere from then on.

Re: Programming goofs!
 

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.

Re: Programming goofs!
 

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:
I accidentally wrote the raw angle to the drive as opposed to the pidOut calculation. :P

Also a comment to myself consisted of this:
That was after a late night of coding sans Coca Cola :P

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

Re: Programming goofs!
 

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).

Re: Programming goofs!
 

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.

Re: Programming goofs!
 

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. :p

Re: Programming goofs!
 

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.

Re: Programming goofs!
 

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....