While competing at SMR in week 2, we had three matches where we lost communications and stopped moving. The FIRST data did not indicate any field issues, so we have been working to identify what the issues could have been on the robot side. We found a few potential causes and have made some changes to address this. We are at BMR this weekend so we will know soon if this has been resolved.
We also consider ourselves “lucky”
that we lost communications in our last match. Prior to eliminations, we had made some other mechanical changes on the robot (cables, connectors, moved some protective lexan) and thought those changes had fixed our problem. After we stopped in the final match, we went back and did some more work.
We thought this information might help other teams that have connection issues.
We found we were running with nearly 100% CPU utilization and had high trip times and lost packets. To address this, we have disabled the video on the driver station dashboard and added a short wait period to the image processing. We also changed to not have the tracking system on until the operator turns on the shooter motors. Previously, tracking was enabled the entire match.
We are not sending the camera video to the Classmate. This is not needed by the operator since we have lights to indicate when we are on target.
We also borrowed a new Classmate (E11) from another team and found the performance was better than on our E09. We may choose to invest in a new laptop.
Thanks to FIRST FTA’s for some troubleshooting ideas that have helped us considerably.
I want to understand the physics. - Molten [more] 
Threaded Mode