View Single Post
  #73   Spotlight this post!  
Unread 11-05-2008, 19:02
usbcd36's Avatar
usbcd36 usbcd36 is offline
Registered User
AKA: "DOS"
FRC #2399 (The Fighting Unicorns)
Team Role: Mentor
 
Join Date: Jan 2007
Rookie Year: 2006
Location: Solon, OH
Posts: 151
usbcd36 is a jewel in the roughusbcd36 is a jewel in the roughusbcd36 is a jewel in the rough
Re: Silly Programming screw ups (funny)

So…

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.