Stupidest Programming Mistakes

[Matt Krass]

Alright everyone, let's have a collection of this seasons dumb programming mistakes, it'll be educational, and fun, and maybe I won't make as many dumb mistakes after seeing all the ones possible!

My gyro code was broken because I always checked to see if the output was greater than zero, and if so, set it to zero.....no wonder the robot always spun to the right...:)


if(GyroSample > 0)
GyroSample = 0;


Two days troubleshooting that one, thanks to Drew Shapiro from 417 for spotting it.

[ForgottenSalad]

No specific code snippets, but there's been plenty of times where I've tried to compile and gotten 10 or more syntax errors... only to realize I'd left out semicolins on every single line I had added that needed them.

I did, on the other hand, sit there for hours today trying to find out why digital_io_01 wasn't working... Only to realize that I wanted rc_dig_in01

[radicalnerd]

last year somebody deleted +127 at the end of our speed scaling code. it shot backward rather quickly.

[Tureyhall]

last year somebody deleted +127 at the end of our speed scaling code. it shot backward rather quickly.
and just today, we couldn't figure out why one of our 3 way switches was giving funny results. I kept checking the code, commenting out things i thought might be the problem, and it turns out i reversed the wires on the switch when i unplugged it to mount it.....

[Eldarion]

No specific code snippets, but there's been plenty of times where I've tried to compile and gotten 10 or more syntax errors... only to realize I'd left out semicolins on every single line I had added that needed them.

I did, on the other hand, sit there for hours today trying to find out why digital_io_01 wasn't working... Only to realize that I wanted rc_dig_in01

Been there, done that, chewed up two limit switches in the process... :rolleyes:

One of the most aggravating things I have run across to date is actually an IFI stupid mistake from 2005. They threw in a while loop, looping 20,000 times, every time new data came in from the camera. This caused the code to take practically forever to execute, but somehow didn't trigger the BLROD. Commenting out the while loop fixed the problem without damaging camera communication; I wonder why it was in there in the first place? :confused:

[Tom Bottiglieri]

Ehem...

http://www.firstwiki.org/media/2/2e/RobotAttack.avi

[Donut]

This is easily the worst mistake made this year.

Else (current_state == enabled && last_state == disabled)

It took us 3 hours of staring at it to realise you can't put conditions on an else.

[kaszeta]

Worst ones I've seen on our team:

1. Our variation of "when robots attack", when someone re-routed the shaft encoder harness to where one of the CIM motor chains could suck it in, resulting in one of the shaft encoders zeroing out while the other incremented, causing a wild spiral while folks are falling over themselves to hit the disable switch on the OI.

2. Various spastic responses from leaving the backup battery off the bot and having the motors draw enough current to reset the RC, causing very, spastic results.

[Andrew Blair]

Last night, tried to get my drive code lookup table to compile. Turns out that I did everything right...except NAME THE STUPID THING!!! :ahh: Thanks to Alan Anderson for catching it.

[ForgottenSalad]

Ehem...

http://www.firstwiki.org/media/2/2e/RobotAttack.avi

That's why you don't use the screws on the serial cable. :D

[6600gt]

if(joyin - pwmout > rate)
pwmout = pwmout + rate;

joyin - pwmout could be negative but they were all unsigned variables so it never looked at nagatives. So for example it would still execute when (-10 > 5)

Took 2 hours to realize that!

[Mike]

I won't mention the hundreds times I've forgotten a semicolon, I'm sure that's all too common.

So I'll mention the time I was debugging a version of code and wondering why the printf's weren't working. Turns out I was downloading the old (buggy) version of the code :(

[theycallhimtom]

Working on code for a few days working through all the bugs. Then when it coms time to use it a few weeks later I have lost the code and have forgotten how I fixed all the problems I came across. So I had to redo the code and attempt to remeber how I dealt with each error.

Also assuming that ints were 32 bit caused me some pain.

Oh and almost every day when I download code to the robot I download from the wrong project and realize it a few mins later when the printfs are all wrong.

[Eldarion]

One of the things that keeps tripping us up is that the MPLAB compiler does not follow standard C data type promotion rules.

