Image processing- too slow on cRio...

[pgaston]

We've followed this approach:

• Took lots of static images with the camera
  
• Used Vision Assistant to  determine HSL values, play with some morphology (fill holes, erode, remove small particles, ...)
  
• Used the example labview FindColor program w/ some minor changes (findings from Vision Assistant)
  

    -- Worked great on PC - running at 38 frames per second (no decimation)

• Added this VI to a new FRC robot project - Basic.      Set the camera fps to 30.
  
• Runs correctly on cRio - finds images, plots intercept course, etc.
  

    --- But only at 3 to 4 fps

Yow.   

Closed dashboard, assuming that the streaming of the real-time images to the driver station / laptop were slowing things down.   No dice.    Noticed that the front panel for some VIs also show the image and mask.   Closed those windows.   Still 3-4 fps.    Changed decimation from none to 2/2, then 3/3.  No discernable difference.   (On PC this would already take it to >400 fps!)    The world is a lot different at 3-4 fps versus 30 fps.

Thoughts?

Question on the side - when/why does Labview bring display data back to the laptop?   I was sort of hoping only when a window was open and asking for them.

Thanks!

[Greg_McKaskle2]

You should be able to get more than 3 or 4 fps. Most likely, your camera is set to return 640x480 images. It takes ~100ms to decode that size of an image on the cRIO. Assuming the camera takes 30ms to return an image, plus 100 for decoding, and you are now at like 7 fps with no processing or additional overhead. Plus you have lots of pixels to process, 300,000 of them.

The demo sets the camera to 320x240 I thought, and it will be even faster at 160x120. The decode times are ~22ms for 32x and ~8ms for 160. Plus the pixels to process go down by 4x and 16x.

Another thing that will slow down an RT app a huge amount is to add a property node into the loop. This requires a round trip to the host, and will drastically cut performance, even more than an open display.

When/Why data? When a window is open and the data is written to via terminal, local, or property node.

Greg McKaskle

[pgaston]

Thanks!      How about these rash assumptions?

• So - it sounds like reducing the image size at the camera is a *much* better way to go than decimation.    Exact same effect but much quicker.    (I'm surprised at how slow the cRio / camera area turns out to be - for some reason my expectations were in the 30 fps range...)
• Property node.   I'm guessing that this is something that wants to display on the screen.
  

And, lastly, now that the sample code is released on how to do this right (by the experts) - I can chuck all this and start with their code, eh?

That link, by the way is http://joule.ni.com/nidu/cds/view/p/lang/en/id/1215 - Two Color Servo Camera Demo V

[Greg_McKaskle2]

If the images weren't compressed, it would be much less of a load on the cRIO. In reality, the PPC 603e is a pretty simple architecture, and 400MHz isn't slow, but isn't super fast either.

Greg McKaskle