Silly Programming screw ups (funny)

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

I'll contribute with probably my least serious, and most funny programming error I've encountered (outside of FIRST, but we were working in C/C++).
My freshman year, I took an introductory computer science class, and our final project was to design and code a remake of Tetris. We've been working on this project for a little while and it seems as if all the major flaws (that we found) were out of the code. Our team leader maintains this Windows independence, and will only work on his laptop, or, if he has to, in notepad (since MS Visual Studio is "evil" in his eyes). We finish work on the code, and GUI, compile everything, and...it doesn't work.
Try again...
...And it still doesn't work...
...We decide to each look over our parts of the code since the error messages were being less than helpful in figuring out why the code wasn't working...
...Try again...
...Yet another failure...
...Our experienced programmer gives up, calls it a day and checks in the code. I check it out for the rest of the team to work on for a little bit, open MS Visual Studio...
...And it immediately highlights the little " /* " at the top of the page that the senior team member forgot to delete when he took out comment header that described the beta process we had gone through.


We had inadvertently, commented out our declarations and main() since the next instance of a " */ " was below the code. We had used // comments everywhere else.


Proving that notepad, while incredibly useful, is not always the best program to use.

[ExarKun666]

One of my countless screw ups as a rookie coder was when I was coding for the encoders at one put I changed the sign one positive and one negative, since it was a tank drive, which is logical, and I turned it. First mistake was I left the cable in so it bulled the laptop, but I luckily caught it, and second it span in really fast circles.

[mcf747]

2008:

I am hooking up the electrical and working with our programmer to well drive the motors im hooking up.(the two window motors keyed together). Any way we have a button set to automatically shoot the ball out of the arm and then drop the arm to a position where it can pick up a ball again. At our first regional we end up inverting the position of our window motors and go out to another practice match. We start the automatic sequence and bang the arm drives backwards and fold over itself crashing into the back of the robot. We cant figure out what happened but I think it was the recoil from the punch so i tell our drivers to not raise the arm so high when they fire it and in the next match it does the same thing. We put a hard stop, using steel wire, on it as the arm was "pushing" through the stop sensor think this would stop the recoil. We send it back out and it happens again and then i remember that we never reversed the code when we inverted the motors, and the powerful worm drives pushed through our hard stop and the delay was to great from the senors that the arm was already more than half way over when the arm lost its momentum, crashing down anyway due to gravity.

What we learned:
-Two worm drives are no match for a 20G steel cable
-Remember to check code after inverting ANYTHING
-Built a robot so tough it can handle major abuse to cover for the occasional mistake

Matthew
MorTourq 1515

[Jay Lundy]

In 2001 I was trying to write a program to automatically balance the bridge (which was basically a big see-saw) with our 2000 robot and a gyro. My first idea was to have it slowly drive up the bridge until it sensed rotation, then have it reverse proportional to the gyro input. Unfortunately I got the gyro input backwards, and as the bridge started to tip instead of reversing the robot began to accelerate. The faster it tipped, the more it accelerated. Fortunately the bridge and the robot came crashing down on the other side before the robot could launch itself off the end or else it would have really caught some air.

[Qbranch]

Originally Posted by mcf747

What we learned:
-Two worm drives are no match for a 20G steel cable
-Remember to check code after inverting ANYTHING
-Built a robot so tough it can handle major abuse to cover for the occasional mistake

*chuckle* I guess you didn't need MorTorque.

Back when we were using a toughbox transmission at the Midwest regional, the 36:1 -> 12.75:1 reduction from the dual FP motors was SO SLOW... but way way too forceful (it could lift the whole robot without breaking a sweat).

Well... and we found out on our practice bot that if it did break a sweat... it bent a 9" length of beautiful new 1/2" stainless steel shaft.

...After that we made a new single-reduction-stage transmission that saved weight and turned all that extra force into lightning quick arm speed.

-q

p.s. It never screwed up the right way in competition, but we found out that if you pick the ball up then hold the manual up button with only a few psi of air in the system... the ball flys out and actually goes high enough to hurdle over the back of the robot with a perfect shot.

[JesseK]

This one reminds me of Zoolander:

On our scrimmage bot from the summer we broke a banebots 56mm drive transmission due to over-agressive driving and direction changes. Since we didn't want this happening to our expensive new AM shifters, the coding team implemented a "soft steer" drive that limited how fast the robot could change directions for the '08 season. They had limited testing due to unforseen and unavoidable build-team delays.

We get to VCU in week 2 and all of a sudden the robot can't turn left in teleoperated mode! This was the cause of most of our penalties at VCU. All our driver could say was "I don't know, don't blame me, I'm not an ambiturner!". We commented out that portion fo the code Friday night and BAM it could turn left.

[AdamHeard]

Originally Posted by JesseK

This one reminds me of Zoolander:

On our scrimmage bot from the summer we broke a banebots 56mm drive transmission due to over-agressive driving and direction changes. Since we didn't want this happening to our expensive new AM shifters, the coding team implemented a "soft steer" drive that limited how fast the robot could change directions for the '08 season. They had limited testing due to unforseen and unavoidable build-team delays.

We get to VCU in week 2 and all of a sudden the robot can't turn left in teleoperated mode! This was the cause of most of our penalties at VCU. All our driver could say was "I don't know, don't blame me, I'm not an ambiturner!". We commented out that portion fo the code Friday night and BAM it could turn left.

For future reference, you can run the AM shifters HARD without issue.

[billbo911]

Originally Posted by Alan Anderson

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.

In my line of work, we affectionately refer to this approach as "Seagull Engineering". Why? Because we swoop in, flap around making a lot of noise and commotion, leave a big mess of "stuff" behind and then fly off. (You can substitute your own words in for "stuff" ) No one really knows what we did or what happened.

[11Mort11]

mecanum drive code in a tank drive robot
bad things happened