Quote:
Originally Posted by Mark McLeod
As an addon to Marc's comments, all team programmers should get in the habit of checking their Driver Station log for each match when the robot comes back from the playing field.
It contains a wealth of information recorded 50 times a second for the entire match: - Communication packet trip time
- Lost packet count
- Robot battery voltage
- cRIO CPU utilization %
- Markers for lost comms (and most importantly, the duration of lost comms: ~25 sec = radio reboot, ~40 sec=cRIO reboot)
- When Auto/Teleop occurred
|
We competed in the Week 1 Palmetto Regional and by Friday afternoon the field staff were very busy diagnosing the networking problems that eventually resulted in the C++ update.
I rechecked our driver station logs yesterday and most matches were as expected, except for Q44 which showed quite spectacular activity with lost comms to the robot every couple of seconds. (We were not using the latest DS version so the packet loss/latency graph is missing.)
But this post isn't to complain about that match since both alliances were operating under the same conditions, and the probable cause was fixed during Week 1.
I just wanted to illustrate that we now have some excellent tools for teams to identify problems themselves.
It is easy to blame robot problems on "the field" but in my experience it is almost always a problem with the robot, and teams are now in a far better position to diagnose and solve those problems, perhaps with the help of a friendly CSA.
So a huge thank you for the DS logging tool.