Our programming team is having problems with camera lag. When we go direct to the camera webpage we can see the stream in real time (or close). When we are running it through the cRio, the video is 3-5 seconds behind. We have stripped the code down to nothing accept what is needed to get the video and put it on the dashboard and are still having the issues. Does anyone have any insight into what we can change in order to fix this issue. We are using Labview, using the provided examples and figure we must be missing something.
To view the video stream on the Dashboard, don’t put it through the cRIO first. Put it on the DLink @ 10.xx.yy.11.
Both the Dashboard and the cRIO can independently each open their own camera streams and get great response.
If either system doesn’t need it then it doesn’t have to use it.
The default code is setup to use the camera this way.
As Mark said, the recommended setup should work much better.
I’ll also explain why this lag happens. If you have the camera or any other TCP device start pumping out data faster than the other end is consuming it, you will see data collect in the TCP buffers. If you configure the camera to produce 30 fps and the PC reads at 29 fps, then each second, another frame if video collects in the buffer, making the PC lag another image behind. After 30 seconds, the PC is now 1 full second lagging behind (provided the buffers are that large). If you slow the PC to reading at 20fps, then 10 frames collect per second, and in 3 seconds you are one second lagged.
It turns out that the TCP buffers on the camera and PC will typically hold several seconds of images, meaning that you will see your video streams several seconds lagged with occasional jumps to catch up a bit.
One solution, is to slow down the camera or speed up the PC so that the buffer is kept relatively empty. And as Mark mentioned, the dashboard and other pieces now default to a more efficient configuration now that the robot contains an enet switch.