For example, given the statement below, standard C would promote both data types to integer, then multiply. The MPLAB compiler, however, multiplies a and b as unsigned chars and then sticks the result in the integer value, resulting in an overflow where you least expect it! :ahh:


unsigned char a = 127:
unsigned char b = 127;
int result;

result = (a * b);

[seg9585]

We've had QUITE a few:

to convert angle radians to degrees:

int tiltdeg = tiltrad*( (int)3.14 / 180 );

hmmm, no wonder why we kept getting "0" as a tile angle...
and oh yeah, it shoulda been 180/3.14 to begin with...


In trying to comment stuff out with "/* */", we realize that we comment out other stuff already commented out using the same method, and whenever it reached that comment's "*/" it would end, causing a bunch of syntax errors throughout the rest of the uncommented code, and we couldnt figure out for the life of us why it was reading that code...

and dont know what we were thinking here:

if(TILT_SERVO > Tilt_Servo_Max)
TILT_SERVO = Tilt_Servo_Max - Tilt_Servo_Min + Step_Size;

um, I think we were trying to have the camera search in the last area it saw the light if it immediately loses it too high...but um.. Tilt_Servo_Min = 0 and Step_Size is greater than 0...

[Matt Krass]

In trying to comment stuff out with "/* */", we realize that we comment out other stuff already commented out using the same method, and whenever it reached that comment's "*/" it would end, causing a bunch of syntax errors throughout the rest of the uncommented code, and we couldnt figure out for the life of us why it was reading that code...


Little trick Mark McLeod showed me for that:


#ifdef //This is actually a comment block, #1
code
code
code
#endif //This is the end of comment block #1


Since the #ifdef is missing something to check, it always fails, so any code in it never compiles, doesn't get stopped by */, quite useful

[Mike Shaul]

The C Programing language has MANY different "issues" with undefined behavior or easy-to-make mistakes that compilers won't usually catch.

This website has compiled 10 (actually more than 10) common mistakes (http://www.andromeda.com/people/ddyer/topten.html), check it out.

[Goldeye]

My teammate made a great slipup that him and a mentor didn't catch till I looked. Here it is (with the error) in a function for averaging something in pseudocode.

int sum,count;
while(stuff_left)
{
sum+=stuff;
count++;
}
if(!count == 0)
return -1
else
return sum/count;

[Cuog]

I havent made any hilariously dumb mistakes coding, i have done the condition after the else statement but i caught it quickly and i have also done the good old no semi-colon, but my most hilarious story is from an alumni from our team on his first programming attempt,

Basically to init his PWM values he set them to 0 logically thinking that zero meant no speed, the robot the ran full speed backward over the laptop he was using to program giving it the name "smokey" for ever and now i have to try and fix this old i286 laptop to use for some random off season stuff

[Kristian Calhoun]

this was one that someone els eon our programming team made that i had caught. we kept trying to compile the code and we kept getting an error, it ended up that instead of pwm01 and pwm02, that the other member of our team had put pwn01 and pwn02. we reached the conclusion that you cannot pwn the pwms lol.

[scitobor 617]

For some reason whenever I open a project in MPlab it automaticlly opens user_routines.c from an old version of my code. It took me half of a saturday to figure out way changing stuff in user_routines.c had no effect what so ever, even when I intentionally added errors that should have caused all kinds of compile time errors. I still do not know what is causing this but I now know to check which file I'm editting before I make any changes.

[BrianR]

Today we were trying to do our angle calculations, and we had made a trig mistake. So we changed it and uploaded the code. But for some reason it kept having the same problem. After we changed some other stuff to no result, we happened to notice that the loader was calling the wrong code, and that for some reason, it had built the .hex file to a different spot. Once we figured that out, it worked like a charm.

[Chris_Elston]

if (varible = 1)
{
do this;
}




Burns me ALL this time....don't forget to use DOUBLE equal signs....

[tpc]

Burns me ALL this time....don't forget to use DOUBLE equal signs....
This is why I always write the constant first, when comparing equality between a constant and a variable:

if (1 == variable)
{
/* do something */
}
Then if I inadvertently use an assignment rather than a comparison, it's a compile-time error (can't assign a value to a constant).

[ForgottenSalad]

