Built in distance calculations?

[pSYeNCe]

I was under the impression that there was no built in way to get distance from the Axis camera. After many hours of searching, I finally ran across this whitepaper on how to do it- however, another team member told me that the distance value is already in the program. If it is there, where is it? I've unbundled the Tracking Data and Target Info clusters to no avail. It would save a lot of time if this value is floating around somewhere...
(We're programming in LabVIEW; I guess it's irrelevant to put that here since this is the LabVIEW subforum, but you never know )

[Luke Pike]

I don't believe there is. The way I did it last year was to use the angle of the camera (either fixed or based of the servo or some sensor to measure that angle), the use trig to calculate the distance to the target.

Like this:

Target
|
----------- Robot camera
Find the hypotenuse

[ebmonon36]

If you look in the Rotate to Target vi in Teleop, there is a distance calculation at the top of that vi. It is not set up as an output but it could be.

[Greg McKaskle]

Be sure to compare against a tape measure. You may need to adjust the divisor a bit.

Greg McKaskle

[pSYeNCe]

Thanks everyone, we'll test it out once we get the camera installed.

[Carter12s]

Regardless of whether or not the code exists getting distance values from the camera will be a fairly imprecise method. I would instead suggest using the KOP digital encoders in conjunction with a position tracking program. I don't know of a Labveiw edition of one but i know that there must be. I have used in Java a program that by getting encoder values with give real time the position and speed of a robot on a Cartesian plane; The encoders in this years KOP are extremely accurate and if implemented in this manner would yield not only the distance to the goal, but if used in conjunction with a field map would give every distance on the field.

[Greg McKaskle]

In reality, all of these methods are pretty imprecise. Encoders on drive wheels cannot account for slip or sideways motion due to a collision with field or another robot.

The camera method works by knowing the real-world size of the target. At a given distance, the target should measure the same pixel size. Moving closer to the target increases the pixel size, and moving farther decreases. You can think through the symmetric triangles or use trig if you like, but estimating distance based on the perceived size of a known object is a pretty accurate approach. The thing that can cause moderate error is if the vision selects the inner circle rather than the outer error to base the distance computation.

The best way to determine the error is to measure it. Determine if it is accurate enough for what you need and determine if other approaches are more accurate.

Greg McKaskle

[pSYeNCe]

Originally Posted by Greg McKaskle

In reality, all of these methods are pretty imprecise.

Yeah, I had a feeling they would be. Depending on the results we get when we test it, we may not use distancing. Our code, fortunately, doesn't depend on it.

The camera method works by knowing the real-world size of the target... distance computation.[/quote]

I've noticed that the tracking software slips up a lot in our lighting conditions, perhaps because the setting in the Begin.vi is the default (fluorescent lighting, I think? I don't have it in front of me) and the default is probably designed for competition circumstances. Again, I'll have to test to get results.

[Greg McKaskle]

If you are using the ellipse detection like the default code is, the white balance setting shouldn't matter much. The first thing the code does is extract a grayscale luminance image. You might as well use a fixed setting IMO.

There is a white paper on the NI site that talks about the camera code and some of the things to consider. One thing that seems far more likely in a shop than in a competition is streaked lighting. If you've built a shiny target and you have rows of fluorescent lights, they tend to make long white streaks across the black of the target. You can see them if you kneel down and look at it from the camera's vantage point. Other than that, you would like to get a good contrast level, and fast camera response.

If you have images that do not work well with the ellipse code, post the image and perhaps people can help diagnose and suggest solutions. BTW, the default dashboard saves an image every second and keeps the last sixty in the documents directory I think. That will hopefully help document the camera performance and give you some data to crunch on to test out different approaches.

Greg McKaskle

[rath358]

We have found that image size works great for determining distance. I have developed a special VI that extracts the height of the target from the supplied information, then plugs that into a formula I derived by graphing a bunch of data in excel. It is accurate to 30 feet on medium resolution, within +/- 6inches, and 45ish feet on high. Accuracy only drops off only because of problems finding the target itself.