Driver Station Lag

[daniel_dsouza]

Hello CD,

Throughout the 2012 season, our control system has been plagued with lag issues. The first thing we tried was kicking everything except for the cRIO, the E09 classmate running the driver station, and one programming laptop off the network. We were running the the d-link in bridge mode, and connecting it to a separate router. Our lag remained >20ms.

The second thing we tried was using the d-link as an access point. (We never used auto mode) We thought that eliminating the aforementioned router would decrease lag times. However, the lag times jumped off the charts. When we pinged the access point using the classmate, the lag was >1500ms, often loosing 75% of the packets. Interestingly enough, our programming laptop could ping the access point with <10 ms. This lead us to believe that the problem was with the E09 classmate running the driver station. Efforts to use an external USB wireless adapter were in vain.

Both scenarios left our robot undrivable. Am I correct with my diagnosis of the problem, or is it something else? What do you recommend we do?

Thanks,
Daniel D.

PS. I already read this thread http://www.chiefdelphi.com/forums/sh...d.php?t=100717

[daniel_dsouza]

Well, our team fixed the problem.

Props to Alex Slaughter, who stomped on that lag issue.

The issue was that two devices were on the same IP, and the router needed to take some time to sort out the information. The driver station classmate wasn't the root cause of the problem...

We also upgraded our firmware. Here is the link

In addition, we also set the router to bridge mode, and connected it to the linksys router we had around from previous years. I am not sure how this part helped though.

[DavidGitz]

Originally Posted by daniel_dsouza

In addition, we also set the router to bridge mode, and connected it to the linksys router we had around from previous years. I am not sure how this part helped though.

This should not affect anything. Another common cause of lag is the camera not being connected and the camera code not being disabled. IP conflicts are bad. When you run the Driver Station on your laptop it will set the IP address to 10.xx.yy.9 The other IP addresses on the network are:
10.xx.yy.1
10.xx.yy.2
10.xx.yy.11 (If using the camera connected to your dlink)
From what I've seen, the 10.xx.yy.6 is no longer used and 10.xx.yy.4 hasn't been used in a few years. Any other address on your network should cause a conflict. Sinc we normally have several development computers attached to either of our robot's networks we designate a specific address for each computer to avoid this issue. If one of these computers becomes the Driver Station it will go to .9 and then when back in development mode it will go to it's pre-assigned address.

[Alan Anderson]

Originally Posted by DavidGitz

IP conflicts are bad.

Indeed. Someone powered up the Classmate yesterday while I was doing development on a different machine. The moment it connected to the robot's wireless network it complained about the IP address already being in use -- which it was, because the Driver Station had configured the programming laptop to the .9 address as well. I immediately started getting approximately a second of communication lag between the DS and the robot. Shutting down the Classmate restored everything to normal.

[Mark McLeod]

Originally Posted by daniel_dsouza

In addition, we also set the router to bridge mode, and connected it to the linksys router we had around from previous years. I am not sure how this part helped though.

If you did see an improvement due to this, then it's possible the DLink in AP mode was conflicting with other wireless networks in the area.
Switching over to the older linksys router might have unintentionally put you on a different band/channel that avoided conflict with existing wireless networks.