Programming goofs!
 

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?

Re: Programming goofs!
 

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.

Re: Programming goofs!
 

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.

Re: Programming goofs!
 

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

Re: Programming goofs!
 

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.

Re: Programming goofs!
 

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.

Re: Programming goofs!
 

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!

Re: Programming goofs!
 

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.

Re: Programming goofs!
 

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.

Re: Programming goofs!
 

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

Re: Programming goofs!
 

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

}

Re: Programming goofs!
 

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.

Re: Programming goofs!
 

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. :eek: 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. :confused:
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. :D

Re: Programming goofs!
 

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

Re: Programming goofs!
 

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

Re: Programming goofs!
 

Alright, so this year (2011 Build Season), as lead programmer of Team 263, we were working on our robot's arm. We had a ridiculously large gear ratio, and the arm generated a lot of torque. Our adviser said to put in a limit switch, that way we can program it to stop before it overdid itself pushing downwards. I said to him, "naah no need it will be fine...". Lesson learned, basically, I didn't realize that our arm was still trying to go down, on the last few days before the end of build season, and because I hadn't noticed, the arm bent a heavy steel rod, which completely dumbfounded some of the mechanical members of the team, how the arm managed to do that. Not only did the mistake stop there, the captain then tried to pry the sprocket off the bent side of the steel rod to salvage it, in turn bending the metal sprocket, and again in turn our other mechy team member, helping the captain, stood on the frame above the wheel, causing the axle to come loose. So my mistake essentially bent a steel rod, bent a metal sprocket, and make a wheel axle come loose, all on the last 2 days of build season. :) :cool:

Re: Programming goofs!
 

Not so much programming, more of a "D'oh!"

This year at NJ we brought the robot back to the pit after a match and had to put it on its side to fix some chain problems. They got it worked out and asked me to start it up and test it. We had tank drive set up. So I run the code and push the right joystick, and the right side works. Then a push the left annnnndddd....nothing happens

About a half hour later, after pulling out jaguars, switching out pwms and ports on the sidecars, checking code, rechecking, and making new code, I found an unplugged usb cord. It was the joystick.

Re: Programming goofs!
 

When testing code mount the robot on stands. We were testing autonomous or something and then we enabled. The robot flew off the cart onto the ground bending mini bot deployment on the last couple days before ship date.

One of our programming traditions is summing up our meetings in the form of limericks.

So you know the watchdog? Well on team 578 last year we had problems with it so many times so we decided to rename the watch dog and called it now the watch kitty. Long story well this year we named the watch dog watch whale whale watch.

Re: Programming goofs!
 

I don't know if anyone remembers this, but it did make YouTube temporarily.

Last year, at FLR, went ahead and tried vision code for the first time. It seemed to work at home, so we bundled it up and sent it. I guess we were wrong - in our first practice match, we ended up spinning in rapid ccw circles. I still don't know the cause - I didn't have time to debug it at comp, due to other huge issues - Like the radio not working half the time (!). Caused a mechanical failure, I suppose, too - our left(?) drive chain came off.

Re: Programming goofs!
 

Here's a story I heard from one of our mentors from 2002(??? whichever one had lunacy-style moveable goals):

We had this goal grabber-thing that twisted 90 degrees after being placed on one of the posts of the goal. Really cool, we managed to pull the entire opposing alliance around while they were all holding onto this same goal :D. But anyways, the grabber itself was powered by a motor and had limit switches to hold it at the ends. Well one day the programmer decides it would be a great idea to do some debugging by removing the limit switch code. The robot enables, and the thing spins out of control, catches on some of the electrical wires, and manages to tear up most of our electronics board!

Another story: Last year during elims at FLR, the head programmer decides to take one last shot at autonomous. He builds it, tests it on the cart tethered, and sends it out for a match, where the robot just sits there. Seeing that (again) it didn't work, he goes and removes autonomous from the code and redeploys. We go out for our next match, only to find that the robot successfully scores in autonomous!

