![]() |
Silly Programming screw ups (funny)
Post any silly programming errors, screw ups, etc here that you've made either in season or at nationals
My biggest one so far: Nationals: I was coding some side code for our demo board to simulate our braking system, but the guys putting it together used a type of valve I hadn't coded before, and when I was messing with it I turned a simple toggle into something strange. I was calling the toggle (with a trigger on a joystick) on the main processor loop (the 26.2 ms one) without any checks. I turned our single fire brake toggle - INTO A JACKHAMMER. This little 2 inch stroke cylinder was firing in and out at an insane speed. Then I had accidentally set our autonomous values backwards the first time so we drove backwards during a practice match. |
Re: Silly Programming screw ups (funny)
thinking that 0 is neutral.... well we hit the wall....
|
Re: Silly Programming screw ups (funny)
Messing up some type math and making it roll over.
Let's just say for a couple matches last year we just told the driver not to go full throttle forward. Too bad it's hard to explain why that would make it go backwards.. =p |
Re: Silly Programming screw ups (funny)
I wrote out autonomous code, compiled it (no build errors, yes!) and put it on our school's server to use on the computer in the front of the room, where another kid downloaded it onto the robot. I told my coach it was ok to go ahead and test it... so he did... and it went full forward, raising the arm. He almost lost his projector from the ceiling, but found the power button first.
Moral of the story: do not test a robot in a confined space with lots of valuable things. Or, just don't trust me when I say it should work. |
Re: Silly Programming screw ups (funny)
In 2006 I was working on autonomous, and was useing the Limit_Mix() function, and forgot to add 2000 to the input. Before anyone could stop it it had draged a computer onto the floor, and ran into someone. After that I leared not to put the robot on the floor when testing, and I've never screwed the serial cables in again.
|
Re: Silly Programming screw ups (funny)
Leaving the following line in the main while loop for the first match at Wisconsin:
Code:
autonomous_mode = p2_sw_aux1; |
Re: Silly Programming screw ups (funny)
My Junior year in Highschool (many moons ago), I was teaching the new programmers how to , well, program the robot. My pedagogical style is very "hands off" / "turn and burn". I knew that the code they had written wasn't going to do what they thought it was going to do, but I most certainly wasn't going to rob them of this learning experience.
Unfortunately, what it did do differed from both of our thoughts significantly. Such was the birth of the horrible offspring of "spin the bottle" and "chicken". It would boot, spin around, invariably stop pointing at either a person or the most valuable object in the room, and charge into it. Always place your main disconnect in an accessible location. If you don't, be sure that you design your robot so that you can ride it long enough to find said disconnect. |
Re: Silly Programming screw ups (funny)
This year I wrote code so that when our secondary driver held a switch, the claw on our robot would automatically grab a track ball if one entered the claw (we did this using an IR rangefinder). This code was finished and first tested during a competition match at the West Michigan Regional :D. Due to an unfortunate glitch, the claw refused to relinquish the first ball it grabbed. When the team asked what was going on, I quipped:
"You said you wanted the claw to automatically grab the ball. You never said anything about letting go of it." The glitch was gone five minutes later. :D |
Re: Silly Programming screw ups (funny)
2006:
The first time we ran our autonomous in competition we did everything right... except for setting the one little bit that turns the PID on to run the flywheel motors on the ball launcher... basically, it looked like the robot threw up in multicolorful poof ball glory. Another time, our robot was just as happy about shooting 8 balls in rapid succession at an unsuspecting FIRST sponsor wearing a bright green shirt. :yikes: 2008: When first beginning to play with the gyro, I didn't notice (for a few hours) that negative was left and positive was right (opposite math). -q |
Re: Silly Programming screw ups (funny)
2006:
not so much a programming error, but i was wearing a bright green shirt while programming the robot. I was tuning the camera at the time, and stood next to the goal. the robot went out, and looked like it had found the target, except it kept running towards it. So, i get out of the way and go towards the disable switch and the thing starts to follow me, and proceeds to chase me around our practice field, shooting balls at me while i attempt to get to the button. funny thing is, it never shot balls as well at the goal as it did at me. ow. 2007: i used reverse logic for the camera positioning, which led it to spin out of control, while still having control over the arm. one thing led to another, and centripetal acceleration made the robot throw the tube at me. more of a laugh than an ow. 2008: oh god. so while programming hybrid it wasn't a priority for the first couple of runs to have the arm in the 'tucked' position- we only wanted it to drive around. So its going at high speed to the turn, and doesnt do it, instead ramming into the fencing on the other side, tearing the gripper to peices. oops. at the championships i was making corrections for wall distance for the middle ball, and derived it to 285 counts. i typed 385. the robot hit the 3rd ball for no reason i could figure until i saw the code. |
Re: Silly Programming screw ups (funny)
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 :D
|
Re: Silly Programming screw ups (funny)
testing code on our old 2005 robot in our school hallways late at night. Running autonomous it would drive straight while extending the arm (a VERY STRONG TELESCOPING ARM) and the SPIN very quickly. now keep in mind our arm that year could reach 11 feet, and our robot could spin in place in about 2 seconds. Math geeks know this means tip of that arm could max at a speed of about 34.54 feet per second! now, our hallways in our school aren't even 11 ft across, so needless to say we banged up a few lockers. One guy on our team, his name is John, was watching it the whole time, and noticed it always was having a problem after it went something like 13 ft. He says "OK, if it happens again, its gonna hit locker.......*counting to himself quick*.......locker number 874." So while he's goofing off, we get the robot hooked up to a laptop to see what our display says while it's running. So off the robot goes, and after 13 feet we started getting a repeating message on the screen VERY quickly. We pause it for a second, and it say:
"PROBLEMS, ISSUES, CAN'T TAKE IT. RESTARTING. PROBLEMS, ISSUES, CAN'T TAKE IT. RESTARTING. PROBLEMS, ISSUES, CAN'T TAKE IT. RESTARTING. PROBLEMS, ISSUES, CAN'T TAKE IT. RESTARTING. PROBLEMS, ISSUES, CAN'T TAKE IT. RESTARTING. PROBLEMS, ISSUES, CAN'T TAKE IT. RESTARTING. PROBLEMS, ISSUES, CAN'T TAKE IT. RESTARTING."............... John, walks over and inspects the lockers, grins and says "CALLED IT!" (it hit the locker right in the dead center) |
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
Last year, we had a box on wheels and it was put on the field the wrong way. It ran into the wall...
Yeah, we fix everything in the programming.... Including the welds :P -Vivek |
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
Quote:
Quote:
|
Re: Silly Programming screw ups (funny)
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. |
Re: Silly Programming screw ups (funny)
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? |
Re: Silly Programming screw ups (funny)
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...:yikes:
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... Quote:
|
Re: Silly Programming screw ups (funny)
It's always a programming error on our team. Even when the potentiometer is installed backwards... (11pm, Night-before-Ship, 2007)
|
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
Quote:
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) :D. |
Re: Silly Programming screw ups (funny)
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". |
Re: Silly Programming screw ups (funny)
Code:
if (this = that) |
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
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. |
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
Quote:
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. |
Re: Silly Programming screw ups (funny)
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. |
Re: Silly Programming screw ups (funny)
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. |
Re: Silly Programming screw ups (funny)
Quote:
The other programmer working with me once threw this into my code while I wasn't looking: Code:
this line will break your code xD;Code:
import english |
Re: Silly Programming screw ups (funny)
Quote:
Hint for beginners, make sure the cable is off the robot when going to test hybrid after downloading new changes. Check once, twice, and trice. And never tighten the pins down. You'll thank me later |
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
This isn't robot code related, but it is FIRST related.
Last year (during my senior year of high school), while coding Team 228's content management system, I left a few lines of development code in place in one of my email notification scripts. This particular script would email everyone selected, every time a new event was added to the website. To make sure that all the emails were being queued up and sent correctly, I added my own email address to the BCC headers of each email, and then I had the script send me another email when everything completed just fine. I tested the code running on my local Apache server with a few email addresses, and everything worked just fine. And then I forgot about those few lines of code. Fast forward some time later, when I forgot to remove those lines of code when turning the development code into production code for deployment on 228's website. I then proceeded to have my mailbox flooded with 58 emails every time a new event was added to their website. At the time, since I was busy with classes it took a week before I had the time to go and fix that issue. |
Re: Silly Programming screw ups (funny)
We programed the auntonomus mode, finally, in our regonal comp. Our only problem was that it was driving the wrong way (into the wall), and did a major burn-out, tearing up some of the carpet. I don't think we got any points off, though.
|
Re: Silly Programming screw ups (funny)
Hah, I've got a story from this year that wasn't even my fault. We were debugging out feedback controlled lift in AZ, and had just rewired the feedback pot and screwed it down into the proper place. The soft limits in the code hadn't been reset yet and we hadn't verified that everything was going in the proper directions, so I had the electrical team pull the breaker for the lift as well as for the drive motors since we were testing on the floor. A match came up , so I told the electrical team to replace the drive breakers. We sent the drive team out with the robot and presumably without a functioning lift. They come back 15-20 minutes later after the match, and our coach says "Hey, the lift worked great that match."
After I recovered from my heart attack, we determined that the electrical team misheard me and replaced all of the 40 amp breakers instead of just the lift breaker. |
Re: Silly Programming screw ups (funny)
I can't believe I forgot this one. Well, It turned out NOT to be a programming error which we initially thought it was but.
At St Louis we took the bot over to the practice field and were going to, you know, test. I reached in and turned on the robot and WHAM! The arm that we have on it SLAMS into my temple, making me go woosy for a second and I have since had major headaches (getting that taken care of). One of our mentors swore it was a code problem even though the bot was in disabled mode through our disable switch box on our OI, and none of the joysticks were moved. It turns out that our electrician accidentally wired a victor backwards so the arm got direct power and so when I turned it on, it went haywire. It hurt, a lot. |
Re: Silly Programming screw ups (funny)
One time our programming mentor accidentally inverted the autonomous code, so it went the totally opposite way.
He was standing behind the robot holding the tether when we engaged it. He got nailed, but got out of the way in time. Everybody laugh, cheered, and yelled things like "MR. PAWLY, SUICIDE IS NOT THE ANSWER!" |
Re: Silly Programming screw ups (funny)
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 |
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
Quote:
Also, Quote:
|
Re: Silly Programming screw ups (funny)
Well, let's see. During the 2007 season we spent several days trying to figure out why our camera wouldn't track the green light before finally realizing it was mounted upside down.
This year, we had an experience on the field that almost got us a penalty. Due to a short on the RC pins, we lost the 5V bus during one match, which runs the gear tooth sensors. During hybrid mode, the robot went forward full speed and slammed into the opposing alliance's wall. We got a warning from the refs and determined that we could not fix the problem in time for the next match, so we flipped our disable autonomous switch, slightly disappointed. The next hybrid mode, we were reminded that the disable autonomous switch also runs on the 5V bus. Fortunately we didn't get a penalty but the refs said we would get a yellow card if we did it again. |
Re: Silly Programming screw ups (funny)
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.
|
Re: Silly Programming screw ups (funny)
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 |
Re: Silly Programming screw ups (funny)
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.
|
Re: Silly Programming screw ups (funny)
Quote:
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. :ahh: ...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. :yikes: |
Re: Silly Programming screw ups (funny)
Quote:
But the load of money they give me makes up for it. Just imagine what its like to be a programmer on my teams.:eek: BC Programming Mentor Team 1675, 1714 |
Re: Silly Programming screw ups (funny)
You know those lines in the code that say
/* Do not remove */ They really do mean it. that became evident when we accidentally deleted a line in the autonomous code and the robot sat through a whole match. :yikes: BC Programming Mentor Team 1675 , 1714 |
Re: Silly Programming screw ups (funny)
2007:
Team:"Can you make the robot drive forward for two seconds after unfolding the arm?" Programmer:"Sure, that's easy!" Match starts... and the robot careens into the opposite wall! Programmer:"Well, you didn't remind me to stop it!" We were on the ref's watch list for the rest of the event as we later found out. Because of this incident, every time we change the autonomous, everyone asks if it stops when it's done. |
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
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. |
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
mecanum drive code in a tank drive robot
bad things happened |
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
Quote:
One instance where it was my fault: half the team was struggling along with me to discover why no Victor we threw at our proto board would drive a motor. What I eventually realized (and of course, failed to tell them), was that I still had the joystick values overridden to neutral whenever a rangefinder read less than 6 inches. The rangefinder was unplugged, thus "reading" 0 inches. :D |
Re: Silly Programming screw ups (funny)
Another funny one I got is when in autonomous, this year, we were in a practice match in the regionals at L.A. and it was the first time we were going to test autonomous, my autonomous was just said to drive straight, but what I forgot was that one wheel rotated faster then the other, and in my autonomous code I had the robot going full speed. So autonomous starts, and the left motor goes super fast, and the right goes semi fast, and it veers and hits the center divider really hard. Teleop mode starts, and our driver can't start the robot, we go down to check it out after the match, and the battery cable had come unconnected, as well, as other cables, all because of my autonomous, boy did I get yelled at after that.
|
Re: Silly Programming screw ups (funny)
Today at the Vex Championship we added two extra motors to the arm, so I was programming autonomous quickly and forgot to add the stop to those motors. It ended up that the arm flipped over backwards and we actually scored because the arm dumped all the balls into the bridge backwards. Everyone was so stunned since that was never the intention of the program. It was the most amazing autonomous ever! :D
|
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
I modified the "bug" slightly so that the arm didn't go quite as far to prevent damage to the robot, but it was very convent since thats what I was going to work on next. :cool:
|
Re: Silly Programming screw ups (funny)
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. :D
|
Re: Silly Programming screw ups (funny)
With our team, if there's a problem, the builders say its a programming problem. The programmers always think it's an electrical problem. What a suprise...:confused:
|
Re: Silly Programming screw ups (funny)
On our team, even the electrical guys think it's a code problem. But the programmers know it's an electrical problem. :D
|
Re: Silly Programming screw ups (funny)
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.
|
Re: Silly Programming screw ups (funny)
I tried that this year and it worked suprisingly well. :D
The thing I love the most about these accusations is that the code hasn't change since before the code "broke it." |
Re: Silly Programming screw ups (funny)
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.
|
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
Quote:
|
Re: Silly Programming screw ups (funny)
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):D |
Re: Silly Programming screw ups (funny)
Quote:
Code:
#ifdef DEBUG_THISThis 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 :D). |
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/2Needless 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. |
Re: Silly Programming screw ups (funny)
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.
|
Re: Silly Programming screw ups (funny)
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. |
Re: Silly Programming screw ups (funny)
ha well where do i start?
i think the funniest one we've had was when we got the yellow flag at Las Vegas regional. the assistant lead programmer basically redid the coding to make our robot go in low gear and put the code on the robot, but then the head mechanic put the robot in high gear and the robot shot off and crashed into the other teams wall at 15 ft/s |
Re: Silly Programming screw ups (funny)
Hm.. a good one was when I put the wrong value in the code and basically had to sprint to get the driver badge, and sprint again to curie.
The biggest one (for me) has to be when I realized halfway through the season that the reason one of our previous autonomous systems kept spazzing was because a variable was rolling over. |
Re: Silly Programming screw ups (funny)
i thought that -1 was bigger than 1.
|
Re: Silly Programming screw ups (funny)
A bug in our turret this year (failing to MOD the angle before converting it into potentiometer counts) resulted in the turret locking into hard left if the driver turned too many times in the same direction.
This resulted in a very surprised field official being pelted with a moonrock or two before our gunner realized the turret no longer agreed with the joystick... |
Re: Silly Programming screw ups (funny)
One of the programmers came in with a copy of the code on his laptop. He said he had "optimized" the code.
any guesses as to what happened? thanks to the wonders of parallel programming, our new programmer introduced several race conditions and deadlocks into the code. We spent 3 hours looking for all of them before giving up and returning to the previous (more messy) version of the code. what fun. more errors... labview's included PID loop didnt behave like any pid loop we had seen in the past (we tend to keep our kP kI and kD independent of one another), which led to lots of fun while tuning this thing. the weirdest error was if you set the range on the PID loop to "1-255", the target value is "setpoint * range_midpoint / kP". our turret tried to spin 127,000 encoder ticks! |
Re: Silly Programming screw ups (funny)
we had our robot, and our target, and we were testing vision code, and enabled the robot, an it kept spinning to the right, we could not figure out why, then the target holder picked up the target, and it spun to the left. we had our x and y's mixed up :)
we were testing code later, and had this in our code: int loop = 0; ...strcat((char*)loop, "OtherText)... and our robot kept crashing. we thought it was the strcat, but it turned out to be that we were referencing memory at 0, basically corrupting the robots memory. |
Re: Silly Programming screw ups (funny)
Part of our code works when the robot is disabled, and part doesn't. A weekend or two ago, we spent more than an hour trying to figure out why two servos weren't moving. We tried everything -- new cables, changing ports, putting in jumpers... What finally worked was enabling the robot. Oops.
|
Re: Silly Programming screw ups (funny)
Last year, we had a forklift robot, with pointy ends.
When doing auton testing with our practice robot, if we forgot to reset the robot in between tests, the robot would arc 180 degrees, and smash into the wall right in front of our programmer. Well, we remembered for a while to reset the robot, but after we started to move the forks in auto mode, and they would fall down, we forgot a couple times. Twice, our lead programmer was smacked in the face with the forks. So we moved his table back a few feet :P. I'm sure Pat will chime in here saying "When was this?" |
Re: Silly Programming screw ups (funny)
Our programmer downloaded the code wrong and we didn't move for a match (sad funny)
last year we never got the ir board to work right so we had to have our robot crawl out of the starting line. Then we had a match where we put in the old code. we flew out of the starting line going almost 15fps and clothes lined ourselves on the over pass (we had a fork lift type robot). all we could do was laugh our heads off because we where tipped over. I don't remember if we knocked a ball of or not. I think we didn't however. |
Re: Silly Programming screw ups (funny)
Oh, we've had some good ones this year...
At DC, we went through an entire qualifying match nearly unable to drive because I misplaced a decimal point ("but I'm only slightly changing one number; it can't possibly fail!"). There was once at the end of a long night when we couldn't figure out why this line of code failed: if (0 > DBL_MIN) That should have said -DBL_MAX - i.e the largest representable negative double precision floating point number; DBL_MIN is the smallest representable positive number. The funny thing is, when debugging the statement, we noted the value of DBL_MIN to be something like 2.17e-300. Our programming mentor (a senior programmer at CSC) and I must have stared at that number for fifteen minutes thinking "yep: that's negative". The number is obviously positive; just very small, but we could not see that. We came to the conclusion that the compiler had a bug in it (yeah, right) before realizing our mistake. Our robot has a "tuning mode" that allows us to adjust traction control constants on the fly. This mode uses the double-throw momentary switch that normally rotates the turret to adjust one of the constants. After a practice match at Chesapeake, our drivers complained that A) the turret didn't work and B) the drive system was acting very strange. At first we suspected battery problems, but then I realized I had left the robot in tuning mode: every time the second operator attempted to rotate the turret, he was actually changing the P constant for the traction control loop. No wonder it seemed inconsistent. During Chesapeake, we had been setting the traction control to maintain a slip ratio of zero. After a qualifying match, one driver commented that the robot seemed to work much better going backwards than forwards. I looked in the code and realized that I had a sign wrong; when going backwards, the traction control was actually speeding up the wheels, not slowing them down. We quickly realized that a certain amount of slipping was much better than no slipping at all. To date this is the only helpful bug I have ever seen. I once tried to download code three times before finally realizing the robot was turned off, the driver station was off, and the tether wasn't plugged in. At the beginning of build season, we put two acetal wheels on our 2007 bot to simulate the rover wheels. This made the robot imbalanced and caused it to rock back and forth when (de)accelerating. We then tried to do a PID drive using velocity integrated from an accelerometer. The accelerometer was mounted such that the rocking motion of the robot caused it to rotate perpendicular to the axis of measurement, therefore horribly skewing the velocity measurement. This was quite funny to watch as the PID loop caused the robot to drive back and forth repeatedly, tilting the accelerometer just enough to make it stop and go back the other direction each time. |
Re: Silly Programming screw ups (funny)
I'm not programming, but I could certainly hear them yelling. They forgot to check the disable switch. It's only funny because since they'd forgotten so much, they made a massive poster for it. They also added a bit for checking the automated/teleop switch...
|
Re: Silly Programming screw ups (funny)
Quote:
We had that same problem except in reverse, when you would go full reverse 0 it would send 254 to the victors. This caused me to slam the almost done bot into the field in our shop and break a wall:rolleyes: |
Re: Silly Programming screw ups (funny)
Big screw up for us was in 2008 we had arms that unfolded over the front. In auto we never had them reset to folded so it would start wherever it was left. In a practice round everything went fine. The ref asked us if we wanted to go again and we said yeah. We let the air pressure out and folded the arms back up and reset, but never reset the solenoid. Match starts, we come blazing out at like 30 mph with arms unfolding, clipping another bot, sending square tubing everywhere. Oh the rookie memories.
|
Re: Silly Programming screw ups (funny)
At Atlanta, my programming mentor wanted me to prove to him that I hadn't screwed up the autonomous code (which he wrote) when I changed the drive code (which I wrote). Our autonomous has three modes - one to go left, one to go right, and one for the center field position.
I started by testing the go right mode. I looked in the code and saw that it used the encoder on the left to measure distance. I ran the autonomous mode, then spun the left follower wheel manually to verify that it went the correct distance. It did. Then, I tried to test go left mode. I spun the left encoder wheel, only to be disappointed when the robot failed to stop after I spun the wheel the required distance. At that point, we had a match coming up and didn't have time to troubleshoot the problem, so we put the previous code back in for the next match. While the drive team was queuing, I took at look at the code to see what I (presumably) had done wrong. The answer was: nothing. It turns out that, for whatever reason, while the go right autonomous measured distance using the left wheel, the go left autonomous measured distance using the right wheel. Go figure. Back in the IFI days, every so often one of us programmers would mistype the printf() string. This led to a few laughs, such as the time I confusedly reported the PWM output to be "dollar sign dee". We also often forgot that true was off and false was on for the RC digital inputs (as they are on the cRIO, stupidly). This one wasn't a programming screwup, but it happened while we were programming the robot. Last year, we went to a practice field somewhere in a very dry warehouse. Static electricity was a big problem. Once, when I went to plug in the laptop to the programming port, a 1 inch spark jumped directly from a pin on the programming port to a pin on the serial cable, which was connected to the laptop, frying the laptop and ending our practice for the day. Oops. Also last year, we had problems with our IFI controller due to a metal shaving that was hiding under a PWM header. We had to take out a loaner unit, and all they had at spare parts was one of the old controller with only 32KB of memory - or, I guess I should say, 32KiB of memory, because that made all the difference. The size of our code was over 32,500 bytes; we literally were a few variables away from the limit of 32,768 bytes. We're thankful not to have floating point issues anymore with the new control system. In 2007, we had a big function that contained around fifteen floats and attempted to call about ten trig functions - once every 26.6ms loop. We had fun optimizing that one. |
Re: Silly Programming screw ups (funny)
I totally screwed up all of our work [labview] we did for Buckeye regional by using shift registers with all of the code bundles and i missed a robot mode case value and didn't find it until i had completely redone the code thursday night [@buckeye]
|
Re: Silly Programming screw ups (funny)
I was writing some code that was supposed to slowly increase the speed of our shooter. Every test though it went from really slow to full power instantly. I spent an hour on it until I realized that 18 =/= 0.18 (doh)
|
Re: Silly Programming screw ups (funny)
Quote:
http://verizonmath.blogspot.com/2006...rom-cents.html Basically, Verizon can't tell the difference between .02 dollars and .02 cents. |
Re: Silly Programming screw ups (funny)
We made the mistake of not checking to make sure that positive on the motors = positive sensor movement. The crab pods started spinning around and broke all of the sensors (with the bot on a table). Oops.
|
Re: Silly Programming screw ups (funny)
All through build season and our first regional, our software team was working on getting the camera to actually track a trailer. About mid way through our the camera started to track the opposing trailers.
In the beginning of the build season, our software team was jokingly adding code pretty much called "Skynet" where if the camera saw a trailer it would score on it. We were never able to get the camera to actually track, and Skynet was eventually forgotten in the code. Midway through our second regional in Minnesota, we get ready for our match, and I start driving. Well the robot decided to override me and started driving itself! The whole match... it tried to pick up balls and score on opposing trailers. It did rather well, it never scored, but it picked up balls and was rather close to a robot trailer. A team there gave us an award for best autonomous, since it drive the whole match autonomously. Worst moment in competition, but when you think about it, it was the best moment in competition. Our programmers in the pit after the match were confused about how that happened, then they were like "OHHH!!! I know what's wrong.... we have Skynet inside that!!" Luckily they removed it.... |
Re: Silly Programming screw ups (funny)
When testing a new autonomous mode this year that makes our shooter flip backwards so we can shoot behind ourselves, I accidentally forgot to add the part where it stopped the shooter from turning when it reached the backward point. So on the initial test, our shooter started doing circles (which wasn't good, because by design it wasn't even supposed to go backwards...). Needless to say, I was the one left in the shop for 3 hours fixing it.
|
Re: Silly Programming screw ups (funny)
Back in 2011, we made a random attempt at hanging an ubertube in autonomous. The values were completely random, and we were hoping to maybe get it dialed in later on in the elims. It of course hangs the ubertube, top rack, first try. Our alliance lost in the semis, but I do believe that we were the only alliance who did a 3-tube auton.
|
| All times are GMT -5. The time now is 20:26. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi