Silly Programming screw ups (funny)

[Mark McLeod]

Originally Posted by ABlackburn

on our team everything is the electrical sub-team's fault

Originally Posted by EHaskins

On my team I'm both.

Don't blame yourself...

[ttldomination]

Well I have a couple of things. Well, one we had a problem with our code because everytime we tried downloading the code, it gave us the Hex Dump error...we even tried different controllers....just didn' work.

Then, in a couple of matches our IR commands weren't working and so everyone was wondering why, guess why? Turns out it wasn't plugged in...someone had screwed it in..but not wired it up...and guess who had to wire it up...ME...guess who had to rewire the new robot controller ... ME....

but it was fun andi enjoyed it.

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

[Cow Bell Solo]

Originally Posted by tseres

this is kind of a funny thing. you see, on our team, everything is the programmers fault, no matter what. it's the way it is. i'm the programmer. we had the robot ready to test, and we powered it on, at which point it flew straight into a heavy table. it was "my fault". turns out another guy was getting ready to go and accidentally buy his backpack on the xbox controller

Saying it's Programmings Fault is a viable reason for everything, EXCEPT THE ROBOT FALLING APART

[slavik262]

Originally Posted by Cow Bell Solo

Saying it's Programmings Fault is a viable reason for everything, EXCEPT THE ROBOT FALLING APART

This is horribly true. We get the bad rap no matter what the problem is.

The funniest thing to me this year:

While in pits, I was often told to "fix my code" so that the robot would work. My response to this statement was "fix your wiring." 95% of the time our electrical guy would come out with a loose wire or a bad relay, and everything would work beautifully the second he fixed it (of course until the next "code" problem, that is) .

[JesseK]

You guys all joke that it's always the programmer's fault...

...but you're the ones who have the power to make the entire mechanical team nervous by saying "I have to download new code".

[Mr. Lim]

if (this = that)
{
    They_Are_Now();
}

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

[gurellia53]

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;

OY! You never told us that

[Carlee10]

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;

I am NOT a programmer, so what does that mean? I really hate programming, its confusing!

[Alan Anderson]

Originally Posted by Water Bandit23

autonomous_mode = p2_sw_aux1;

I am NOT a programmer, so what does that mean? I really hate programming, its confusing!

It replaces the field control system's "autonomous mode" signal with the state of a switch on the operator console. This has two results. First, the robot will not run its autonomous/hybrid mode routine when the field tells it to. Second, the robot will run that routine any time the switch is activated.

This line of code was inserted into a file which contains prominent warnings that it is not to be modified. Some of us programmers know the reason for the warnings, and know that some modifications are "safe". We just fail to clean up after ourselves sometimes.

Oh! That reminds me of my silly programming mistake this year. Our prototype drivebase was built with Mecanum wheels and four independent drive motors, but we settled on a six-wheel skid steer system for the competition 'bot. I decided it was "safe" to leave the strafe function in the code, since we went with y-cables to the drive motors and would thus never be commanding the paired motors to different speeds. Because of the choice of pwm outputs, pushing the joysticks from side to side would end up making the 'bot turn in the expected direction, so I figured we'd be okay with it.

In the pit at Atlanta, after replacing a Victor, we suddenly started having extreme difficulty with the joystick centering. Everything was calibrated properly. The dashboard data told me the joystick trim was perfect. The telemetry from the robot told me both the steering and speed command values were zero, yet the Victors were buzzing and the wheels were turning slowly. After puzzling over it for a very long time, eventually I noticed that the x axis trim was not perfect. Setting it to center made everything fine again.

I immediately changed the code to ensure that the strafe command value was always zero. The speed/steer/strafe mixing is still there, however.

[DPTeam270Driver]

Well, at the SBPLI regional
my programmer decided to tell me and the other driver that he switched the autonomous program so it was backwards right after we put the robot on the field. soo we panicked and jumped on the field to fix the robot and flip it around. the programmer swore that he switched it, and of course it wasn't. so during autonomous, we were driving into the wall.