Quote:
Originally Posted by bvisness
A team alumnus of ours referred us to that same bug report yesterday. We tried reproducing the error by temporarily disconnecting the robot, but weren't able to trigger the issue. It seems to strike at random, usually when I'm not paying attention. We're going to try cutting down on our NetworkTables usage and see if that helps.
|
I'm pretty confident that the problem you're having is the problem I reported in the bug report. In particular, the fact that the robot came back after 8 minutes, indicates that it was hanging waiting for the network write to timeout.
Reproducing the error is easy if you replicate the exact circumstances in which the bug occurs. Two things have to happen:
- Your robot has to write to NetworkTables via PutNumber, etc for it to freeze. If no write attempt occurs, no freeze occurs.
- A NetworkTables client (like SmartDashboard) must be actively receiving data from the robot, and then you must disconnect the client *without* sending a reset back to the robot. You cannot close the program as that will cause a reset to occur. Instead, you must disconnect the wireless/ethernet cable. Sometimes after reconnecting the cable, the robot will start working again.
I've found that some wireless cards can induce this behavior more easily than others. For example, our driver station laptop causes this to happen very easily, whereas I find it difficult to randomly get this to happen on my work laptop. I theorize that wireless interference can cause the connection to drop randomly, but vxWorks doesn't always pick up on it and it hangs.
The freeze is caused by the send buffer filling on vxworks for the network connection. So, if you send data less often, you will be less likely to run into this problem -- but the potential for a freeze is still there.