[Gary Dillard]

Quoting a few posts from another thread, so we can get a specific discussion on what and why this happened. Here's my post:

Originally Posted by Gary Dillard

Our robot just did the circle dance for no reason. We tested code before the match and no problems. It started when autonomous started, then continued in teleop so we killed it. After long discussion with FTA about this thread, we powered down and went to the pits. When we started up in the pits it did the same thing. We checked grounds and vacuumed out the robot, no change. We redeployed the same code and then it worked fine. We had Rick Foley check the code and it all looks fine. Hmmmmmm....

Also:

Originally Posted by Greg McKaskle

I assisted a team in Lubbock after a similar issue. It happened at the end of Th and we didn't find it. It happened again on Fri and we saw that most of the motor controller weren't receiving a signal when code was enabled. We discovered that the ribbon cable was no longer zip tied down. It was lifted on one side, so some connections were present, some weren't.

I've also seen this when a limit jumper "fell off" of a jaguar. Without the jumper, the motor will not run in one direction.

If you haven't done it already, check the basics, verify both the code, the electrical, and the mechanical. Could a bad sensor value cause this? Gyro's are finicky if not calibrated when the robot is stationary.

I'll be happy to help interpret the log file if you want to PM me.

Greg McKaskle

Originally Posted by DominickC

Being the programmer last year, and the one on disaster control at the time of the incident at the WPI Regional last year, I can speak in greater detail to the issues we experienced.

It was round 3 of the quarterfinals. Only mild issues with initial FMS connection were experienced at any point prior to the issue. Auton executed as expected. When transitioning from Auton Disabled to Teleop Enabled, the robot began spinning in a tight circle, and was not responding to any driver commands.

Later inspection from the FTA, CSA, as well as a National Instruments rep yielded no result. The code was ruled out as a non-issue.

EDIT - We later attempted to replicate the failure using FMS simulation software provided to us by the CSA. All attempts at replication failed.

Originally Posted by animenerdjohn

16 and ourselves had a buggy match at Lubbock.....where we both sort of spun after losing connection. A few times titanium was spinning in auto in Elims as well...

From what I've seen this is sort of a popular failure...why I wonder do all the robots react like that?

Originally Posted by Team23pitboss

To fill in the blanks about what exactly happened to us last season, it was the third elimination round of the quarter finals, autonomous had just ended when suddenly the robot began to spin wildly in circles and continued to do so until the end of the round, eliminating us from the competition. The team was incredibly distraught and was disappointed to have lost due to something so completely out of our control.

My panicking was meant to be taken with a grain of salt and was extremely sarcastic, hence the memes and star trek GIF. However, my questions about the integrity of the FMS last season (and possibly this season) is quite serious. While I make no claims to be able to diagnose an FMS failure over the web I can say with a high degree of certainty that our failure at WPI last year was not based on a fault in our code. We functioned normally for the entirety of the competition and had not experienced any previous failures. The FTA's at the event looked over our watchdog logs and our robot code at length and were incredibly helpful in trying to deduce what had caused our problem. They agreed with us that it was not an error in our code and even tried to get us a rematch to no avail. We have tried on multiple occasions to replicate our spinning on the field and have been unable to do so.

I trust enough in the folks behind FIRST to believe that the FMS will be a non-issue but our experiences last year will never be too far from my mind.

A few more details for our situation: We program in Labview, our drive motors run off of the sidecar in ports 1-4 using talons, but there is no drive code in autonomous. We're still trying to get the video to confirm a few things, but we're pretty sure we were spinning counter clockwise; we don't know if the conveyor or shooter motors were running also. It would seem that the motor controllers must have been getting sent a constant PWM value of zero to make them circle counterclockwise; when we check the video hopefully we can see if all the motors had the same problem. I stated that we checked the code and then went to the field; I can't say for absolute certainty that we didn't deploy something after our last test but I don't think so, I don't think we had time. One theory is that we did deploy new code but it didn't load correctly and so the cRIO automatically sent zero variable values, which then got corrected when we redeployed later. Has anyone ever had that happen, or is it even possible? Is there any way that losing connection or reduced bandwidth would cause variable values to go to zero? The FMS and out display showed that we stayed connected. I'm hoping we can find a common problem so that teams can test for it in the future.