|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
| Thread Tools | Rate Thread | Display Modes |
|
#76
|
||||
|
||||
|
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 |
|
#77
|
||||
|
||||
|
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. |
|
#78
|
||||
|
||||
|
Re: Silly Programming screw ups (funny)
i thought that -1 was bigger than 1.
|
|
#79
|
||||
|
||||
|
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... |
|
#80
|
||||
|
||||
|
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! |
|
#81
|
||||
|
||||
|
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. |
|
#82
|
|||
|
|||
|
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.
|
|
#83
|
|||||
|
|||||
|
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 . I'm sure Pat will chime in here saying "When was this?" |
|
#84
|
|||
|
|||
|
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. |
|
#85
|
|||
|
|||
|
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. |
|
#86
|
|||
|
|||
|
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...
|
|
#87
|
|||
|
|||
|
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 ![]() |
|
#88
|
|||
|
|||
|
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.
|
|
#89
|
|||
|
|||
|
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. |
|
#90
|
||||
|
||||
|
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]
|
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| pic: I Love UPS! | dubious elise | Extra Discussion | 15 | 05-05-2006 16:43 |
| pic: UPS with UPS | Kevin Kolodziej | Extra Discussion | 10 | 04-05-2005 12:57 |
| I am silly. | FotoPlasma | Chit-Chat | 15 | 07-01-2003 09:55 |
| silly fun | Mark Hamilton | Chit-Chat | 8 | 29-10-2002 13:56 |