The unplanned circle dance

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

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:

THE HORROR! THE HORROR!

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

THE HORROR! THE HORROR!

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.

THE HORROR! THE HORROR!

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?

THE HORROR! THE HORROR!

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 :ahh: panicking:ahh: 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.

[vinnie]

We had a problem with “phantom autonomous” at a scrimmage yesterday. In our case, it was because we did not reboot the robot after previously driving it, and since our robot was driving when it got disabled, the cRIO held the last PWM values and started sending them again as soon as it was enabled, even though there was no drive code in autonomous. We fixed our problem by sending a drive command of 0 during autonomous to make the motors stop.

[Racer26]

Oddly consistent error. Intriguing… I wonder if HQ is listening…

[Jefferson]

I still don’t know what caused our weirdness, but I’ll add a little to this discussion.
We have 4-wheel independent swerve drive. We were spinning in circles for a couple seconds while the driver let loose of the controls. This means that the PID loops for the moduals had to be functioning normally. This leads me to believe that the driver station data was not being sent or was delayed.

Remember also that there are a lot of different potential causes for what you are observing and people are reporting. These could all be unrelated occurances.

[Greg_McKaskle]

If the robot is normal in auto, but spins in teleop, it may be that the joysticks were not centered when they were plugged in or when the DS was opened. Modern joysticks have a great feature where they take their current setting as zero when the SW opens a connection. While this auto-trimming feature helps with old joysticks, it isn’t limited, and can result in a robot that drives itself when hands are off the joystick. The default dashboard may help diagnose, as it would show the value being sent to the motors and read from the joystick. To correct this in a match, you unplug the joystick, plug it in again, and hit the F1 key. This would present itself the entire match and wouldn’t just show up partway through.

A robot that spins during auto but not during tele may be due to a faulty sensor, sensor connection, or sensor calibration. Mess with robot reference point and oh how they spin. The sensor could also be used in tele, but since they often aren’t, …

Of course I’ve also seen plenty robots spin when a chain comes off, wheel gets a game object caught in it, etc. I am not claiming that this pertains to any of these cases, but numerous times, the team assumed field caused it until they actually inspected the robot. The PWM cable or digital breakout cable can cause similar symptoms.

Greg McKaskle

[Chris_Elston]

When this happens next time, take a look at your driver station. The driver station has a nice graphic imagine of what the Joystick inputs look like. There is a dot on the screen that is a virtual representation of the joystick position. We had a case where the joystick position in the driver station did not match the joystick real position which caused the robot to spin out of control. We thought it was a bad joystick so we replaced it. Later…I think what would have fixed it is the “F1” refresh key trick, to refresh the joysticks in the driver station. In the mean while we took no chances and swapped the joystick.