Take an exit with dignity

[Zach Purser]

Let me go ahead and show my ignorance here. I haven't been part of programming the robot since FIRST switched to the current controller, but aren't there any watchdog timers to prevent you from getting stuck in automode?

[Radical Pi]

Originally Posted by Zach Purser

Let me go ahead and show my ignorance here. I haven't been part of programming the robot since FIRST switched to the current controller, but aren't there any watchdog timers to prevent you from getting stuck in automode?

Nope, none at all. The SimpleRobot template for code simply is call Autonomous(), wait for field to signal end of autonomous, run Teleop(), wait for field to signal end of teleop.

[Greg McKaskle]

I was assisting at the Dallas regional, and would follow nonmoving robots back to the pits to help resolve the problem. We saw a small number of issues that explained the failures.

The most common issue was loose power connectors. Robots that disable for ~15 secs, then continue had the cRIO reboot -- wiggle the connectors at cRIO and at PD to find which is loose. If the robot is disabled for 30 to 40 secs, check power to the bridge. Also, bridge only power issues don't affect RSL. If it was 40 secs and RSL goes out, check battery connectors.

Clearly, a cRIO reboot that isn't explained by a loose connector can also be a code issue especially if running C/C++.

If the reboots are due to a weak battery, the RSL tends to be dim. Clearly the DS should help identify this as well.

Another issue, harder to diagnose from the stands is the Security button on the bridge. If the bridge can move and an impact can cause the lock button on the front to be pushed, the robot will not move for the remainder of the match, and the Security LED will be blinking green or amber at about 3Hz on the bridge after the match. It blinks green for about two min, then amber for several more minutes.

One well built robot had the bridge security button pushed several times. Testing the bridge outside of the robot, it seemed that the board moved within the case, possibly due to their good job of hard hit testing before ship. Replacing the bridge resolved their issue.

-------

DS setup:
Do not plug Cypress board into an external hub, plug it directly into the laptop port. This may cause the Cypress to stop working, but it may cause the entire hub to drop out. This is often corrected, for awhile, by unplugging and replugging. Hit F1 if the match has already begun.

To test the Cypress board, press the button. If one red LED lights up in response, the board has not been recognized. If zero LEDs light up, everything is fine. This should match the state of the LED on the DS I/O tab.

To test joysticks, click a button and see if the LED on the Diagnostics tab turns blue, or if the listbox line turns blue on the setup page. When disabled, the DS scans for joysticks once per second. This is too expensive during a match, but F1 will force a rescan if connections are changed during a match.

-------

I'm not posting this here to declare that the field or FMS never has issues, but in my investigations, the issue was explained by one of the above. Hopefully this will help with troubleshooting.

Greg McKaskle

[Radical Pi]

Originally Posted by Don Rotolo

Somehow, the actual cause needs to be identified, we can't just chalk it up to some random event.

Unfortunately, I doubt any major debugging will be done until the offseason. At the moment, probably all of the official fields are flying around the country to be used at the various regionals. The people who wrote the FMS and know exactly how it works are probably working as hard as they can to find the problems, but until some correlation is found between the various field issues they probably can't do much to fix it. It's not like they can run down to a regional and install a "debug FMS" to monitor every little thing that is happening. It would totally disrupt the matches.

I highly doubt that there is more than one major issue with the field. From what I've seen and heard, the non team-caused failures seem to have some sort of domino effect, causing other robots to fail somehow. Perhaps there is one little bug with something a team does on their robot, and it cascades across the field to other robots.

I think it might actually be a good idea if the beta teams could get together and play on an early build of the new FMS for the season. The entire point of a beta is to figure out how to break a system so it can be fixed, and the beta would provide a perfect opportunity for this. You get to try out new features, have the resources of teams who are pretty much writing the documentation on the system and know what works and what doesn't, all trying to "break the field". It's a perfect chance

[PAR_WIG1350]

The FMS is not flawed; it just has surprise features


I hope luck is on our side in Boston and Atlanta.