I’m attempting to get vision tracking working in the Vision Processing VI. I have only slightly modified the example code by removing features I’m not using, so I don’t believe I’ve altered core functionality.
When I run the project on the cRIO, I get this error output from the Camera GetImage block:
WPI_CameraWait for Raw Image String.vi:1>>WPI_CameraGet Image.vi>>Vision Processing.vi>>Robot Main.vi
<time>17:56:59 04/08/2012<unique#>17567
Nothing shows up on the front panel for either the pre- or post-processing images. I have run the example Rectangle Target Processing, and everything works great. The very high speed that the vision loop is running at indicates that no processing is taking place, even though it should be, and the 44005 error is repeated every cycle of the loop.
I am using an 8-slot cRIO and Axis m1011 camera plugged into the d-link.
Does anyone know what I need to do to fix this error? Any help is very appreciated.
Our team had the same error, with the same setup (8-slot + M1011). We wasted a few hours trying to fix it, and eventually moved our vision processing into a custom dashboard, sending the boiled down output to the cRIO through UDP (port 1130).
Even the wimpy classmates have more processing power than the cRIO, allowing us to use a higher resolution image. This also cuts down on processor contention on the cRIO, where a blocked teleop loop can halt your drive.
We’re you, by chance, feeding a grayscale image to the vision processing vi?
So the GetImage error is related to the speed of the processing on the cRIO? That hadn’t occurred to me, I figured there was some other internal sort of problem going on. I’ll have to take a look at it. And yes, I am using greyscale images.
It may have more to do with using grayscale. That is what we were using. Each pixel in the grayscale image is an unsigned 8-bit value, where each pixel in the standard RGB image is an unsigned 32-bit value. There may be a problem in the precompiled JPEG decoder function that is called, where it may only be able to deal with the standard 32-bit version. Just my theory, as I don’t have the source code.
The PC version of the decoder had no problems with our grayscale stream.
It looks to me like that error may be returned if you were to delete the Acquire MJPG Loop VI. The get image returns the latest image in the buffer, but the loop VI handles the stream from the camera and updates the buffer each time one arrives.
We got the error with the original code from the find rectangular targets VI, with the only change being the switch to grayscale in the camera configuration.