I spent an hour and a half or so trying to figure out why a new revision of our code wasn't working at all today. After switching speed controllers, cables, checking for abnormalities with a multimeter... I realized I had never called my routine. I ended up (stupidly) slamming my fist down on the laptop. :ahh:

[Chris_Elston]

This is an EXCELLENT idea. Thanks for sharing this.




This is why I always write the constant first, when comparing equality between a constant and a variable:

if (1 == variable)
{
/* do something */
}
Then if I inadvertently use an assignment rather than a comparison, it's a compile-time error (can't assign a value to a constant).

[X-Istence]

Listen to the compiler when it tells you about casting. Don't try to force something to cast, and then lose information. Like going from unsigned to signed ints.

[Idaman323]

Well, It wasn't exactly a programming error, but it made me think it was. Someone, when wiring the bot, plugged the speed controllers into the Relay outputs instead of the PWM outputs. I sat there looking through the code trying to edit, and reload code on the bot for 3 hours.

Our Robot Controler was upside down, so I couldn't see what it was plugged into. Everytime I aksed someone to check the speed controllers, I always asked someone else to check it, Since I didn't wire it. I wasn't sure exactly how it was wired. Finally after getting REALY tired of mesing with it, I lay down under it and looked. I was look and the robot controller to find out the speed controllers were in the Relays and not the PWM. After that, It worked from then on out. It got me very frusterated :) But now its all good.

[jfelser]

