[Greg McKaskle]

If you post the log files or images of them I can help look at them.

Responsive driving requires that all elements of the communication chain are not introducing lag. Conversely, if you have lag, any element of the chain could be causing it, and it is generally not easy to identify which link is the issue.

The chain starts at the DS. The DS reads the joysticks and sends their value out to the robot. If the drive computer has high CPU, it can introduce some jitter or lag into the control packet timing.

The next link depends on the venue. It can be a cable, or a managed switch, or wireless. But skipping a few robust elements that you generally don't control anyway, the next link is the DLink, then the robot.

On the robot, your code needs to process the packet, respond, update drive motors, and produce a status packet.

If the Robot CPU usage is high, it can introduce lag between when it reads the joystick and when it responds. Even if the CPU usage isn't high, if the user code doesn't utilize a packet due to a delay in its code, it feels like lag. Sleep statements are generally the cause of this form of lag.

Back to those elements we generally don't control. We can't control, but we do influence them, and that is where the camera settings and other network usage come into play. The system this year implements QOS and bandwidth limiting. My explanation for this is that the communication on the field travels in lanes, like on a highway. Each robot has a couple lanes it can use for traffic to and from the robot. Your robot can no longer use the lanes of other robots. QOS is a bit like an HOV lane, or a flashy light that tells other traffic to get out of the way -- perishable cargo. If you put too many cars or trucks on the road, you cause your own traffic jam. QOS does a pretty amazing job of keeping the drive code from lagging. But flashy lights only go so far, and we aren't on the autobahn anymore.

Greg McKaskle