At the Milwaukee competition, the programming port broke on our controller and we were forced to replace it with the previous year's controller. After re-wiring everything autonomous turns refused to work, yet teleoperated turning was fine. This problem wasn't solved until our next regional (Michigan), when I noticed that the wires for the drive train motors had been switched. The teleoperated code hadn't presented a problem because I had accidentall switched the inputs in the arcade-style drive code.

Yeah, I had that problem, too; our IR board didn't work, I was told to make it, despite it being wired wrong... that was fun. Then, once the wiring was fixed, it worked for a while. When it stopped, I was asked to fix my code (yet the code didn't change!)... ah, the joys of programming. Next year, I'm going to blame everything on the electrical team.

Yep, and you'd think our coach would know that, as he teaches programming (thus why the core of our team had all taken Programming I and II.) However, with most of our team graduating, blaming everyone else will work VERY nicely, as we'll have a completely new electrical team and mostly new mechanical people.

On our team, even the electrical guys think it's a code problem. But the programmers know it's an electrical problem.

I instituted a policy of "defensive programming" a couple of years ago. Simple, easy-to-understand subroutines that provided simple, easy-to-understand feedback to show the state of sensors and their desired operation. The electrical/mechanical group quickly comes to trust the software group when a wiring problem can be identified by the lack of a light or a non-incrementing number.

I instituted a policy of "defensive programming" a couple of years ago. Simple, easy-to-understand subroutines that provided simple, easy-to-understand feedback to show the state of sensors and their desired operation. The electrical/mechanical group quickly comes to trust the software group when a wiring problem can be identified by the lack of a light or a non-incrementing number.

Yeah, same here. Our terminal can display almost any input and output of the RC, so when they tell me that I need to fix something, I just show them that the input is not correct or that the output is correct.

There was one time at the Wisconsin Regional, where i was ready to download new code...
but for some strange reason the laptop that i was using really liked loading up our practice robot's code...
so without paying attention i downloaded the wrong code.
and when we turned on the robot the arm shot up
but luckily we had a limit switch which both of the robots used in the same input...

so when i checked what was wrong i noticed that i had downloaded the wrong hex file
(and then my mentor owed his wife 15 dollars... which they apparently bet that id make that mistake)

Oh and there was one time at the Great Lakes Regional,
Once the match started our arm decided to not go up
right as we came back everyone began to blame me (even my mentor had to "check what i had done")
but then one of our drivers said, before the match started the cowboy hat guy from IFI told them that there was something wrong with the controller but we didnt have to worry about it... and i guess the arm decided not to work
but luckily it worked the very next match (without me needing to change the code)

Yeah, same here. Our terminal can display almost any input and output of the RC, so when they tell me that I need to fix something, I just show them that the input is not correct or that the output is correct.

I did that as well. I basically created a bunch of preprocessor macros containing prints throughout my code, i.e.

Code:

#ifdef DEBUG_THIS
printf("The value of this is: %d\r", this);
#endif

I then created a file called Debug.h containing commented out #defines. Whever I wanted to check a specific system on the robot, I just uncommented the #define that correlated to the system I wanted to check.

This strategy helped us constantly, and even let us track down a loose wire connected to the compressor's pressure switch (even though when electrical blamed me I told them that I hadn't touched compressor code since before we shipped ).

I've been working on the electrical, programming AND drivetrain for the past two years. If something goes wrong with any of those, it's simply MY problem.

2007

I wasn't programming for the first time, but I was programming for the first time that season, and I wrote the code like so:

Code:

pwm01 = p1_y/2
pwm02 = p2_y/2

Oh, and neither wheel was reversed.

Needless to say, it didn't work as I'd planned. Right after I plugged in the OI, the robot spun around really fast and whacked one of our members in the ankle. He jumped around shouting "AARGH! The robot just tried to kill me!", and the mistake was forever named, "The Kill Rimon Program."

Also, in an attempt to slow the robot down a bit, we'd implemented a better, but not completely correct algorithm. The only problem is that when the joysticks were moved forwards past a certain point or backwards at all, the chars overflowed and the robot shot ahead at full speed. Very confusing for our driver, though it didn't cause any crashes.

2008

I had originally written the code to actuate our hoop and trackball puncher (both of which used pneumatic cylinders) to use two buttons each: one to extend, and the other to retract. While this was a very simple solution, the button to retract the lifter was hard-to-reach (p2_sw_top on the left joystick ends up right between your thumb and pointer), so I decided to re-write the program to toggle the cylinder position instead (and therefore only use two buttons). After downloading the code and driving the robot back out to the middle of the room, I realized that something was wrong. Upon pressing either button, nothing would happen, and upon the release, there was a 50% chance that the manipulator assigned to that button would move to its other position. When I stepped up to investigate, I noticed that when a button was pressed, the solenoid it corresponded to switched back and forth rapidly, and upon release, it stopped. At that point, the hoop hit me in the head. I had failed to realize that no one is going to press a button for one cycle of the main loop, so the toggling feature formed a simple oscillator instead.

Another time, I was working on a simple autonomous program that would drive the robot forwards a certain amount, then stop and extend the trackball lifter. I wisely (or so I thought) left it on the cart for its first run, so it couldn't go around terrorizing the school if something went wrong. The wheels ran at a reasonable speed in the correct direction, but the combined height of the cart and fully-extended lifter were enough to dislodge the cover of a nearby fluorescent light, which nearly fell on me. The danger gone, I started trying to figure out how to replace the cover. I thought about it for a moment, then re-hooked the hinges on one side and used the same lifter to push the other side into place.

There was also one time where the left and right encoders were plugged into the opposite digital inputs. Wasted a LOT of time diagnosing that one…

Fortunately, most of our crazy robot stories from this year were actually stupid operator stories, and were able to be stopped by simply letting go of the controls.

This year during a practice match our coder forgot to comment out some autonomous he was testing some code and didn't comment it out and our robot hit one of those boards supporting the overpass and our robot flipped. Quite scary but very funny since nothing was hurt.

Mine would be this year, before the Buckeye Regional when trying out autonomous code back at the school. We didn't have the robot, so I downloaded the code to our motorized cart. And some how, no matter what the dongle was set to, it would always be in auto mode.
A few days later when I fixed that, I was experimenting w/ joy stick control. Ended up giving it an emergency stop. where you had to hold down the trigger button in order to move. While it was a good idea so accidental movement didn't happen, it wasn't practical.
The 'funnest' was when the 'testing' auto. code kicked in randomly when moving the cart. While packing stuff on, it bumped the switch and that was that.