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.
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
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…
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? 
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.
Worst ones I’ve seen on our team:
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.
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.
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.
That’s why you don’t use the screws on the serial cable. 
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!
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 
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.
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);
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…
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
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, check it out.
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;
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
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.