Speed of the camera

[Daniel_LaFleur]

Originally Posted by StevenB

You could use a couple of digital IO pins as a serial port. It's been done before...

Hmmm, I wonder what the transmission rate of the DIO pins are .....

[Jared Russell]

Originally Posted by Daniel_LaFleur

Hmmm, I wonder what the transmission rate of the DIO pins are .....

The GPIO inputs are sampled at 173KHz according to the GDC. Don't know about output rate (probably the same?).

[TheDominis]

My code can process 1000 640x480 images per second.

EDIT: I'm sorry. ~.00012 seconds was the time difference. It's actually about 10000 images at 160x120. I'll post the time for 640x480 tomorrow.

-TheDominis

[Alan Anderson]

Originally Posted by TheDominis

My code can process 1000 640x480 images per second.

I'm curious to know what your code is doing with the image, and what information it provides to the rest of the program when it has done its processing. What language is it written in, and would you consider sharing it?

[TheDominis]

I won't share it. I'm using C++ and my code provides accurate data to be used by our cannon.

-TheDominis

[Zultraranger]

Originally Posted by TheDominis

My code can process 1000 640x480 images per second.

EDIT: I'm sorry. ~.00012 seconds was the time difference. It's actually about 10000 images at 160x120. I'll post the time for 640x480 tomorrow.

-TheDominis

Pics or it didn't happen.

[Robopanda6]

WE NEED HELP!

My team is testing it's camera and it sees the colors just fine. The problem we are having is that even the camera sees the color it won't track the color using the servos. Does anyone know what's going on?

[Greg McKaskle]

Make sure the servo channels match your wiring, make sure the channels you are using have jumpers, make sure your RSL light on your digital sidecar is steady green. All of these are necessary for the servos to move under computer control.

Greg McKaskle

[Shamx]

How are you guys checking the frequency? What we see so far is just the framerate which is currently at 7.5fps, which is not tat great.

[TheDominis]

I've just tested 640x480 and it takes ~.0008 seconds for each image. 1250 images per second.

-TheDominis

[Shamx]

I find that extremely hard to believe since the camera can only support up to 30 Frames per second, which means it can receive 1 image at every ~0.0333 seconds, and thats the MAX possible by the Axis 206.

BTW, whats everyone's framerate running at?

[TheDominis]

I am processing the same image more than once. I disabled the timestamp checking to see how many per second I could process.

-TheDominis

[Shinigami2057]

Originally Posted by TheDominis

I am processing the same image more than once. I disabled the timestamp checking to see how many per second I could process.

-TheDominis

There is absolutely no point in doing that, other than to benchmark the cRIO using the imaq library. It has little use in tracking anything, other than to waste cycles that could be used by other parts of your program.

[s0crates]

Because I was curious as to how much running image processing on a faster processor would speed it up, I tried it on an (admittedly extremely slow - probably under 2 ghz) laptop and got a framerate of 20 at a res of 320x240. This was just a simple loop of getImage; with simple processing (threshold, fill holes, get measurements of particles), it didn't really slow down. At 160x120 it was more like 30 fps. Since it was running locally, outputting the image didn't slow it down.

Something I'm curious about is what the actual framerate of the axis 206 is - ie, not what the specs say, but what it can actually serve. The laptop - running xp - was reporting cpu usage around a consistent 10% or so, so either it was the network - 100 megabit ethernet (12.5 megabytes/sec) or the cpu onboard the camera is too slow to deliver at higher speeds.

I could probably have sped the processing up a bit by running it in separate loops communicating through a global var so it could utilize both processors. Actually, best performance could (I think) be gotten by using a dual core and decoding and processing in one, and acquiring images in another processor/thread.

Based on the results I've gotten, the network/camera seems to be a major bottleneck at higher resolutions, unless much more of the cpu was being used than what was shown. Tomorrow I'll try with the priority set to framerate and see if there's a difference.

Does anyone have something they've written to test the bmp image retrieval capability? I would be interested in tweaking/changing that and posting any changed or improved code... Otherwise, I'll just post any code for it that I come up with.

-jonathan

[Greg McKaskle]

The camera framerate is often limited by the amount of available light. If you reproduce the test, be sure to aim the camera at the ceiling, or at the lights. You should see the framerate go up. Then aim it at dark stuff, or mostly cover the lens and it should go down. Oddly, when you put your finger over the lens to make the camera go completely dark, it usually falls somewhere in between, presumably it gives up on a decent exposure.

If you set the exposure priority to framerate, the lower light images will get a higher framerate, but will be grainier.

I've wrote and retested the BMP stuff just the other day. The framerate was miserable.

Greg McKaksle