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.
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
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.
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.
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.
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 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).
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.
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
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)
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…
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?
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…
