Camera Tracking

[Tanner]

Hi all,

We're trying to get the robot to track the trailer using a PID loop. We've got the targeting of the colors on the trailer down. Though for some reason, we believe that the PID loop is not getting data as fast as the Image Processing.vi gives it to us. It is as though we're watching a movie, but only seeing frames at a low frame rate, not what it's playing at.

We're not exactly sure what to do next. The code seems so simple, that it can't be our code that is slowing it down (unless we're missing something big). I'll post a copy of our code in a bit after I find my externel HDD.

Any ideas?

Thanks
-Tanner

[Greg McKaskle]

You don't mention which dev environment, but some of my comment will be similar either way.

If using LV, beware that open panels add overhead. Great for debugging, but that is the price you pay.

Probe the output from the camera, and within the PID area where you are consuming that data and acting on it, probe again.

The better type of probe would be a chart so that you have history and can see how much of a lag is there or if you are indeed skipping values.

If you can't get them probed, just add indicators here and there.

If not using LV, trace values in C by dumping to an array of printing to a file.

Again, what you are looking for is the way the values interleave, and whether they lag.

Greg McKaskle

[Tanner]

Originally Posted by Greg McKaskle

You don't mention which dev environment, but some of my comment will be similar either way.

If using LV, beware that open panels add overhead. Great for debugging, but that is the price you pay.

Probe the output from the camera, and within the PID area where you are consuming that data and acting on it, probe again.

The better type of probe would be a chart so that you have history and can see how much of a lag is there or if you are indeed skipping values.

If you can't get them probed, just add indicators here and there.

If not using LV, trace values in C by dumping to an array of printing to a file.

Again, what you are looking for is the way the values interleave, and whether they lag.

Greg McKaskle

Thought posting in the Labview forum would be a hint towards what I was using.

Er, I must be lost or confused. Probe / indicate what? I've got a graph on my Track Trailer.vi (with the PID loop) that displays my set point (0.5 the width of the image) and the process variable (x value from Image Processing.vi). When it runs, the graph clearly shows the process variable as a "square wave" - all square, not smooth like a Sine wave. The "smooth-ness" of the wave can be affected by the frame rate and other things from the image processing, but not by much.

So, I'm not sure what else there is to probe...

Thanks
-Tanner

[Greg McKaskle]

Sorry about that. Answer enough and you don't know where you are.

If you are getting a slow framerate due to displays or other things, and you are moving the target moderately fast, it seems reasonable to get pretty big and sudden jumps in the setpoint. Are you sure the rest isn't just tuning? If you are using the outputs wired to drive, it takes -1 to 1 range, right? So are your outputs in a range like that?

If I'm still not getting close, maybe you should copy the graph and paste it in the next post.

Greg McKaskle

[Tanner]

Originally Posted by Greg McKaskle

Sorry about that. Answer enough and you don't know where you are.

If you are getting a slow framerate due to displays or other things, and you are moving the target moderately fast, it seems reasonable to get pretty big and sudden jumps in the setpoint. Are you sure the rest isn't just tuning? If you are using the outputs wired to drive, it takes -1 to 1 range, right? So are your outputs in a range like that?

If I'm still not getting close, maybe you should copy the graph and paste it in the next post.

Greg McKaskle

Hehe, no problemo.

Eh, this situation is so confusing. We move the target around in a slow walk to a walk and the graph shows up in lots of jumps (not a nice "smooth" square wave we could expect with Image Processing.vi running so fast). I need to record some of the data and get the latest project on my HDD so I can show what exactly is happening.

On our PID loop, we've got the output limits at 50 and -50 and a divisor at 200 or 100, I can't remember which. We use a divisor and such high limits so that we can use integral, but with my limited use of a PID loop, I'm probably getting ahead of myself and should stay with just -1 and 1 outputs?

Thanks
-Tanner

[Greg McKaskle]

I didn't get to my main point in my previous posts, but if you see LV data onscreen, in a probe, graph, or array, you can right click and copy data. Then open a new VI and paste. You now have the binary data captured for further analysis. Make the current value default, save it, or change it to a control and write a quick program to do what you want to the data set. If you paste into Word or other apps, the thing on the clipboard is an image, but within LV it is a graph or other control with the data.

The point is, it is not necessary to rewrite the program to use file I/O if you want quick data. File I/O is still good of you want to be systematic about gathering data for driving runs.

If you start doing this, there are a few odd things in LV. For arrays, you will want to Select All in the right click first, otherwise it copies just the selected data, which is hard to control and normally nothing is selected. Also charts display history, not just their data, so copy data on a chart is odd too.

Anyway, the picture will probably allow control guys to help out much more than just your description.

Greg McKaskle