What is the strangest issue with a robot you have ever seen?

[ns3517]

Our robot kept losing connection during our first couple matches at our first district event. The problem was every time we went over a defense our sponsor board would flex a bit and tapped our main breaker button just enough to reboot the radio....

[ollien]

Originally Posted by ns3517

Our robot kept losing connection during our first couple matches at our first district event. The problem was every time we went over a defense our sponsor board would flex a bit and tapped our main breaker button just enough to reboot the radio....

Oh god something like this happened to us at one of our events. Our method of mounting our top plate was a bit janky (we put it in the slot of some REV extrusion with some bolts on either end) and it sometimes fell out mid-match. We were in Q31 and Q37, meaning we had no time to fix the issue between matches. We had a proper mounting method in the works but the time it would have taken to put it on would have made us miss our next match. We went the match without the plate and forgot that our penumatic release valve was normally attached to this plate, meaning it was free-flopping. We went over the moat and got stuck. After a team member pushed us we went completely offline. Our driver checked it out and noticed that the button had been pushed JUST enough to put it offline. :/

[simpsonboy77]

I can think of 2 pretty weird issues. The first one was my fault, we used an encoder with too many ticks per rev connected to a CIM. We had this feed into a jaguar for I think speed control, but I don't remember. When the CIM would spin up to full speed, the jaguar controller could not keep up with the interrupts and would lock up. Even disabling would not cause the motor to stop.

Another issue was at 2013 Bridgewater. I was in the pits as a CSA and the FTA radioed me that a team was hanging after a match, but half their drive train was still moving. Couldn't replicate in the pits but we did fine some swarf near the Victor's PWM pins, and that Victor did power the problem drive motor.

[thatprogrammer]

Ok, this one is really weird.
So after the SFL regional (or at the regional, really) our shooter stopped holding position while getting ready to shoot, which would cause it to go up or down REALLY fast because of the force of the spinning shooter wheels (we have a U shaped shooter similar to 987). I couldn't figure out why this problem was happening as I was really busy with drive coaching at this event.
After World's (we didn't really look into this problem as we intended to do low goaling and defense at World's only), I looked over all of our code and found the issue: we had somehow deleted the lines of code that set the motor command to the output determined by our PID loop.
Now this is where is gets weird
By doing so, we actually ended up saving our robot... In that same code examination I realized that the other programmer, in an effort to make our code more concise, was now using the exact same variable for our shooter RPM goal and our angular Goal for the shooter. In other words, if we would have gone to position and then set the flywheels to our shooting speed, the goal (for BOTH!) would have been 3300 instead of the rpm's goal being 3330 and the angular goal being 80. If we had actually run the shooter like this, the shooter would have slammed down and ripped the robot's bellypan in half.
This mistake ended up being a good opportunity to teach others about testing code changes before deploying at least

[ctt956]

I have a few:

1. Joysticks only moving one side of a tank drivetrain very slightly. Joysticks were swapped, their ports were changed, and a controller was used in place of the joysticks, but only one side would twitch forward or reverse. I'm not sure what happened or how it was fixed, but I think it may have been a programming issue. This was probably the strangest I have seen so far.

2. Loss of comms when the battery was a bit low, but still ~11 volts. The robot would just freeze, then it would reconnect to the DS, and driving a bit would disconnect again. A full battery would fix it until that was discharged to the same level. The motors didn't seem weaker when this happened(mecanum drive), so not sure what caused it. That same RoboRIO was used in another robot, and it did the same thing once, but with new code, a full battery, and(I think) an OpenMesh radio. Strangely, it didn't happen again, even a few times when the battery dropped below 10 volts.

[Sperkowsky]

This year at the NYC regional we came in without much to do. The robot was in good working order after our week 0 and we did not have any planned upgrades. So, we got inspected quickly and proceeded to participate in some practice matches. After 2 practice matches we went to the pits and tried to shoot a boulder for a kid visiting our pit and well.... nothing worked. The robot would not inititialize and we kept getting weird errors. Nothing looked wrong anywhere and we had not changed anything since our last practice match. Turns out our programmer accidentally wrote a line of code (Not a programmer so sorry if I am saying this oddly) saying if the controller joysticks were not 0 to set all motor values to 0. He claims he never wrote the line but no one else would have. And... we will truly never know. My guess is we slightly damaged one of the joysticks so they were not completely 0ed and it broke everything....

4 hours of troubleshooting later
every CSA at the event later

We fixed it.

[NShep98]

On our 2015 robot, our driver would always complain the the left side of the robot would be slightly slower than the right. Throughout the entire season, we tried all different methods to track down the issue, and eventually came to live with it. At some point, a modification needed to me made that required taking of the entire left drive plate (a process far more difficult than it probably should have been) where we found that a nut had somehow gotten wedged in one of our wheels causing this https://drive.google.com/file/d/0B3d...5hRWE1Njg/view

If we had kept that up long enough we'd have been close to carving through the entire thing.

[jdunston94]

still not sure what happend during the auto of this match. ourselves,COMETS, (3357), Average Joes (3620) and Code Red Robotics (2771) all had been having near flawless auton routines. then this match things went wonkie. any thoughts? our code skipped over 2 fail safes in the process and Joes said after the match that there was no feasible way for that to have occurred in auto.. as you can see the rest of the match everyone was functioning perfect on our alliance.

http://www.thebluealliance.com/match/2016miken_qm64