Silly Programming screw ups (funny)

[3DWolf]

I had another screw up at Atlanta-
I had gotten our hybrid code to finally work thanks to Q (1024, THANK YOU SO MUCH) and I forgot to switch the bot to low gear to start with - so this thing was going too fast for me to get a good angle on the IR board to throw the stop button and it SLAMS full speed into the opposing player station. I go out to reset the bot (practice match) and a ref says to me "Can you do something about that autonomous? That was a little rough"
Hehe, yeah I changed it promptly.
Who knew a single variable could be so deadly?

[Los Frijoles]

Well our drivetrain/arm PID code is duplicated in many places due to the patchy programming style which results from me and a mentor showing each other programs and adding in programs and taking out others and otherwise just making a big mess out of things...

I was trying to tune the drivetrain PID manually and so I was modifying our #define's for what I thought was the drivetrain PID...turns out it was the arm PID...ack! time to start over again...

On my hobbiest side:
Because I compile MCC18 projects using batch files which open and close quickly, I cannot even count the times I loaded the same program into a microcontroller because I failed to notice that the link operation had failed (MPLINK does not spit out an error file...drat).

Other times, I have forgotten to turn the power on in many projects...

Originally Posted by Chaos in a Can

Leaving the following line in the main while loop for the first match at Wisconsin:

autonomous_mode = p2_sw_aux1;

Now that must have been interesting...

[Blue_Mist]

It's always a programming error on our team. Even when the potentiometer is installed backwards... (11pm, Night-before-Ship, 2007)

[Chaos in a Can]

Originally Posted by Los Frijoles

Now that must have been interesting...

Actually, it just sat there during auto, and since we weren't using that button to control anything, it didn't go into auto during manual either.

[Mike Mahar]

In 2007 we couldn't download to the robot using any of our laptops. We had no problem with our desktops, however. We tried everything. Whenever anyone would start to help us they would always ask if we were using the right version of the IFI loader. (version 1.1.0) We'd look at the IFI loader and, sure enough, it would say that it was v1.1.

We didn't figure it out until the start oft he 2008 season. When we looked at the IFI loader is was displaying the version of the RC's firmware on the main panel which happened to to be v1.1. When we looked at the version using the About menu, we found out that the loader was actually version 1.0.9. The desktops had the new version and worked just fine. We did have the 1.1.0 version on the laptops but the quick start button on the task bar was pointing at the 1.0.9 version which was still loaded on the system.

This problem was missed by at least 8 experianced programmers, including two from IFI.

[SgtMillhouse648]

Well, in general, debugging is always the "funnest" part of season...i'm being sarcastic if you didn't catch that one...well, this year, I made a controller for our arm that I strapped to mine, and where I moved my arm, the robot's arm moved...well when we went to test the arm out on last year's robot, I couldn't understand why it was giving me something like -28451 for the degrees of the controller...spent an entire night trying to figure it out. come saturday, I realized what the problem was...I was using int's for my variables and some of my calculations went outside the limits...changed them to longs, and it worked perfect.
Then came the fun part...testing it on this year's robot.
for those of you who don't know, this year's robot's arm can rotate behind it, and with a FP driving it originally, can turn into a giant baseball bat as it's swinging around. Well, I had the m value reversed, so the robot was driving the arm the opposite way it was supposed to. needless to say, I replaced the lower section of the arm at 11:00 the night before our media days...
Malhon