[Greg McKaskle]

After doing some profiling and testing the other day, I also have recommendations for video back to the dashboard.

If there is a big lag, ~5 seconds of lag, that is caused by a TCP backlog somewhere in the network from camera to cRIO to bridge to router to laptop. Clearly it could be happening anywhere a processor is bogged down, but the cases I was most easily able to reproduce was to set the camera to high frame rate, then run everything on one classmate so that it was fully bogged down. Using probes in LabVIEW I was able to see that the cRIO was sending images every 33ms over TCP, but the classmate was only displaying them every 100 ms or so. That means that the laptop TCP cache quickly fills with images and the lag builds to around five seconds with occasional jumps. To correct this BIG lag, do less on the cRIO. An upcoming driver station will assist in this as I found some UI things that could be sped up, but if you have other tools on the classmate and you look at the Task Manager and see the CPU fully loaded, that is the likely explanation for the lag.

As for the frame rate, it is highly affected by the jpeg image size being sent by the camera. Specifically, images larger than 16k in size are causing slow memory allocations, ~100ms, at various places in the WPI and development libraries. Below 16K, the allocations take much less time, ~5ms. By setting image compression on the camera you can see the effect.

To reproduce these results, turn off the continuous circle detection. For LV this means turning of the button on Robot Main. C and Java sample code do not do the detection until the button is pressed.

With the image size set to small 160x120, most any compression will achieve high frame rates, 20-30 Hz. The default of 5% is fine.

With medium image size, 320x240, the 5% image compression will result in a frame rate of around 8Hz at the classmate. Raising the compression to 20% should raise the frame rate dramatically as the image size falls below the 16K mark.

For large, 640x480, the compression number necessary to get the image size small enough is around 75%.

Similar numbers were seen to work for C++. Note that high compression numbers affect image quality, and this is not a linear affect. Allocations above 16K are all pretty slow, and below are all pretty fast. Plus, the camera will not and cannot produce images faster than 33ms, so super high compression will do nothing but distort the image. If you plan to use image processing to find ellipses, this will perform more reliably with low compression images. The numbers listed above should be a reasonable tradeoff of quality and speed, but feel free to experiment.

It may also be useful to enable and disable ellipse detection depending on the task being accomplished or on the mode of the match.

Greg McKaskle