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

[ASD20]

During one of our matches this year, we were the victim of a excessively hard autonomous. While our drivers caught the driver station, the lid on the laptop shut causing it to go to sleep. We ended up needing the FTA to bring over a spare driver station. After that we made sure that we disabled sleep mode on the driver station.

[Chris is me]

One team at one of our competitions had a very forceful appendage on a long swinging arm with a small point on the end, designed for drawbridge and stuff. It ended up swinging down directly onto the power cord of our radio, ripping the tape off and yanking it out. Fun.

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

[EDesbiens]

Originally Posted by 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.

I had that too... Though if I clean my code it's fine.

[teslalab2]

We had another programmer that knew labview and I told her she should let me try C++ and it fixed it. but yeah, Labview is the worst

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

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

[ceb515]

In the build season of 2015, I had an interesting issue. We were testing an idea for a 6 wheel mecannum drive. It worked at first and then another programmer wanted to add PID loops. Lets just say when the RIO rebooted it ran full speed over my laptop. To this day my trusty laptop has some of its battle scars. (The screen and trackpad needed to be replaced, the frame of the laptop remains with gouges out of the aluminium.)

[Nightwing430]

For 2015 we were testing out our Auto and something happened and our robot started spazzing out and kept spinning around in circles, this only happened once and we don't know what really happened. Also with the same robot, sometimes when the arm mechanism is closed it starts twitching so we called it "hugging" now everytime it starts to twitch everyone says that all the robot wants is a hug.

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

[SpoonMechanic]

That time the e-stop completely malfunctioned and a robot broke out in auto to terrify the front row. The robot uprising has begun.