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

[aristochaotic]

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

This can be either your robot or another team's, just the strangest issue you've ever seen. Bonus points if you tell us how it was solved.

[ASD20]

When we were working on our 2015 autonomous, our robot always seemed to go towards me, wherever I was standing, instead of going forward. We never really figured that one out.

[EricH]

Originally Posted by ASD20

When we were working on our 2015 autonomous, our robot always seemed to go towards me, wherever I was standing, instead of going forward. We never really figured that one out.

2016, SCRRF Spring Scrimmage. 4276 goes just about 100% on finding the portcullis in autonomous. They were aiming for the rock wall, which happened to be next to it. They did eventually get that mostly worked out... but it did crop up about once an event after that.


I've also heard of an E-stopped robot continuing to wander slowly across the field. (This was over 10 years ago.) Seems the batteries were surface charging, and the controller had enough voltage to drive the motors--slowly--but not enough to read an E-stop signal from the radio.

[Cothron Theiss]

Originally Posted by EricH

I've also heard of an E-stopped robot continuing to wander slowly across the field. (This was over 10 years ago.) Seems the batteries were surface charging, and the controller had enough voltage to drive the motors--slowly--but not enough to read an E-stop signal from the radio.

I would be somewhat terrified to see an E-stopped robot still moving across the field.


Just after our Rookie season, we were demo-ing our robot at the main office building of our biggest sponsor along with two other teams. We were outside, and for some reason, did not have the robot cart for the driver's to set the laptop on to drive. So one person was holding the driver's laptop while the driver held the joystick in one hand and drove with the other. As the driver was turning all the way in one direction, the person holding the laptop accidentally hit the power button, setting the laptop to sleep. For some reason, instead of disabling the robot or ceasing input, the robot locked into the last signal it had received from the driver: turning in place at full speed.
Soon, the force from the robot spinning flung the battery out of the robot and sent it sliding against the concrete.

So, as any group of high schoolers would do, we brushed the battery off and zip-tied it back in. But as soon as the driver re-enabled the Driver Station, the robot immediately went back into its death spin and flung the battery out in exactly the same fashion. To this day, we don't drive the robot unless the laptop is firmly secured onto the cart or the Driver's Table, just like at a competition.

[Chak]

We had an absolute encoder on an arm that would sometimes randomly read 180 degrees from where it actually is, causing the arm to ram down into the robot and stall the motor in an attempt to dig into the ground.

Our programmer solved it in software by ignoring the encoder value if it goes crazy.

[Ryan_Todd]

https://www.chiefdelphi.com/forums/s...d.php?t=145297
I'm not sure whether to laugh or cry about the fact that out of 11 years of FRC, the 2016 season takes the cake for strangest issue to date.

Anyways, here's the short summary:

"Sirius" got in the habit of randomly spinning up various motors to top speed... while disabled.

The issue affected PWM and CAN-driven motors alike, and even happened several times while connected to the FMS. Since this kind of problem is pretty much the very definition of an "unsafe condition," we were disqualified from play for several qualifying matches in a row.

Re-seating the wires in question didn't appear to have any effect, and re-flashing the code didn't help either. Running low on options, we resorted to completely reformatting the RoboRIO; after that, we were no longer able to reproduce the unsafe behavior. The FTA eventually let us back onto the field, with the understanding that we would need to swap to a loaner RoboRIO if the problem ever happened again.

For my part, I was never completely satisfied with the hand-waving explanation of "something must have gotten corrupted;" seeing as the problem never recurred, however, all we've got left is hearsay.

[SenorZ]

Originally Posted by EricH

2016, SCRRF Spring Scrimmage. 4276 goes just about 100% on finding the portcullis in autonomous. They were aiming for the rock wall, which happened to be next to it.

We were going for audience reaction... I swear.

2011, Logomotion, my rookie year (mentor), and we could NOT get our robot to stand still during auto. We were using LabView, and even put a motor->off block into the auto code and it still would wander. We only attended one event that year, so for 9 matches we drifted during auto. Only once did that interfere with an alliance partner.

[EricH]

Originally Posted by SenorZ

We were going for audience reaction... I swear.

At least you won't have to worry about that at Beach Blitz.


I've seen some magic smoke from robots this year, but the one that had me wondering was the rookie team who smoked their intake's BAG motor. Fortunately, a quick fix by replacing the motor... but smoking a BAG, used in its (at least generally) designed use? Takes talent.

[Aaron.Graeve]

Not a robot problem, but I think it's still interesting.

Lone Star this year (I was FTAA). One robot refused to connect to the Driver Station, and the Driver Station refused to connect to FMS. As it was practice day, we were willing to take extra time and figure out what the issue was.

