Network Tables values of Limelight/Vision Processing freezes in LabVIEW

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.

Can it be part of this issue Robot Keeps Losing Com and Code ? @oscarfonloz

I heard we are not alone and more teams experiencing the issue I described, has someone managed to figure it out?
Does any official side aware to this? (NI, WPI, Limelight)


Guys that I tagged, if someone else is more relevant please tag him here :pray:.
Any help is welcomed!

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)

Is it this known issue?

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,

  1. I saw in another thread you don’t recommend doing flusn on Server side.
  2. 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? :pray:

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.

How long does it typically take for the problem to occur?

Sometimes it could take about 15 minutes and some times an hour.

I would not relate these two behaviors just yet.

My team uses LabVIEW and Limelight to aim to the target during the match and has not run into this issue during gameplay.

I recommend ensuring you have the latest Limelight software installed in the device.

Oscar thanks for the response, we got latest software.

Did you encounter in this issue at home when you are running robot main without building it to the Roborio?

As fas as I remember, we have not seen it in any of both modes. I just asked one of my team’s programmers and he doesn’t remember bumping into it either.

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.

Is there any good documentation on setting thresholds? We cant seem to get a consistent target anywhere we go weather it be at home in the shop or at competition.

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.