And now for this year's autonomous mode: I had 5 minutes on the practice field at FLR to write autonomous before elims started. I'm sitting there, programming frantically, when I finish a download and go run autonomous. Well, the robot runs normally for about 1 second, after which it runs backwards in high gear at max speed! I practically kill the e-stop button, and the robot stops about 1 foot away from a rookie programmer! Turns out I forgot to tell the drive controller that it needed to send an update to the jaguars :(

Re: Programming goofs!
 

In 2008 at Lone Star, our robot was supposed to make 3/4 of a lap, but instead our power kept shorted out and it restarted the program an we slammed the wall at full speed went up on three wheels (of 6) and turned around, went full speed back and nailed our team mate who didn't have a autonomous mode. Our robot was unharmed and hitting the wall the second time it fixed the short. We one the Motorola Quality award and the judges told us that was why, because other robots would of broke down after that kind of hit.

Re: Programming goofs!
 

For the 2005 game, Triple Play, we had six reliable autonomous paths that would pick up a vision tetra from the appropriate spot and place it on the center goal for a double bonus. We had a camera that would reliably find vision tetras. We just didn't have a working bit of code to connect the two. So we defaulted to the path that picked up a tetra from front center and placed it. It always worked, if that's where the tetra happened to be. I figure it was only going to take a couple of hours of programming on Thursday at the regional to get the camera to choose the path.

At the same time, the white KOP joystick we used for our operator that year proved to be noisy and unrepeatable enough that we decided to replace it. The high-quality arcade-style joystick we purchased was installed in our driver station, and we discovered that its output was only about half of the possible range. That would have made our arm move much too slowly for effective game play, so the first thing I did to the code when we got to the regional was to multiply the motor control value by two before sending it to the PWM output routine. The joystick worked great, and everyone was happy.

Our first practice match came up. The vision tetra was randomly placed in exactly the place our autonomous was going to try to pick it up. The team was ready to awe the venue with our fantastic autonomous performance. When the match began, our robot raised and extended its arm, drove to the tetra, picked it up...and proceeded to throw it into the air and thrash the arm wildly up and down, making the whole robot bounce. The drive team hit the emergency stop.

I immediately realized that the arm PID had been totally thrown out of whack by the extra doubling at the end. I spent the next half hour trying to retune it to account for the change in system gain, without success, then figured out that I could put everything back the way it was before and just double the joystick value on the way in instead of doubling the motor value on the way out.

I am not sure what exactly happened at that point. I probably restored the code from the wrong backup, because the autonomous code totally failed and never worked again. After most of the day without success, the team leader eventually decided we needed something quick that worked, so our great tetra-placing scripts were discarded and our robot spent the rest of the season bumping the hanging tetras off the corner goals for a one point score in autonomous.

Re: Programming goofs!
 

Once in 2010 Breakaway competition, our autonomous code "shorted out" and our robot ran at full speed at a graceful curve and slammed into another robot, flipping it over.

The other team forgave us...

Re: Programming goofs!
 

My code from 2010 calgames made up for that sort of, that was a seriously sweet drift around the robots that all piled up in the middle of the field. Concerning that year, I did *cough cough* say just keep the robot turned around and it won't end up toppling another robot. In my defense, the code was right, I was just using the wrong workspace, and I'm glad Pally (I didn't actually see it happen, I was in the pit, so excuse me if I'm wrong) was forgiving about it. The best autonomous code ended up being us sitting there running the compressor. But really, you should know by now that when I say the code works, I'm wrong, but when I say I'm right about something, robot code included, I'm right.
Basically, it's a thin line between admitting you're wrong and making an argument of why your right so poorly put together it can't be taken apart any more, making it just about as good as a solid one.
On an somewhat unrelated note, I do remember something in '08 where we knocked down all 3 of the opposing alliances driver stations in possibly 2 consecutive matches during autonomous. All I can say is that, while they were quite professional about it, they weren't horribly pleased my our sudden movement of the entire field.

Re: Programming goofs!
 

This year, at our first regional, my biggest mistake was. It wasnt even my fault but what happened is that me (lead and only programmer) and the only other person on the team who knows what 'program' is, were sitting in the pits writing autonomous code. After our last match of the day, I assumed the kid would be alright, seeing as how he might occasionaly be an airhead, he can wield anything (be it hammer, keyboard, crimper, you name it) and instantly look like hes meant for it. looking over the code that night in the hotel, I cleaned up much of the teleop code we had (under the drivers specifications), and didnt think about looking at the auton. the next day, in our first match, i looked at the program while waiting in line for our robot to be set up on the field and notice he had a very buggy piece of autonomous in the default case. asking him about it right there (me and him are the drivers), he said he couldnt get it to download, so i wasnt worried. After we set up the robot and were waiting in the drivers area, waiting for the countdown ("red alliance, ready? blue alliance, ready? GO!). All of a sudden our bot (on a far side) just zooms out of its starting position in a nice arc all the way across our half of the field and makes it to the robot across from us (which also had autonomous, but worked) and cuts it right off, slamming into our side and messing both our autonomous up. after the switch to teleop, our robot was just stuck spinning in circles in and out of the lane, continually getting lane violations. all because a bug went achoo, and changed a variable that diverted the initial autonomous switch case.

Re: Programming goofs!
 

I'm gonna beat RyanN to it, but he can explain this video.

Re: Programming goofs!
 

When writing autonomous, don't forget about environmental factors. You are not the only robot on the field, and you must account for that. In this case, I was looking for the walls... When another robot took off and got in front of us, the robot took evasive actions and went in the wrong lane and collided with every other robot on the field.

Also, a 1-to-5 pushing match was fun.

Our robot took 0 damage that match.

Re: Programming goofs!
 

Instantiated the analog autonomous mode selector object in the wrong channel, so the cRIO could never read an autonomous mode besides 0 which is make the robot sit still. Oops.

Re: Programming goofs!
 

When i was tweaking the programed positions on our teams arm I accidently wrote to the the arm motors twice over at the same time causing the arm to go crazy and lock its self in place. they tried to move it again by pressing the button and caused the wrist motor to internally lock, and broke one of the sprockets on the arm, it cracked in half, at the same time. this all happened 5 minutes before we went out on field for our first match.

Re: Programming goofs!
 

I first tested our new autonomous on the competition field at our regional last year. I forgot that a positive voltage setting to the wheels means the robot goes backwards. I don't think I'll ever see a robot again accelerate full speed backwards over a bump, catch airtime, and land on the ground, back-wheels first. Oh, and then we proceeded to turn the wrong because of the erroneous values, cross the median, and get 11 penalties and a red card by the end of autonomous. Woohoo.

Re: Programming goofs!
 

Another one of those "d'oh" moments instead of a "goof":
This season we used the line sensors for autonomous. During the build season - our mock practice field required us to have the robot move some extra distance after stopping at the "T"/cross made by the tape to effectively and consistently score. When we got to competition, it seemed that the robot was too far from the wall, so we simply added to the amount of feet to try to get it to work. When we finally got time to go to the practice field, however, we realized that the robot was actually bouncing off of the plate at the bottom of the scoring pegs and being pushed too far back. We didn't figure this out till right before eliminations - and we did not have any successful autonomous runs in qualifiers or practice. But once we took out a simple "feed power to the motors for 500 milliseconds" in the code, our autonomous worked every single time.

Re: Programming goofs!
 

I guess I have a couple of moments to share. Both were pure awesome, both were goofs, and both differ in the amount of awesome of failure/win that ensued afterwords.

I'm sure I've mentioned this before, but for Breakaway, I attempted to urge our programming to just program a go forward autonomous code. This way, we could at least score in the near zone. The programmer did just that, and we ran out onto the field with untested code. The match starts, and the robot proceeds to drive backwards over both bumps and we manage to rip the bumpers off one of our alliance partners. The amount of failure was amazing.

Another goof was more recent, we had this bug in the autonomous where sometimes, our lift does not initialize (Our lift leans back, and we use two pneumatic cylinders to lift it straight up). In one such match, this just so happened to be one of the few before eliminations, this our cylinders didn't fire. The drive team and I watched as our chances of seeding high went through the floor because the tower pistons failed to fire. But to our surprise, the tower pistons fired at the beginning of teleop. It wasn't until later that I found out that one of our programmers had gone in and programmed a safety at the beginning of teleop. I was so proud of that programmer for being one step ahead. I equate that to giving Murphy's Law the finger.

Anyways, just a couple of goofs that have a space in my memory.

- Sunny

Re: Programming goofs!
 

While it could be a mechanical or a programming goof, it was about 4 weeks into the build season when we were testing our arm. As a safety precaution we had put limit switches on the robot to make sure nothing went wrong. Everything was going great till one day the arm started not stopping at the limit switches, luckily i was manually controlling the arm or it would have been bad. As it turned out one of our mentors switched out a limit switch for some reason. After testing about 5 or 6 different limit switches and spending quite a bit of time rewriting our code i turned to the mentor and asked if the switch was normally open or normally closed. As it turns out when they switched them out they switched to normally open. So it was about 2 hours of troubleshooting to find the little thing that was killing us.

Re: Programming goofs!
 

after we fried almost all of our electronics on thursday at the k.c. regional. we did not check the line sensors, come to find our they were bad, which caused autonomous to go to an "impossible situation" that stopped the wheels. we ran a few matches before realizing this... then when we found that to be the problem, we took them off to get the new ones re-wired. so my un-calibrated gyro code seemed like the quickest way that might yield some results in points... in autonomous the robot drove in an elegant arc with our arm in the high position, pushing both alliance partners to the side (who fortunately couldn't hang anyways, just drive forwards) with our arm hanging over them. the whole time the "drivetrain" driver was excusing our robot and code to the other teams. we still won the match thankfully. we got the sensors back on before our next match, and our code was 100% all the way through finals. the way hanging code was written literally threw the tube onto the rack. it was so nerve racking that it was not requested, but ordered to drive further to make it less stressful. i finally saw video of it after the change and it still was pretty intense.

our biggest goof for the programming team in general was hooking up the battery cables backwards when rewiring the robot after finding the cause of the ground to the frame. we fried all our jaguars, a side-car, a c-rio card, and maybe a power distribution.

Re: Programming goofs!
 

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.

Re: Programming goofs!
 

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.

Re: Programming goofs!
 

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.

Re: Programming goofs!
 

This year, during an autonomous code test for the line trackers, the robot was following the line as it was supposed to. However, once it got to the split in the duct tape, it sat there, seemingly thinking. then it drove forward, full force, smacking my friend in the back of the legs and ramming both him and itself into a table
Turns out instead of doing
i did

Re: Programming goofs!
 

This year, my autonomous code was very buggy. In the first match of the day, we were up, and I got to test my code for the first time. Turns out I had inverted the the Y axis, and the robot crosses the center line and gets a penalty. While that was a simple fix, the code was unreliable the rest of the competition. It is supposed to drive foward while lifting the arm, then move the arm down, release the tube, move the lift down, and back up. However, sometimes the lift would never rise, sometimes it would go up and down before the robot had finished moving forward, and sometimes it would only lift after it had released the tube. We managed to score once on both the bottom and middle pegs, and never had it go to the top pegs like it was supposed too. I ended up removing the code for quarterfinals, as the risk of damaging the claw or getting a penalty was too high.

Re: Programming goofs!
 

Just this past weekend at the GVSU Regional, I was programming our autonomous, with each round as a trial. Unfortunately, I had missed the first round of my trial because I was helping another team with their driver station. Everyone told me that it basically didn't move, the arm went up and very slow. What they left out was that it went backwards. So, being the troubleshooter I tend to be, I just upped the speed and duration.

Unfortunately, that sent our robot all the way across the field, giving us a penalty. I don't have any video for you, but if you were there, it stood out quite well... I felt horrible. But, in the end, our auton got us a place on the first seed alliance! Thanks 67 and 2054!

Re: Programming goofs!
 

Well at the Florida Regional this year....(2011) Well, we never tested our autonomous and I was a little shaky about letting the robot go out without Auto. tested. So the match starts, we drop the tube and the robot starts going backwards and smashes into another robot! Of course we got a red card but I was in the stands hiding my face trying not to laugh. Im glad it worked but in the wrong way!!

Epic Fail on my part.

Re: Programming goofs!
 

I felt bad about ours too! I did the same thing! LOL. LOL. I was thankful that teleop started almost after that, it wouldve been insane.

Re: Programming goofs!
 

In 2006, Cyber Blue 234 had a robot where the autonomous went straight toward the upper goal and would shoot the puff balls into it. Well at one point in a single match, the robot decided it wanted to sit still for the first 3 seconds of the match and not move. In that time, a robot from the opposing alliance came careening by and would have drilled our robot at full speed had we moved like we planned it. However, the robot didnt get hit and instead, moved right after the rocket bot missed us and continued autonomous as planned. We, the people in the stands, thought it was one of the best pieces of programming we'd ever seen. We were later notified that the programmers were just as stunned as us and didn't program it to do that. Long story short, we never found what glitched on the robot's programming, and we were still able to hit goals in that match. It also worked properly after that. Very cool :D

Re: Programming goofs!
 

Wow, reading these posts really makes me feel conservative. If an autonomous mode has not been tested (in some form), we won't run it.

Our list of programming goofs over the past few years is long and depressing:) This year seems to be the year of the fat finger.

Tuning autonomous on the practice field in Milwaukee, the robot was suppose to drive x inches, lift the elevator, drive last y inches, score, backup, drop elevator, sit idle. Our coach was standing near the rack chatting with another team member while we were tuning. Lets assume x = 120 inches and (should have been ) y = 36 inches. Let's get those slender fingers out and change y = ~3776 inches.

Things are looking good, robot stops just short of the rack, lifter goes up properly, SLAM full steam ahead into our coach with the elevator ~15 feet in the air. Luckily our coach has the reflexes of a cat and somehow catches the robot and saves the day. Coach: +1 Controls team: 0

Actually now that I think of it ....

During one of the qualification matches in Milwaukee, (after several previous successful autonomous attempts) the robot decided to spin ~270 degrees with the lifter at full height and careen toward the announcer. Robot hits the wall, nearly going over. I watch from the stands as the controls team members slouch further down into their seats. I was sure that the drive team/coach was going to hit the E-Stop. We end up running great in Teleop and won the match. Coach: +2 Controls team: still 0

End up getting picked and didn't have time to debug the above problem. Never ran autonomous in elimination rounds which was a big downer. Since then we found out that the breakout card on the analog module had went bad causing the gyro to very quickly count up instead of showing a constant angle.

I'll stop there ... enjoy!

Re: Programming goofs!
 

This year, while I was working on the tele-op code with my fellow programmers, we were testing the arm on our robot and the arm swung around past its limits, making itself jammed into the gearbox. Luckily, it only broke the fan cooling the motor, so people weren't that mad at me.

Then there was another time when we were testing the tele-op code and I drove the bot into the table we were sitting at.

I was using the wrong controller, but hey, you really do learn from your mistakes.

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

Re: Programming goofs!
 

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)

Re: Programming goofs!
 

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.