I dunno if this is truly a programming mistake... but testing autonomous (using PID) we forgot to plug in one of the the interrupt pins on the encoders, resulting in a very interesting open-loop control system, and various material damages (the robot LED, the green light, the 6' stack of books the light was sitting on, the desk the books were sitting on, the counter with microscopes behind the desk with the books and light, and my self confidence).

[Brad Voracek]

We've had one major error that took -forever- to figure out.

We had this cubic function for the drive system, since it would increase slower... And it built and all, but when we loaded it an error popped up in the IFI command prompt, all in HEX. It took a while until we realized that victors couldn't take floats @.@

Then we had to change our step(which works very well now, speeds up slowly then stops fast, speeds in reverse slowly but goes to 127 again fast.) from .8 to 1 =P All is good now... also we decided to move our autonomous code to a new file, and leave manual in another... Only to forget to change this
#ifndef __399_Code_h_ in our header file to the name of our Autonomous file @.@ That gave us the same hex error stuff... Oh well! All is good now... Except it seems like our cam is fried. =/... Will be able to test it more tommorow =(

EDIT: After reading tons of the messages here, it seems that those hex errors were actually oversized memory? I doubt we have the new IFI loader so eh... I guess maybe we can go back to our cubic. This works good though, so we'll see.

[Adam Shapiro]

How about having a programmer delete PutData as "unnecessary" in a code update 2 minutes before a match?

[Dillon Compton]

How about having a programmer delete PutData as "unnecessary" in a code update 2 minutes before a match?



...ouch.

[JugglingSuns120]

Well our "programming" errors tend to really not be programming errors at all. One of the more frustrating ones we had this year happened a couple weeks ago. We were testing some code for gyros we are using. Well after two hours of pouring over the code trying to figure out why our printf with the variables wouldnt work we realized that we never tethered the OI to the the robot controller.

[slade24]

My associate programmer decided to add Limit_Mix calls to the equations for joystick input / pwm output. He uploaded the code, but before we tested it he left, and took with him the updated code files (when I asked to get a copy, he uploaded only the .hex file onto my computer for some reason). Apparently he didn't read the Limit_Mix function correctly, because when we fired the robot up and began testing the ball launcher, it started spinning backwards! :confused:

In the dilemma that ensued, we reversed the polarity of the motor to get it to spin correctly (though we didn't know what was the original cause at the time). The launcher worked, but then we noticed its speed couldn't be adjusted.

Upon reaching home, I looked at the code (we post it onto a team wiki) and found... lo and behold, he forgot to add " + 2000" to the Limit_Mix calls. After fixing this error, I realized how lucky the team was to have remembered to take the drivetrain fuses out before testing the launcher -- all functions calling Limit_Mix were being returned as 0 (FULL REVERSE!). :ahh:

We almost had a mass murdering robot (at least this years robot doesn't have a huge arm like last years -- now that would have been bad).

[CmptrGk]

just yesterday i made an incredibly stupid mistake

if(TempCount4BA <= 38)
{
BALL_MOVER = 1;
}
else if((TempCount4BA > 38) && (TempCount4BA <= 78))
{
BALL_MOVER = 0;
TempCount4BA = 0;
}
TempCount4BA++;

needless to say, the air postion never "moved"

[aaeamdar]

Last night, tried to get my drive code lookup table to compile. Turns out that I did everything right...except NAME THE STUPID THING!!! :ahh: Thanks to Alan Anderson for catching it.


Gosh that is funny. When programming in java I've gotten so lost in public static final volatile private blah that I forgot to give it an actual type. I did this:

public static final theta;


It no like that...

Good thread.

Paul Dennis

[aaeamdar]

I had this:


auto_mode = ~auto_select1 + 2(~auto_select2) + 3(~auto_select3);


Where auto_mode is later used in a switch{case:}, and auto_selectNs are variouss rc_dig_ins.

Can someone spot the error there? Yeah, 2() is not a valid method. So I changed it to this:


auto_mode = ~auto_select1 + 2*(~auto_select2) + 3*(~auto_select3);


And it still didn't work. Gee whiz. What is wrong now. It gives me a run-time unexpectedness glitch where auto_mode is calculated to be 246 or some nonsense like that. OK, fixed that by not using the binary complement and instead used the logical complement (in a #define) and it works.

In another one we had:


printf("Some motor values %d %d %d", 1,2,3);//Whatever


And nothing was printing. Gosh, that sure was weird. Well, it turns out that we failed to import stdio.h (or anything else that gives us access to printfs). And then, to make things worse, the C language is so incredibly stupid that all it gives you is a warning because it's not prototyped. Since we had been using some other methods that weren't prototyped (may have been a few in Kevins Code) those warnings got mushed in with the others.

Thank goodness for Java.

Paul Dennis

[Jake M]

How about spending an hour trying to decipher a run-time error and systematically commenting all of our added code up to that point, only to later find we were compiling with the 2005 FRC settings instead of 2006?

Oh, and this isn't really a programming error, but I still think it's up there as stupid. In our third or fourth practice match last year, our robot suddenly started smoking out on the field. We had used a large ribbon cable to wire the camera and dozens of switches throughout the robot for use in autonomous mode to sense and pick up tetras, and cap them, which had been working perfectly. As it turns out, several of the spare wires, which was about half of the cable, that had been cut off from removed sensors and never removed from the electronics, and that included several five volts and grounds, had brushed up against the frame, which, simply put, melted the entire cable and fried our camera.

[Calvin]

I decided to make life easier and write functions, and reuse them through out the program... Last night I spent 2 hours trying to figure out what was wrong with the functions, later I discovered that I forgot to include them in the user_routines.c

[GeorgeTheEng]

During the stack attack game, in Atlanta, we had to change our autonomous code. I had a brain fart and missed the fact the motors were moving in different directions on left and right sides. The robot was supposed to move forward for x seconds. Instead it looked like it was dancing as it spent all autonomous mode spining around. :D

[P1h3r1e3d13]

Originally our drive motors were hooked up such that 255 on both sides made the bot drive backward, because the person wiring them didn't know what the polarity should be. At this point I was using EasyC's Tank command to drive the bot, so I told the electronics people not reverse the wiring, because it was easier for me to just check "Invert direction" in EasyC.

My (yet untested) autonomous code, however, used PWM commands, which I had already set to numbers greater than 127 to drive the bot forward (logically).

For the longest time, I couldn't figure out why it drove backward in autonomous....

[Rickertsen2]

Earlier today i was confounded with a mysterious bug in my php code. No matter what i did, i couldn't get it to work. After exhausting everything i could possibly think of, i spent another 15 minutes scouring the php manual thinking my bug might be due to an obscure security permissions issue. Well, it turns out I was uploading my code to the wrong server. I felt pretty dumb as i realized i fixed the bug half an hour ago.


------------------------------- edit ----------------------------------------
At regionals i had block of code like:
...
if(condition)
//do something
...

which i later changed to :

...
if(condition)
//do something
//do something else

without adding the brackets. I tend to do that often. In any case it caused out robot to automatically aim at people level and autofire/load until it ran out of balls

[Chris Hibner]

Earlier today i was confounded with a mysterious bug in my php code. No matter what i did, i couldn't get it to work. After exhausting everything i could possibly think of, i spent another 15 minutes scouring the php manual thinking my bug might be due to an obscure security permissions issue. Well, it turns out I was uploading my code to the wrong server. I felt pretty dumb as i realized i fixed the bug half an hour ago.


------------------------------- edit ----------------------------------------
At regionals i had block of code like:
...
if(condition)
//do something
...

which i later changed to :

...
if(condition)
//do something
//do something else

without adding the brackets. I tend to do that often. In any case it caused out robot to automatically aim at people level and autofire/load until it ran out of balls


This is an EXTREMELY common mistake. In fact, most companies' coding standards require to use braces {} even if there is only one line of code in the code block. The reason for this standard is to aviod the bug you speak of. We mention this in our Advanced Programming presentation at the FIRST Robotics Conference that we presented last year (and will be presenting again at 3:00 tomorrow.

It's good that you finally caught it. I would definitely suggest always using braces.

[nehalita]

How about I made a new program during Florida Regional that did something simple for a few seconds and then was supposed to stop. I forgot to set the pwms to neutral. It kept going. That flipped our robot.

[KenWittlief]

stupidest programming mistake I ever made

when I was in college I took a course in the language LISP. This language is all functions, and you can define or change the definition of any function, even the core default ones built into the language.

I was entering code on a terminal at the computer center, and the terminal wacked out for a second. I thought the mainframe was crashing so I typed

EXIT <return>

which is how you get out of the LISP program space.

But then the terminal was ok, it did not exit, it just kept running. So I finished up my project, printed the listing and entered

EXIT <return>

and nothing happened - I was still in LISP - it wouldnt stop running.

Then I realized just before the terminal wacked out I was defining a new function, so what I had really done was enter

Define EXIT <return>

which in LISP means: define the function 'EXIT' to be nothing!

I had to sit at the terminal for 30 minutes to wait for the mainframe to timeout my link and kick me off.

[lukevanoort]

At the meeting last week, I managed to finish the exponential drive code (Excel saved my butt there) and loaded it into the robot. Putting it up on blocks (always a good idea with new code) I noticed that it ran fine in reverse, but when the joystick was pushed forward the wheels started turning fast then slowed to a stop. My problem? I had forgotten to add 127 to the value from the look-up table... stupid stupid stupid.

[EHaskins]

When i was testing my custom joystick mixing code i forgot to add 2000 to the value before i sent it to the Limit_Mix Function. The robot was on the floor and wnet full reverse it ran over one person and finaly ran into a workbench before anyone could shut it off.

[Joe_Widen]

While one of our programmers was cleaning up the code, he accidentally deleted a line that said *DO NOT DELETE THIS LINE*. Well anyways it gave us quite a few headaches in Milwaukee.

[Adam Shapiro]

While one of our programmers was cleaning up the code, he accidentally deleted a line that said *DO NOT DELETE THIS LINE*. Well anyways it gave us quite a few headaches in Milwaukee.
That happened to us 3 years ago. One of our programmers accidentally deleted the PutData line about 2 minutes before a match. We ended up on the field with a code error and a loss to our record.

[coldabert]

This isnt as stupid as it was an accident but I'm still not going to mention the guy who wrote it:

We had a winch system that would connect to our drive motors. The point was to engage the winch when the cable was taken off the robot and hooked on the bar (2 years ago). Well, he engaged the winch during autonomous and the aircraft cable (which doesnt break) was wraped around the frame of the robot and the dead reckoning code simply drove the motors. The cable just got tighter and tighter. Needless to say the 1/2 inch steel tubing was a little bent and the entire frame looked like a car wreck.

Thats when we decided that only one guy should make the programming mistakes.

[aaronm_k]

One of the things that keeps tripping us up is that the MPLAB compiler does not follow standard C data type promotion rules.

For example, given the statement below, standard C would promote both data types to integer, then multiply. The MPLAB compiler, however, multiplies a and b as unsigned chars and then sticks the result in the integer value, resulting in an overflow where you least expect it! :ahh:


unsigned char a = 127:
unsigned char b = 127;
int result;

result = (a * b);


You can turn on integer promotions by going to "Project" > "Build Options" > "Project" in MPLAB, clicking the "MPLAB C18" tab, and adding "-Oi " to the beginning of the "Use Alternate Settings" text box. (Checking the "Enable integer promotions" check box will NOT work.) Believe me, I had plenty of trouble with this too! :)

[Astronouth7303]

The stupidest programming mistake:

Assuming the programmer is driving.

[Robert Flanagan]

Hehehe, of course semicolons r an issue.

The biggest mistake was working on autonomous. It was at nationals and I still dont know what I did wrong but fixed it. As soon as autonomous started the bot drove forward then started spinning to the left firing into the crowds, judges, everywhere else.

[Alexa Stott]

One stupid mistake I made at one point was that I forgot to close something off. I was too lazy to go back and look for it, so I just added a random "}" at the end of the code. Problem fixed! :D

[Robert Flanagan]

While one of our programmers was cleaning up the code, he accidentally deleted a line that said *DO NOT DELETE THIS LINE*. Well anyways it gave us quite a few headaches in Milwaukee.


That's why you always save a copy of the default code.

[kaszeta]

Hehehe, of course semicolons r an issue.

The biggest mistake was working on autonomous. It was at nationals and I still dont know what I did wrong but fixed it. As soon as autonomous started the bot drove forward then started spinning to the left firing into the crowds, judges, everywhere else.

Team 95's robot did this in the practice pits at Manchester. It was rather entertaining, which helped offset the frustration.

[LordTalps]

Was working on the Marine Biology Study for AP Computer Science AB, and had was running through making a fish (was easy after the first 5 or 6 we made).

All of a sudden, STACK OVERFLOW? What in the world?

isolated it to a method that returned a class variable, myID. That method was one line, it couldn't be the issue. Lo and behold, it was pointed out:

public int myID()
{
return myID();
}

:(

[Booger]

i loaded the defualt code from last year, and the robot just started going. It ran into a table and knocked everything over. Luckly it wasnt facing the otherway becasue it would have went down the road.

[thegathering]

i loaded the defualt code from last year, and the robot just started going. It ran into a table and knocked everything over. Luckly it wasnt facing the otherway becasue it would have went down the road.
Related bug, we had a 1 in an assembly level if check instead of a 0 (one of our less experienced coders put it there) and all the motors ran by the method just started running at full speed. Luckily this was early on and the motors were not attached to the bot yet.

[Booger]

Related bug, we had a 1 in an assembly level if check instead of a 0 (one of our less experienced coders put it there) and all the motors ran by the method just started running at full speed. Luckily this was early on and the motors were not attached to the bot yet.

Yeah we ended up putting the robot on wood blocks just so it doesnt do that again because its a real pain.

[Pat Fairbank]

On Thursday at BAE I was kind of embarrassed because the audience kept laughing when our robot would shoot its 10-ball clip clear over the driver station wall every autonomous mode (and nowhere near the centre goal), due to poor aiming code.

Well, I had been steadily increasing the gain multiplier on the turret aiming routine between the practice matches, and couldn't understand why it wasn't getting any better, so I just kept upping the parameter. :rolleyes:

About four matches in I realized I had been downloading the same, wrong .HEX file to the controller every time, so I downloaded the correct one to test during the next match. Of course, at this point the gain multiplier was about ten times what it should have been, so this time the balls went flying in all directions as the turret oscillated crazily.

Luckily it was just practice day.
(Even luckier, the next time I got to test out a new gain value was during the first qualification match, and it worked 10 for 10. :))

[Qbranch]

Was figuring out the kinematics of how to make the arm on our '05 bot to move to a position, and couldnt figure out why the second link of the arm wouldn't move...

Well i forgot all about the part where when i first started writing the code i had the arm set to neutral so i wouldnt hurt myself :yikes:

So:

<Fancy Code>
...

ArmMotor=127;
TxData(&txdata); :ahh: