Labview Slow Images Capture

[Greg McKaskle]

What were results of the wifi? The difference between 150ms and 1500ms is huge. Did you fix the 1500 or did it just go away?

As for the field radio conditions. I have not seen evidence that the lag is typically there. I volunteer at a few events per season, so it could be that it happens when I'm not looking.

On the other hand, at every event, the situation plays out where a team blames the field and swears that fill-in-the-blank symptom has never happened before. Each time the issue has been debugged, typically on Thursday, and is caused by static discharge, a HW, or SW failure that just didn't show up until the rigors of competition.

The DS this year has a tab on the far right called Charts which displays and logs the packet loss, round trip time, cpu usage, and battery voltage. It also displays the tiny dots which show the state the field is asking the robot to be in and the state(s) that the robot code actually executed. This last feature only works if you insert, or don't remove, the instrumentation code that is in the framework. Program Files\FRC Driver Station\ also contains a Log File Viewer app to review and compare logs from shop and competition. If you run your code through the practice match, not just tele and auto separately, and you watch the last tab on Thursday, I think you are prepared. If the gremlin exists, I hope that the new tab helps to identify it sooner, whether it is a robot HW, SW, or field problem.

If you get to an event and decide to lower throughput on the field, I'd suggest lowering the resolution and upping compression to 60 or 70.

In testing I've run three cameras on a single robot in our eight story office -- a super wifi noisy wifi environment. The limiting factor was the old laptop's ability to decode and display. If you can reproduce the 1500ms or larger lag, please give details.

Greg McKaskle

[gnunes]

Originally Posted by Greg McKaskle

Did you fix the 1500 or did it just go away?

Yes, and no. My original code, which I made my cutting away and modifying a dashboard project still runs crazy slow. An essentially identical program, made "from scratch" has only the expected 150 ms latency.

This morning I deleted the cast to an HSL from the dashboard-derived code, and the lag seemed normal (I didn't test this quantitatively). When I put the cast to HSL back in, it went back to the huge lag. But the other version has the cast to HSL and not the huge lag.

???

[Greg McKaskle]

I spotted the difference, but thought I'd introduce some new tools as part of the explanation.

If you goto Tools>>Compare, you can choose the From Scratch and From Dashboard and it will diff and explain all of the differences between the VIs. Clearly one has a big numeric, and one has some dT calculation. The key difference for performance is in the cluster's value. One image is 320x240, and the other is 640x480. If I change the scratch VI to 640, it is slow, and if I change the dashboard VI to 320 it is fast. I really mean large and small latency, but you know what I mean.

Next, I opened Tools>>Profile and ran the Performance Profiler on one of the 640 VIs. Click on the Start button, then run the VI for about five seconds, then stop the VI, then click on the Stop button on the profiler. You may also find it useful to click on the Timing Statistics checkbox, and that will tell you how many times HSL conversion was done for the time it took. It also does the min, max, and avg values. On my machine, it adds an average of 50ms to convert a 640x480 image to HSL. With data coming in every 33ms, "Houston, we have a problem". My computer has two CPUs, but the operation can only fit on one of them the way it is written, so my CPU usage is about 60% and I'm CPU limited. And indeed, the fps is about 20.

The latency is introduced because while the CPU is processing an image, 1.5 images arrive. So pretty quickly, the TCP buffers swell up and the video stream is lagging. If I drop the framerate from 30 down to say 10, the video will obviously get a bit choppier, but the latency is now something like 250ms. If you use the VIs from the robot, the one that reads the stream continuously in a parallel loop and sends the data across in a notifier buffer. This would allow the fps setting to degrade better and not introduce much lag. It didn't seem necessary for the dashboard, but can be used if you need it. Or you can drop the fps and tune it by looking at the CPU usage. Be sure to restart the VI, restarting the mjpg stream when the parameter changes.

Greg McKaskle

[pfreivald]

As a team that's puzzling through image processing, this thread is gold. Thanks for bringing it up cesaros, and thanks for being so darn helpful Greg!