Angular Rectangle Tracking

Ok, I have studied the NI white paper and have been running the rectangle track example quite a bit. After getting solid target samples using IR emitters and lenses I have found that when exactly straight in front of the targets I get a beautifully accurate distance from the camera to the center of the rectangle, but as I angle myself to the targets I notice my distances all go horribly awry. Now I KNOW that FRIST and NI, with their never ending knowledge wouldn’t make an example that can only be accurate straight on, furthermore I feel like as I read on CD I feel like some of you guys are also successfully reading accurate distances when at an angle comparative to the hoop. Any insight on how I can be successful with angular distance reads of the rectangle?

-Much Appreciated
Lightfoot26

Can you give more detail on how far from center, and what horribly awry is? Can you tell what term is not working?

Also be sure that you have the correct camera selected.

Greg McKaskle

The 206 is selected and is what we are using, and I mean when my camera is at an angle to the hoop I get distance readings 3 to 4 feet off, though when straight on I get readings that are dead accurate.

When you are not directly in front of the goal you are tracking a trapezoid, not a rectangle. I have not looked at the code, does it account for this? Perhaps you can feed a rectangle into your code and use the height of the left or right side of your trapezoid. BTW, the relative heights of the left and right side will tell you want angle you have.

HTH

and I mean when my camera is at an angle to the hoop I get distance readings

What distance? How far off center? What angle? Even better, what about an image so that we can work on the problem together.

Greg McKaskle

Ok, so I have attached 3 pictures showing what I am talking about, all of these taken when the center is 7 feet 2in from the camera. The first on is the straight on picture, and is giving a near accurate workable measurement. The second is a slight angle showing a drastic gain in distance, though its STILL 7 feet 2in from the center, then I moved the rectangle to the most extreme angle I can get it while the program still detects a rectangle and distance measurement is farther still. That any help?









I did a bit of quick measuring on the attached images and I get …

105x79
92x82
77x84

for sizes of the green rectangle. I’m not sure if the green surrounds the red or is one larger, but it gets us a pretty good measure of the rectangles that are being viewed.

What I think you’ll notice is that the widths are changing by more than the height. Relating everything to the first rect, we have

100%,100%
87.6%,103.8%
73.3%,106.3%

This all makes sense since the rectangle will eventually turn into a small vertical sliver that is (distance - 12") away and full height. A little taller than original actually.

So … perhaps you should take the math in the original VI and have it calculate the distance using the height of the bounding box using the height of the tape and the pixel height of the image. It may vary a bit more if the camera is tilted up or down looking at the rect, but it should vary less when distorted as your images are.

You mention that beyond this angle, the rect detector fails, and from the green text scores next to the rect, it seems like the aspect ratio is the score element that will fail. There is nothing that says you need to pass all four, or by how much. Those scores give you some measures of how rectangular and how hollow the element is, and you can use them any way you like. For example, if the edge scores are super high, you could allow the aspect ratio to drop significantly, and even use it as an angle estimator. Similarly, the area score will drop a bit as the rect turns into a quadrilateral. The example is there to demonstrate some relationships, but can certainly be specialized and improved, and I encourage you to make it fit the way that your team’s robot will play the game.

Thanks for posting the images, and I’ll be happy to answer any other questions.
Greg McKaskle

I thank you for all your help on the situation. After your help and my further understanding of the code, I have tailored the code to do exactly what I want, and now we are extremely accurate. Thanks a bunch!

-Lightfoot26

Do you think you could post your block diagram? We’re having issues running the image processing through our laptop.

I’m glad it helped. Good luck with it.

Greg McKaskle

My team is still looking how to figure this out too. Has anyone had any luck with tracking trapezoids or shapes other than a perfect rectangle. If so how?

The code this year is a bit smarter. It is also covered in the white paper. It uses something called the Equivalent Rectangle for a particle.

Basically, a particle has an area A and a perimeter P, so you can solve for the rectangle of height H and width W where A=HW and P=2H + 2*W. It can do this for circular, trapezoidal, and other shapes, and doesn’t really claim that the particle is a rectangle, but if it happens to be, the W and H should be pretty close, typically a tighter fit than the bounding rect and less sensitive to skewed rectangles.

This year’s example uses both the bounding box and equivalent rect as measures to compute the distance.

Greg McKaskle

We manage to get the rectangular tracking done. Now how to we put that data in the vi so it will ajust to the right angle of our window motor to get the right angle for our shooter.