Connections at SMR - and Some Corrective Actions

[Chris Fultz]

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.

[BigJ]

1675 Had this same problem at Pittsburgh, using a netbook similar to this http://us.toshiba.com/computers/lapt.../NB505-N508GN/

We were only streaming video to SmartDashboard, and we would get the odd 5-second lag even when the camera was set to the lowest resolution and highest compression. Hopefully we will have camera tracking by week 4 for Milwaukee so this won't be an issue!

[Al Skierkiewicz]

Chris,
I was talking to the NI rep in Duluth and you can adjust the resolution and frame rate of the camera to help keep the overload down. This is a very common problem with vision systems this year.

[Bharat Nain]

You should also check for errors or inifinite loops in your code that could be consuming resources other than the camera. At Orlando, the robot stood idle for parts of the match because the robot task crashed as soon as the cRio turned on while the driver station indicated that communications and robot code was fine. Reducing the camera's frame rate and resolution may also help.

Since FIRST no longer requires teams to use the classmates, I'd suggest buying a laptop with a little more juice in them (better processor, RAM and battery) as they are far more suitable for a competition environment than the classmates. Make sure they are rugged enough!