Chief Delphi - COMM lost way to many times

As a CSA, the most common category of comms failures are power related. It stinks for a robot to lose power or reboot in a match, but if I'm able to show them the cause of the failure and discuss solutions, I consider that a good outcome. My favorite is when I narrow it down and the students actually find the issue and identify a solution. Many of these are simply loose nuts on the battery or breaker, -- sometimes the PDP. Sometimes it is a bad crimp on the same connections. Loose fuses on the PDP are another source of failure.

I have less familiarity with it, but I have occasionally recommended replacing the circuit breaker/switch because it seemed like the softest touch would cause a loss of power.

I have not seen that many issues with radio power, but I'm certainly not a fan of the barrel connectors and generally encourage some form of positive retention, at least a strip of electrical tape stretched front to back across the jack. In previous years, it was quite common to see a bad DLink at an event. Whether this was damaged through mechanical shock or vibration, static discharge, or was bad from the factory wasn't ever clear, but some DLinks simply had high loss that went away with a radio change. I have yet to see that with OpenMesh.

I would really like to see the OP logs. The cursors, messages, and timings give very good evidence of what happened on the robot. When the disconnect happens, several things take place. The DS starts to ping each element in the chain to identify what it can still see, and the roboRIO, if it is still up, will also ping the radio from its side and post-inject messages into the log.

Key things to look for:
If the comms disconnect is only a few seconds long, I generally find that the ethernet cable was not snapped in or wiggling/tugging will cause link lights to go out.

If the roboRIO reboots but the radio is still up, the FTA can easily see this and will often tell the CSA or team. The second tab of the DS also shows the ping status of each device. Also, the results of the pings are printed to the log file as messages. As the robot comes back up you will also see a code start message.

If the radio reboots and not the roboRIO, there will be a green vertical cursor between the orange and yellow ones. Hovering over pretty much anything on the graph displays a descriptor in the lower left. The green cursors are the roboRIO telling the DS when it saw what radio go away and return. This is also in the event messages.

If the radio went out and there is no green cursor and no code start message, both devices lost power.

If the code restarts and the outage is five to ten seconds, it is more likely a code crash and restart rather than a power issue. This also looks different because the radio and roboRIO are still present and the CPU trace will sometimes help indicate the type of crash.

I hope to be able to make the log or even DS make a diagnosis to categorize the issues, but it just hasn't happened yet. As for logging while the robot sits still. Some teams do this, and it is a fine thing to do with your team. I'm pretty comfortable with the diagnostic capabilities of the existing log files and I'm not sure that RIO logs will actually be that much more effective at diagnosing problems.

Several times as CSA, I've intended to keep details about each failure and keep stats of what was found. But it quickly becomes more important to help teams than to keep count. And some teams don't ask for help and you don't find out until second-day afternoon that they have had multiple issues and you were not at the field to observe them.

Greg McKaskle