Re: Speed of the camera
 

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

Re: Speed of the camera
 

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?

Re: Speed of the camera
 

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

-TheDominis

Re: Speed of the camera
 

Pics or it didn't happen.

Re: Speed of the camera
 

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?:eek:

Re: Speed of the camera
 

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

Re: Speed of the camera
 

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.

Re: Speed of the camera
 

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

-TheDominis

Re: Speed of the camera
 

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?

Re: Speed of the camera
 

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

-TheDominis

Re: Speed of the camera
 

More so than the HTTP session I'd be worried about the connection creation/destruction each time. Since the the camera literally streams JPEGs pushing them once every time it gets a new image to the connection, it maintains the same connection throughout. Connecting is one of the largest overheads in network systems (when you consider the camera is running a server that probably allocates memory for each call when it's made, etc., slowing things down). Although I do suppose it's all NULL due to the transmission delay on bitmaps as you say. I might investigate this myself later, but only after the base code does everything I'd like it to :-)

Another possibility for speeding it up would be to remember the position of the target between images, and use that as an estimate for where it will be the following time. If you get the cycles fast enough, it shouldn't move too much in between (or, you could even add a simple first-order approximation of position based on current and previous positions). Then find the particles within 50 pixels of the previous spot or such. I'm not sure if it's possible to force cropping on the camera side, but that'd possibly be handy - although, again, probably force constant re-connection (I don't know if the camera supports keep-alive connections. Although it does have a scripting interface...)

Another fun improvement might be to sync the servo movement up with the camera, so that pictures are returned a little less blurred. Or use a gyro to counteract turning of the robot automatically, also lessening blur.

If you wanted to go _really_ in depth, you could take the cropping idea above to a whole second level, and write your own JPEG code to only decode the blocks of the image that you think the target would be in (IIRC from the file format, you'd still have to go through the huffman encoding for the entire image, but you could do the IDCT and such only on the parts you need).

There are literally tons of things I'd like to explore to try and speed up this code. Although, for those interested, my first attempt is going to be to get libjpeg compiled for this processor and see if it's able to decode any faster (although for all I know, NI's JPEG code could easily be based on it, and I'm wasting my time - research is to be done).

Re: Speed of the camera
 

Again, I encourage you to run lots of experiments with it. Many of the things you mention are used on a regular basis with industrial cameras, but those weren't in the price range to go in the kit. The 206 is primarily a security camera or monitoring camera, and the features like crop or ROI or precise timing don't exist. The camera does a pretty good job of getting a decent image back to the computer, but many of the things that would be useful for optimization aren't in the current camera's firmware. Maybe next year.

I actually looked at our JPEG algorithm to see about a subset decode, and it would be easy to do the bottom of the rect, but the others get hard really fast. Please let me know if you find a better JPEG algorithm. I was told this is a good/fast one, and I was unable to locate one from Freescale tuned to this architecture.

Greg McKaskle

Re: Speed of the camera
 

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. :)

Re: Speed of the camera
 

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

Re: Speed of the camera
 

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