Programming goofs!

[Matt Krass]

Ok everyone, Week 1 is past, Week 2 is coming, and people are nervous about it. This is normal, and I think it might be fun, and helpful, if we started throwing out some great 'war stories' of silly programming mistakes we've made. I'm not talking about a misplaced semicolon, or forgetting to invert one motor, I mean the big stuff, the kind of stuff that you look back on and think "I can't believe I did that!"

I'll go first:

In 2003, I was a freshman in high school, programming the Stack Attack robot for 263 in PBASIC. It was the first year of autonomous, and with purely loop counters and some rough guesstimates on numbers our robot drove forward, turned in a wide 180 degree arc, and deployed two pistons on either side of the robot as 'wings'. Then it charged the ramp and tried to drag as many bins over to our side of the field as it could. One match I tweaked the turn so it would be a bit straighter.... I overdid it a bit. The robot whirled around so it was pointing at the ramp at a sharp angle instead of head-on. The pistons deployed, and the robot took off, and crushed the piston. I mean wrecked, it took a substantial amount of time just to dig it off the robot. At that point the team teased me relentlessly about it. Later on, we all signed the piston and it's been a staple of the robotics room at Sachem for years. I'll see if I can track down a photo of it later and add it to this thread.

Ok people, hit me with it, what silly mistakes have you made while wielding the keyboard?

[StevenB]

In 2005, I was a sophomore and the lead programmer for the rookie team 1519. On Thursday, I was testing some broken autonomous code, and suddenly we had to go play a practice match before I could revert back. All I knew is that the robot was going to drive straight for a long time, probably until a variable overflowed.

For whatever mechanical reasons, the robot didn't actually go straight. Instead it made a graceful arc, slipping through the narrow gap between the goals and careening at top speed into our opponents on the opposite corner of the field.

On Saturday, they picked us.

[davidthefat]

For the off season, I was making a 3d image generator from an IR range finder. I chose to use the cRio as the board to get the data from the ir range finder. That set up required 2 servos, so I tried to get the servos to work for a week. The code was correct, I was sure of it. Now it turns out that I had forgotten to put "jumpers" onto the board. Now that took a week for me to humble my self to ask some one. THAT was embarrassing.

Another blunder with that same project. Some reason unknown to me, code blocks was reading the data from the C drive. I was unaware of that until summer. I was supposed to read from the folder the executable was in, or the root of the project folder. So I could not get the data points from the cRio so it could not draw 3d imaged on the screen, but I had the drawing part down. So when it was time to present (I went after a fantastic game made by our team captain) I had nothing to present, but I learned something valuable from going up there: "I have not failed. I've just found 10,000 ways that won't work." Thomas A. Edison.
I had seen that quote before, but I truly experienced it in that class.

[Matt Krass]

Originally Posted by StevenB

In 2005, I was a sophomore and the lead programmer for the rookie team 1519. On Thursday, I was testing some broken autonomous code, and suddenly we had to go play a practice match before I could revert back. All I knew is that the robot was going to drive straight for a long time, probably until a variable overflowed.

For whatever mechanical reasons, the robot didn't actually go straight. Instead it made a graceful arc, slipping through the narrow gap between the goals and careening at top speed into our opponents on the opposite corner of the field.

On Saturday, they picked us.

We did something like that! I forgot until I read your post.

2003 (again, I was literally getting a crash course in robot programming, mostly by crashing the robot in to the course) and part of the game was that the Human Players could put a stack of bins down on the field pregame. Our autonomous took its turn waaaaaay too wide, and nailed one of the opposing alliances stacks, and demolished it. I got so many comments and questions how I made that so smooth.....

Yeah... complete fluke.

Matt

[Owen Meaker]

I am the lead programmer for our team since our rookie year last year. the automous was a simple go forward, stop, go backward, move to the side. The first time I got to test it was in the first practice match. I watch the countdown begin, then I see the robot move....backwards up the bump and hi center (our robot was meant to go underneath the tunnel, not over). I quickly go back to the pit to fix the code. after I have the fix, I'm informed that two of the wheels had been switched, which partly contributed to the problem. Content, i deploy the code, and watch the second practice match. the countdown begins and the robot moves...backwards, again, and hi-centers itself, again. I had made a change in the begin.vi, not considering that there might be a case where we ran autonomous twice before shutting down. Lucky this was all during the practice time, and a kind team helped get us down the second time to let us practice. Let's hope there is not another mistake this year.

[WizenedEE]

I'm interested.. How did you change begin so that it would work just once? It seems like you'd just add "true" constants to the inputs of robot drive.

As for me, I've never messed up anything too badly in programming, mostly because we loaded the code on the C RIO before ship date last year and my brother wouldn't let me touch it afterward.

This year, I spent a week trying to figure out why we were having communication errors before seeing that once of the loops in periodic tasks didn't have a wait on it.

[Bryan Herbst]

During Overdrive, one of the other programmers and I decided that Linux would be awesome on our laptop.

