Dashboard joystick lag when not connected to robot

I’ve recently been experiencing an issue where the dashboard joystick indicator experiences up to 15 seconds of delay before displaying changes in values. The driverstation displays these changes instantly. When the driverstation is connected to the robot, there isn’t any delay. This issue happened on multiple joysticks, multiple laptops, and multiple dashboards - even with the default dashboard which comes with driverstation. Does anyone know of a way to prevent this from happening? It’s not a huge issue, because most of the time the robot is connected, but for prototyping joystick code at home the delay makes it almost unusable.

Do all the laptops have the same specs? We had this issue at times last year when we were connected to the robot. It was when the machine was running out of free memory or processing power (I forget which). There were times although few, that this applied to the robot as well. Killing processes and/ or rebooting solved the problem.

None of the laptops we tested on had equal specs - I also tested it on my personal desktop, and the same results occurred. It isn’t an issue in my code, because it happens with the default dashboard too. I also tested with multiple joysticks, and the problem still occurred. The only time it hasn’t happened was when the driverstation was connected to the robot.

It sounds like this isn’t the case, but can you test the inputs with another joystick testing program?

The joysticks are updated instantly in FRC driver station. The delay occurs in the dashboard.

I’ve been doing some debugging. It looks like the problem is in the WPI_DashboardRetrieveStatusInfo.vi which is in Loop 1 in the dashboard code. Here’s what I think is happening:
It is waiting on 2 UDP messages for 20 ms. 1 message is Control information (including the joystick buttons and axes) coming from the Driver Station and the other message is Status information (the “Robot Metrics” and “Status Info” output clusters) from the robot. Because these UDP messages are read in the same while loop, the timing between the UDP Read functions gets messed up. When the robot is not connected, the UDP Read from the robot will always wait 20 ms. This is a problem because it takes just a tiny bit extra time to do everything else in the loop so it ends up taking say 21 ms or something on average for 1 iteration of the loop to execute and the UDP messages from the driver station start getting buffered. The attached Sender Test.vi and Receiver Test.vi may help to make this clearer. Sender Test.vi just emulates the Driver Station and optionally the Robot.

Sender Test.vi (8.3 KB)
Reciever Test.vi (8.7 KB)

To fix this I have reduced the timeout value on the UDP Read VI that reads the Status information from the robot from 20 ms to 19 ms. Since I had to modify a WPI VI that was outside the dashboard project folder to do this, I made a copy of the WPI VI and put it in the dashboard project folder and then made my fix. It is attached.

Fixed WPI_DashboardRetrieveStatusInfo.vi (52.7 KB)

Disclaimer: I have not tested this with a real roboRIO. If you use this, please test to make sure all 4 outputs of the edited WPI VI work correctly and continues to work without a lag after it has been running for several minutes with a real robot connected and let us know what the results are.

Also, I don’t think the Wait (ms) function in the false case of the case structure in Loop 1 of the dashboard is necessary because the UDP Read VIs are already slowing down the loop. It doesn’t appear to hurt anything either though.