How to determine root cause of robot dropping from Teleop to Disabled during match.

[MrRoboSteve]

http://wpilib.screenstepslive.com/s/...og-file-viewer

The log has a great plot that should help visualize your problem

I would be looking closely at radio placement, and would consider having a fresh radio at your next regional to substitute in. Review logs from your other matches and see if there are signs of connectivity issues.

In general terms, connectivity issues in one robot won't cause a replay. If the FTA isn't busy during practice day at your next regional, I suspect they'd be happy to show you the field monitor and discuss how replay decisions get made.

[tr6scott]

Thanks for the help so far.

Just a couple quick answers, we are using a 2014 classmate as the driver station, the power options have been disabled, the firewall has been turned off.

This classmate sole purpose is this years driver station, but I had found some instances in the past where Spoitfy was loaded... I had a discussion about the importance of this box remaining pristine, but like I said, I was not there this weekend.

As to code issues bogging down the roborio, we log the "loop time" of the 20ms timed task loop where our control loops run, and you can see from the data, that the loop time is consistent. This has been a great indicator of code issues, and we have learned if that data is not right to figure out the problem, and fix it.

I have worked with the FTA at the event, over the last two years I have FTAA on a couple FTC events with him. Just don't know the FRC FMS.

[Greg McKaskle]

Watching the RSL pattern in the video, and looking at column B of your logs, it looks like the first period where your outputs were disabled was 11 seconds, and the second was 2.3 seconds. The log file on the DS will have some messages indicating whether the DS lost comms with the field, with the radio and robot, or just the robot. It also contains messages every few seconds showing the laptop CPU usage, roboRIO CPU usage, and lots of other stuff. Please post the file or contact me and I'll give you email instructions and I'll be happy to help you identify the issue.

Also, it looks like they started working about the time the FTA made it to their station. Does the drive team have an idea of what was done at the DS? Did they reconnect the ethernet cable? Did they reboot their code?

Greg McKaskle

[Tom Line]

Originally Posted by tr6scott

At West Michigan.
Match SemiFinal 2
Video of match: https://www.youtube.com/watch?v=ib3zz6QXHbc
Robot in question is 2137 TORC, bottom right hand corner.

We experienced two "field disconnects" in this match, the first one lasted about a second, and the second one lasted about 3/10ths of a second.

This data comes from our logging on the roborio on the bot. Our logging completed on the bot, is only done during autonomous and teleop, so when we dropped to the disabled state, we didn't log data, but I can tell this based on the gaps in the data time stamp. These events are highlighted yellow in the attached robot log file.

I am the lead electrical and programming mentor, but was not at the event. I am doing a postmortem trying to determine the root cause. The team was told by the FTA that the issue was not with the field, and there no basis for a replay. TORC bounced back from this anomaly, and the alliance was able to capture the blue banner.

Based on our log data, I know the roboRio did not lose power or reset. From the length of time of the glitch, only being a second, that the robot radio probably was not the cause, as that is a typical 30 second reboot. Also, the robot worked fine after the comms were re-established, but our elevator carriage had been sprung from the frame, rendering it useless. In the video, you can see the drivers and FTA moving the driver station around, and the robot springing back to life. You can also see the stack light go from solid red, to flashing red, back to solid red.

We should have driver station logs available on Tuesday, when we unpack, so one of the questions is what should I be looking for in the driver station logs for this match? I have not done much with the driver station logs, as we typically try to log what is important to us on the bot itself. Can you point me to a doc that describes driver station log files, and how to read the data?

A couple other questions for my general knowledge, what determines if who is at fault on a FRC field, when a glitch occurs?
What data determines this, and do we have access to this?

Just a general comment about the field at West Michigan. There seemed to be many delays, much more than any of the other fields in Michigan, along with more replays on the West Michigan field than the other two. Just an observation as I watched the other two webcasts play finals, while we were trying to finish quarter finals.

Thanks for any help.

I'm sure you noticed that one of the quarterfinal matches was replayed. It was replayed because all 3 robots on our alliance lost communication with FMS for between 6 and 10 seconds, at the same time. This caused team 226's arm to reset and become unusable for the remainder of the match. I verified the issue by pulling the driver station logs for both teams after the match and comparing the times - both sync up perfectly with the loss of communication. I didn't dig into it any further than that at the time, because the FTA had been informed of the issue and was working hard with FIRST to determine what should happen.

If you can get in touch with your alliance partners and get their logs, you may find a correlation in communication events. There seemed to be a number of gremlins, including the 'you most close and reopen the driver station' between each match or FMS can't see you.

[tr6scott]

Tom,

Many gremlins, and anomalies with that field that weekend. On the webcast they said it was a complete "power loss" on your side of the field and that was why the replay was granted.

One of the things that concerns me, is what is the determining factors between the decision to replay your match, and not replay our match. As that decision, could have been a deciding factor on who moved on. Another glitch in one of our other matches would have knocked us out for sure. As it happened, our elevator self destructed due to being disabled and re-enabled too, and that almost knocked us out with a single event.

From our logs, I understand what our robot did, and there are code fixes we can make so that we don't react the way we did when being disabled, and re-enabled. It was kind of a perfect storm scenario, where the elevator was being jogged manually when we lost comms, and when re-established, the pid was reset and sending it to lowest position, those events made us try to rip the elevator when we jammed the container in our arm.. This failure mode was not something I have seen in the past, but I now know to test for this scenario.