We decided to go ahead and dual boot Linux and Vista while we were at the regional. Set up the partitions, and everything went fine. Booted it up only to discover we had installed it to the wrong partition!

[Cecil]

The major goof i remember was back in 2009. We had a slider that would push out orbit balls from our hopper, and had limit switches to stop the motor at its outer limits. Right before one of the matches, i added an override button for the ramp-up PID we had implemented for our drive wheels, at the request of our driver. I found what i thought was the latest code on our laptop, made the simple switch, and loaded it in. For some reason, during our function check, our slider wouldnt work, but everything else would. It wasnt until mid-match that i looked back at the code and saw that the digital input had been called a second time, just sitting at the bottom of the code out of view. Nobody knows why it was there.. After a simple delete, everything worked fine. Still blame myself for losing that match.. Pretty much cost us that regional.

[DiscoKittyPrime]

I am the lead programmer this year and I still made a stupid mistake that ended up costing us our minibot deployment. We have a limit switch at the end of our deployment that is wired to be normally closed and that is to become open once it contacts the pole. The code seemed to work and the mentors approved it. When we went to test he code, the arm deployed and hit the pole... and kept on pushing. It ended up pushing our robot forward, away from the pole, until three of the pulleys ripped off the arm and the cord itself snapped. We went back to look at the code and realized that we had forgotten to use the .Get() function. Luckily it was a quick fix and we had it working again by the end of that day.

[linuxboy]

One big one I made a couple nights before ship involved a negative. We were testing the newly repaired arm and our code for keeping it steady and I figured that it would be okay to run it without picking it up so it could move in any direction. It turned out that the minute I started it it ran back against the hard stop and nearly pulled through the bolts holding in the gear box. That was an interesting night. On the plus side after removing that negative the code worked like a charm!

I know this said no inverted motor things but it nearly pulled the bolts through the steel!!

[goodsky]

I have vivid memories of autonomous mode in 2008. In overdrive the autonomous mode involved driving straight and then turning left (AND NOTHING ELSE!). Of course halfway through the Florida regional our robot decides it wants to be unique and starts turning right in autonomous mode (which I will point out, there was no function ever written in code to turn the robot right). At first I thought we had achieved robot sentience and that the robot was now programming itself, but then we discovered the broken encoder.

Another favorite is from this year. The first couple times we downloaded the code we kept getting an 'out of memory' exception. It had me scratching my head for a while until I discovered an exciting (and accidental) recursive function call written by one of the programming students. The code looked something like:

public void moveArm(double val) {

moveArm(val);

}

[Owen Meaker]

Originally Posted by WizenedEE

I'm interested.. How did you change begin so that it would work just once? It seems like you'd just add "true" constants to the inputs of robot drive.

The reason the problem was ocurring was that I had made inputs from the dashboard to toggle controls. I had written the autonomous to use no inversions, but the drivers wanted forward and backwards inverted. my first solution was to have a "use inversion" set to false in begin, then set to true on entering teleop. this had the problem of only working once per power-on, and I didn't consider running two matches before powering the robot off. my second fix was moving the variable from begin to autonomous, so it would work everytime.

[Kyoshirin]

This isn't so much a programming goof as a Labview goof.

This year, we made a new program every time we wanted to edit our program, and our programmer saved all the variations into a single folder. Near the end of build we were testing the compressor separate from everything else, so we made another program for that. We stop partway through working, save and leave.
The next day our programmer couldn't come, so I took over that part. I opened the non-compressor .vi and it only has compressor stuff. Being utterly confused, I try opening older .vi's and find that they are all the same. We had no clue what happened. Me and another guy on the team began working on a new program to attempt to get all functions back, without ever seeing the actual working program before.
After two days of making new code, we discovered the problem. By saving all the .vi's in one folder, they all had the same dependencies. Begin, teleop, and all the others were used by every new program we made, writing over the old code.
That day we learned to make a new folder for each program.

[mahumnut]

Last year, 2010, in breakaway, during the first match of the playoffs (quarters I think), I had to change the autonomous mode to not do anything which was as simple as putting a disable structure around everything. I built it and deployed. When the match started, to my horror, the robot started our actual autonomous code which was to ram forward into the goal and back up and ram again, but this time, we weren't aligned to the goal but rather our alliances control station wall. Our robot smashed the wall and knocked both ours and one of our alliance members control stations onto the floor (nothing was damaged). Turns out I forgot to save before build/deploying...face palm. For safe measure, our alliance members clipped their control stations to the shelves from then on. We went on to win the regional...

[Pii Wii]

In 2010 when programing the autonomous on a Mechnam drive. I told it to drive in the wrong axis. Causing the robot to instead of driving sideways and pushing a ball in. it instead drove the wrong axis and wound up ramming the wall on the other side of the field.
So our drive team being clever for the next match (This being the practice match we got 2) decided to flip the robot so that it would drive at the goal.
well the match bell rings and our robot goes screaming at the goal hits the slight bump in front of it an starts climbing the wall. The robot was at almost a 90 degree angle before our drive team hit the E-Stop.
Opps