The first time this team come up to play, they had an odd configuration issue on the Driver Station laptop which seemed to preclude connection to the FMS. We sent CSA's with them after the match to help them do a clean install of the Driver Station on a new laptop and thought that was the end of it.

The second time they came to play, the same issue occurred on the new laptop (lack of FMS connection to the DS). Curious what the the issue was, we tried using one of the Spare Parts Classmates as the Driver Station as those are basically bare-bones installs and should always work. No dice. That Classmate worked fine as the DS for the two alliance members, but failed horribly for that team.

Fast forward 30 minutes, still no progress. We have re-run FMS pre-start at least 4 times; the 5 other robots come up fine, but this Driver Station and robot refuse to budge. The team is understandably panicking that they may not be able to compete at all. As a shot in the dark, I turn to the FTA and ask if the Field could be getting a 10.41.*.* IP address from the convention center. As it turns out, the field was getting a 10.41.255.* address with a subnet that conflicted with the 10.41.55.* addresses that the team needed to use.

5 minutes later, the problem is resolved and both of the teams laptops are working fine. The Field exterior IP address is usually checked during setup day for possible conflicts, but must have been missed for some reason. The team was extremely grateful for the resolution and was patient and helpful the entire time.

TL;DR: A 1 in ~650,000 chance that the FMS wants your IP as its IP.

[Ian Curtis]

Originally Posted by EricH

2016, SCRRF Spring Scrimmage. 4276 goes just about 100% on finding the portcullis in autonomous. They were aiming for the rock wall, which happened to be next to it. They did eventually get that mostly worked out... but it did crop up about once an event after that.


I've also heard of an E-stopped robot continuing to wander slowly across the field. (This was over 10 years ago.) Seems the batteries were surface charging, and the controller had enough voltage to drive the motors--slowly--but not enough to read an E-stop signal from the radio.

In the original firmware for the 2007 modem there was a bug that could cause robots to "hold last value" and not see the E-Stop. We had modified the AM Shifters of the time to include a 3rd higher gear, and were testing them out on the shop floor of the vocational school we worked in. We had noticed some weird behavior, but we were just playing around and most of the driving was being done by students without much practice so we kept playing around.

There was a nice long straight away, with the auto workshop at the far end. We were zooming down the straight away when the driver noticed the robot wasn't responding... he hit the E-Stop about halfway down the straightaway, and the robot didn't stop. It continued until the top of the electronics board collided with the undercarriage of a truck in the auto workshop a few seconds later. The universe definitely conspired against us on this one, as the Victors on the electronics board were exactly at the right height to be "the impact zone", and since it was our prototyping electronics board we had 10 Victors on that board -- all of which were destroyed.

[Conor Ryan]

Does anyone remember the story of Harlem_Shake.vi?

[dmelcer9]

So last year, our lifting mechanism for the totes kept twitching up and down. This would happen whenever the bot was enabled, even when the controller wasn't connected. We calibrated the motor controller, but that didn't fix it. We went through the lifter code line by line and there was nothing there that could have caused the twitching. To this day, we still don't know what caused the twitching, but it doesn't matter because we cannibalized the control system for our 2016 bot .

[GeeTwo]

Originally Posted by Conor Ryan

Does anyone remember the story of Harlem_Shake.vi?

Not when it happened, but I have read about it through highlight posts. Two words: Price Less.

[mman1506]

We've semi consistently had issues with motors "jerking" while the robot disabled with no one touching the driver station. I've been told it's impossible but it has happened multiple times on multiple robots.

[frcguy]

On the day before stop build, our RoboRio started acting up at a scrimmage. We had an intermittent loss of our USB camera, but the rest of the robot worked fine. We reflashed the RoboRio, and that appeared to solve the issue, and we bagged the robot the next day. Flash forward to SVR. We've just been selected for the playoffs, and the camera starts acting up again. We try frantically to reflash the RoboRio but to no avail. We keep getting errors. Somehow, right before we are set to queue before our first playoff match, the issue resolves itself. We didn't think much of it and were just happy the camera was working, and the robot went back in the bag for Champs. At Champs, the same issue started again, although this time we were too nervous to attempt flashing the RoboRio. Some matches the camera worked, some matches it didn't. We finally have two CSAs come over during lunch on Friday. They take a look, and confirm our worst fear: there is an intermittent short in the 5V rail on the RoboRio, causing the camera to work sometimes and then mysteriously fail. Cue us staying through lunch and taking the rear of the robot completely apart to replace the RoboRio. Luckily once the new one was in there was no further problems. The cause of the short turned out to be metal shavings from the build season finding their way into the USB port.

Lesson learned: Either use a vacuum or be REALLY careful when drilling near electronics.