Stupidest Programming Mistakes

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

[aaronm_k]

Originally Posted by 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!

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.

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

[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]

Originally Posted by Adam Shapiro

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!

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

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"