Re: Speed of the camera
 

The LV code doesn't use MJPGs. It does SW timed acquisitions of JPGs. Each of these need to provide authentication, and this is done first with FRC/FRC. If that fails, two more attempts are made just to support older cameras. Anyway, because a camera that isn't set up will fail on its first attempts each time, you can get much better frame rates by doing the camera setup.

If you are doing your own authentication, this doesn't apply.

As for the compression penalty, it is a surprise and a mystery. I suppose it is because the ASIC pipeline isn't deep enough. Who knows. The default for the camera is 30 by the way. I was just wanting to point out that there is a bad side effect to making the camera compression to be set to zero or really small numbers. Similarly, be cautious with numbers near 100.

Greg McKaskle

Re: Speed of the camera
 

Just wondering, what exactly do you guys mean by "hz?"

Re: Speed of the camera
 

Hz is Hertz, which basically means "per second." so something that runs at 100 Hz runs 100 times a second.

Re: Speed of the camera
 

When running the code locally on a laptop, the frame rate improved dramatically with compression ~85 instead of 30, although I remember seeing a slowdown on the cRIO when increasing the compression a lot.

Does anyone know why the default code doesn't use the mjpeg stream?

-jonathan

Re: Speed of the camera
 

The default code initially used the MJPG stream when prototyping. This worked fine until something caused the cRIO to fall behind on the images. At that point, the TCP session will queue up images waiting for the cRIO to read them. It would at times have up to five seconds of images sitting in the queue. This of course caused a huge lag.

The other approach is to have the cRIO ask each time it is ready for an image by using the JPG cgi script.

Comparing the two approaches, they were very close in how they behave. Due to individual preferences, the LV code ended up going with the SW timed JPG approach and the C code ended up doing the MJPG stream.

Greg McKaskle

Re: Speed of the camera
 

who is getting 30 hz and is not getting 10000 hz (not that I don't trust that person but I am inclined to doubt that nothing is wrong with that tracking code.) I'm up to 20 hz and I was wondering if those 30s are real 30s.

Re: Speed of the camera
 

With enough decimation, sure. But for me, a more normal rate for the gimbal tracking two color at small size is around 20.

Greg McKaskle

Re: Speed of the camera
 

Hm...Is that how fast our code processes the image (decimate, subset, threshold, etc...) or how fast our code returns data to motors and servos (which can be improved via motion estimation)?

In any case, our current code processes images around 17-24 frames/second. Pretty usable, but I'm trying to make it faster.

Re: Speed of the camera
 

our code runs at about 99hz, it loops through, processes waits 1/100 second, and repeats, very smooth and fairly fast, our only trouble is overshooting the target, but almost done

Re: Speed of the camera
 

How are you tracking the target? Threshold and particle analysis?

Re: Speed of the camera
 

Yes, we have a class we call, I dont have the code in front of me, but we see if the y value for the pink is over the green or vice versa (midPinkY>midGreenY){return friend;} else return foe;
edit: midPinkY = par.Center_mass_y (or something like that)

Re: Speed of the camera
 

I'm having trouble calculating the time it takes the camera to track the target.
I did a series of cases in LV which check if the current state of the camera is "Search-Begin" or "Searching", and on the first run of the case, it will save the time in miliseconds. The code keeps running and once the state is "tracking", it saves the currect time again. Then I display the subtraction of the tracking time in the initial time in an indicator.

Some first times that I run the code, it works and shows around 200 to 400 miliseconeds, and sometimes it shows that the camera is alrady in tracking state, on the first iteration, and therefore the display shows 0.

how would you track the time it takes for the camera to track?
I'd like to do this check without having the front panel open so it will be faster.

Thanks,

Re: Speed of the camera
 

There is an output from the Find Two Color that shows the time spend analyzing each image. This isn't the entire task, but it is the most expensive step. So if you watch that number you'll get a pretty good idea of the processing cost. Note that this doesn't count the time spent waiting for the camera to return an image, which usually happens in parallel, but sometimes it isn't finished when the processing is.

The other reason I mention this is because timing diagrams where things can happen in parallel is sometimes a bit tricky. If you open the Find Two Colors VI, you can see on the left and right are the milliseconds calls and the subtraction. The extra sequences and wires branching off here and there are to make sure that one time happens real early, and that the other happens last. If you aren't careful, the thing you are timing happens, then you take two times and subtract. Also, especially with loops involved, the loop could run some, then you start your time. One time some is none, and you get a good timing. The next time some is most, and you end up with a small number.

The most foolproof way to time a diagram is to put a sequence around the entire diagram, then take the time in a sequence frame before and after. It is just to distracting that most people do it without the monster sequence.

Greg McKaskle

Re: Speed of the camera
 

So you are saying, the first sequence frame gets the first time, where we get the intial time, and the other sequence frame gets the time when we reach the "tracking" mode and then it substracs the two times?:confused:

Re: Speed of the camera
 

I wasn't being specific. Time once just before and once just after the thing you want to time. This delta it the time the code in between took.

If you are instead wanting to time subsequent visits to the same code, you can have just one millisecs call and a feedback/shift reg/local. You subtract the last time from the new one, then update the stored time.

Greg McKaskle