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

[cbale2000]

Back in 2009 when the new cRio control system had just come out, we were experimenting with it on one of our older robots to test out the new control system. This was back before Watchdog was a thing (or at least a thing that worked), so momentary signal losses would cause strange behaviors with robots. Consequently, our first attempt to drive the robot with the new system resulted in said bot driving full speed across our practice field and slamming into the cinder-block wall of the building.

Ironically, the robot was fine, the wall got a nice hole in it though (which is still there to this day).

[Conor Ryan]

I was working a field at Buckeye for Aerial Assist. The giant ball comes flying across the field, 303 driver makes an amazing manuver to get the catch. Ball lands squarely on the off switch. Robot shut down instantly.

[Mikey Richards]

Our issue was one that made absolutely no sense. Whenever our robot went under the low bar in autonomous while on the red alliance in Philomath, it would brownout for 60 seconds and completely take another robot on our alliance offline. This happened three times in a row. After that, they spent half an hour rebooting the field and it started working fine. Still don't know what happened

https://youtu.be/apulBWRFrQ4

[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

[Briansmithtown]

In 2014, before this demo started, we were testing our robot to make sure everything worked fine. We were in a packed common area, and all of the sudden, the robot went in circles. E-stop didnt stop it. I ran and literally stopped it with all my force and hit the breaker off... This is why digital sidecars and metal shavings do NOT go out with each other.

[EDesbiens]

We were training drivers using the robot during the 2015 season and the robot kept getting a super high ping when it got fast enough... Every single time. And every time this happened, it was stuck in a state where it would turn the exact way to aim for a garbage bin and ram it. We broke a lot of bins that day. We figured out that the ping was simply due to an overloaded code but we didn't get why it was triggered with speed.

[ShinyShips]

At BattleCry@WPI this year we were in the finals (Thanks 166!) against 195, 2791, and 501. Finals match 2, everything was fine until about 30 seconds into the match when we drove over the rock wall. Comms and robot code dropped, comms came back, but we were stuck without robot code for the rest of the match which sadly led to our defeat. RSL was solid I believe. After the match, we checked our 5v rail and it was fine and once we power cycled the problem was resolved.

Needless to say, we replaced our rio for IRI.

[ollien]

Originally Posted by ShinyShips

At BattleCry@WPI this year we were in the finals (Thanks 166!) against 195, 2791, and 501. Finals match 2, everything was fine until about 30 seconds into the match when we drove over the rock wall. Comms and robot code dropped, comms came back, but we were stuck without robot code for the rest of the match which sadly led to our defeat. RSL was solid I believe. After the match, we checked our 5v rail and it was fine and once we power cycled the problem was resolved.

Needless to say, we replaced our rio for IRI.

Sounds like a combination of loose power cables on the Rio and on the radio. Seems a bit excessive to replace the Rio...