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

[Mr.Twister]

One of our drive team's accidentally flipped the robot crossing the drawbridge. During the match, one of our fellow alliance members tried flipping us back over. Well, that team ended up cracking our shooter's lexan completely in half. What can fix anything?.... DUCT TAPE! This surprisingly got us through 2 more competitions, including the MARC, an off season competition. The robot still works fine !

[Jon Stratis]

Well, this doesn't have to do with a FIRST robot, but it was certainly a strange issue... and the robot it was with was indirectly responsible for me becoming a mentor .

Back in college, I took an autonomous robotics class. Basically, create a robot from Legos, motors, sensors, and a provided logic board to play a game involving searching for brightly colored plastic eggs and returning them to a nest. Got quite a ways into development of our robot, and were testing it out in the lab, along with several other groups.

Anyways, our robot was having some sort of programming issues... it was seemingly randomly going off-script and acting in ways that weren't actually possible according to static analysis of the code. We started adding in some print statements (there was a small display on the logic board allowing maybe a dozen characters to be displayed at a time). As we added more and more print statements to see what it was thinking, the behavior got worse and worse - literally the only changes were some print statements, yet it was going off-script faster and faster as we tested.

After a few days, we found out this was a bug with the display buffer on the logic board that the professor never bothered to tell anyone about - something about the way it worked behind the scenes caused the memory on the board to get corrupted if you tried to display an odd-length message. So with each print statement we added, there was a 50% chance it would corrupt the memory (as the message could have either an odd or even number of characters). We went through and "even-padded" every print statement (including the one that originally caused the problem) and the robot worked perfectly without any other modifications.

[Koko Ed]

During out third match at FLR our robot switched out of the autonomous mode it was set in to another one which caused our robot to drive up onto to Portcullis and flip over instead of lifting open the Portcullis and driving through like it was supposed to.

[Chris Mounts]

We had two very strange things happen this year. One was solved, one was not.

In one match at FIM Southfield our robot took off at full speed in reverse just before the start of the match. It seems to have happened at the exact moment it connected to the field. It never happened again and we have no idea why it happened.

At our second event in Livonia. Twice we suffered a complete reboot of the robot just after we cleared under the low bar. We spent hours going over every inch of our robot trying to find some sort of short. Then it happened a third time. This time we got lucky our press person was right next to it and saw what happened.

The polycarb sides on the field were not installed correctly. There was a small gap which allowed the side plate on the arm to get caught. The side plate for the arm was sloped and driving forward pushed the bot into the ground. This meant we could not free spin our wheels and would overload our drive motors going into full brownout.

[TogetherSword8]

Our 2014 bot was a plunger shooter (single cocked back PVC tube with a plate on the end tensioned with elastic tubing) and we had some difficulties over the year stopping it, and the plate that was in charge of that duty broke multiple times, and a few resulted in the rest of the mechanism following the ball. There is nothing like shooting your ball at the goal, seeing it fly true, and seeing part of your robot right behind it.

[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

[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...

[ShinyShips]

Originally Posted by ollien

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

It may have been loose cables, but that was the first thing I checked when we got back to the pit. They all seemed fine. When we asked the FTA if he had any idea what happened, he didn't know. Better safe than sorry, really no harm in putting in a fresh rio after a season of 120+ matches.

[Connor McBride]

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.

YOU'RE WELCOME!!!

[teslalab2]

We ended up switching to C++ because in 2014 we were running labview, and its CPU would randomly max out then the robot would crash and you would have to cycle the power.