Quote:
Originally Posted by Greg McKaskle
As for the FMS interaction, the FMS whitepaper goes into more detail, but the FMS never directly communicates with the robot. Your robot has great comms the entirety of each match, I do not see any indication the robot was ever disabled except by the safety mechanism. Also, the tracing code, which produces one of the blue traces at the top of the Log file viewer indicates that the teleop packets were still being processed and wherever that trace call is in your code was still being called at 20ms intervals. You can zoom in and see that those traces are in fact many small dots, each indicating what packet was sent and which code traces were executed in response.
Greg McKaskle
|
Thanks for the detailed and careful analysis. Your conclusions match mine. Occam's razor would suggest that our main loop code either crashes or hangs up at the failure mark of those two logs.
However, we could not reproduce this unless we were on the field. It may be the elements, it may be the subtly additional latency introduced by FMS; we really can't figure it out.
A 525 mentor told me that they ripped out all of the network table and smart dashboard code they had on their C++ 'bot, because they experienced similar problems in Duluth. And, nicely, after we removed all of that code, we had no such issues today.
Steve Peterson has graciously offered to review our code and see if they can reproduce the issue at a less stressful time. And I have to say the field guys were very helpful and supportive. As a rookie mentor, I couldn't have been happier with their response to our woes.
Sadly, we spent today ironing out the other problems that would have been nice to find yesterday, but hopefully tomorrow will be an even better day, and we'll get to play in elims :-)
Cheers,
Jeremy