|
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.
__________________
Go directly to queue. Do not pass pit.
|