We tried to connect Limelight 2+ (either through swtitch or directly to the router).
After some time that the robot is running, the NT values from Limelight freezes in LabVIEW despite you still can see stream and updated values in the web interface.
Restarting the Limelight as well reebooting the Roborio solve it temporary, but it’s not a workable solution during a match.
Earlier this season we also tried running our own vision processing on a RPI (3b+ and 4) coprocessor, and had the same problem.
Just to be clear, it happens also in a blank new project.
It’s never happened to us last year, so we suspect
in this year update to the NT Server in the Roborio.
Although I’m suspecting the NT version of the Server, one of the programmers managed to bypass the freezing values problem by going back until 2016 version of NT on Client side (RPI).
A lot of changes have been implemented since than in NT, so we don’t want to go with this solution.
Is this after deployment or during LV debugging? There appears to be a long-standing bug in the LV networktables that necessitates a restart of any clients (see the restart vision client button in the settings page of your Limelight)
Hey Peter and thanks for the quick response,
Seems that the workaround solution will increase significantly the delay of getting vision processing values.
Sending values from the Roborio, will update them on a 100ms rate.
We can use flush on Server,
I saw in another thread you don’t recommend doing flusn on Server side.
Even if we do flush, it will add about 10ms delay.
Correct me if I’m wrong, and thanks for trying to help!
Restarting works, but if it’s happend during a match, from the time the problem occur it will take too much time until we’ll recognize it happened and then pressing the restart in the settings page…
Btw, how long it should take from restarting until Limelight is up again?
Re-reading your issue report, you’re seeing this when reading values in your robot side LabView code? That known issue is only for replication of values from one client through the server to another client. Are you concerned about latency to the dashboard display or another coprocessor?
If you’re seeing it in your LabView code, you might see it only when debugging, and during normal execution you’ll never see it…
The freezing of NT values happend in LabVIEW code side. We get them from a coprocessor (Limelight/RPI), and use them on LabVIEW side on the Roborio to align to target.
Can you explain this statement please so we can understand what is exactly the issue?
When you say “debugging mode” do you mean running Robot Main without building and run as startup?
Or by debugging you’re meaning in this casr to using “probe” option in LabVIEW? I believe you refer to the first option I mentioned, but just want to be sure.
It might happen in either case, I’m not familiar enough with the LabView runtime to be sure. If the LabView code is completely “stopped” or slowed down sufficiently, it may affect the NetworkTables operation within LabView. Have you ever seen the issue with a deployed program?
We haven’t saw it in deployed program, but at home we almost never run a deployed program.
In our first event, we never saw the issue, but match time is 2.5 minutes, and usually it take more than that until the freezing problem occur.
So I can’t say if it doesn’t happened in delpoy or it is just because we run the deployed program for shorter periods.
We have seen it over and over again when running from Robot Main. We have not seen it when our code is permanently deployed. We just open the limelight webpage and tell it to restart the vision server and it starts to function again.