After getting the camera mounted and tracking, we are working on calculating range. I used the algorithm that Kevin posted, (Target height - camera height)/tan(tilt angle), substituting the formula for tilt angle in terminal.c.
Duee to height constraints and mounting problems, we are limited to a height difference between the target and the camera of 7 inches.
Up to a distance of 200 inches, the algorithm provides sensible data, but one step farther and the distance jumps to 400 inches.
Can this problem be attributed to the smallness of the height difference?
Another thing to note… you should calculate your position relative to the light. You still need some sort of fourmula to turn that position into a tilt or speed or whatever variables you are controlling.
I have an idea of what might be happening to you, but I can’t really put it into words. If you could, tape the target to the wall at whatever height you can (higher is better, up to the actual hieght of the target), and then move the camera accordingly, closer and farther. You may not get the giant jump you talked about. Maybe…
[EDIT] Did you mean 7 feet, not inches? The values at seventeen feet looking at something 7" above it would be indiscernable for calculating range…
I think you are asking, “can this problem be attributed to the small change in angle between the last two measurements,” right? If so, I think you are spot on. The farther away you get, the smaller the measured angle differences. I think you found the camera systems cutoff between meaningful angle distances and the noise level.
Hey, 200 inches is nearly 17 feet. How many teams realistically expect to score from farther away than that? Kareem Abdul-Jabbar scored 38,387 points in the NBA. Three of those points came on 3-pointers. In the ten years the 3-point play was legal during his tenure in the NBA, Abdul-Jabbar attempted 18 3-pointers and only sank 1. He is one of the greatest players ever, and is in the Hall of Fame. I think the teams trying to shoot from outside the paint (to continue abusing basketball metaphors) aren’t going to score very often.
to get the highest degree of precision you want to use the full range of the camera system, so that at the furthests distance the reading is at one end of its range, and at the closest distance its at the other end.
I want to say the camera should be mounted near the floor, to get the greatest change in angle between close and far, but I dont know all the details of how the camera works
but look at it this way, if you mount the camera at the same height as the light, you wont be able to measure distance at all, right?
if you cant put the camera lower, maybe you can put a mirror lower on your bot, and point the camera at the mirror, so it sees the light through the mirror?
It was reasonably accurate up to ~133 (Where it was about 1.5 feet off) inches, not 200 as I previously (mistakenly) stated. And yes im sure it is inches.
Is there any observable problem with the algorithm?
With regards to the calculation of tangent, I am using a lookup table with values for angles between 1 degree and 90 degrees.
I’m going to try to get the target mounted higher up, but due to the fact that disregarding the gym, all our rooms have 7-8 ft high ceilings, it is going to be pretty hard.
Yes, you’re going to want to mount the camera as low as possible. As Ken pointed out, mounting the camera at the same height as the light will mean that the tilt angle will never need to change, which will prevent you from determining the distance. As the angular values I included in terminal.c are for the prototype pan/tilt mechanism I used, you should verify these values to wring-out the maximum accuracy from your particular pan/tilt mechanism.
I haven’t looked over the new camera stuff, but couldn’t you look at the bounding box and the X,Y components of the centroid? We didnt use a tilt servo last year, but were able to stop the bot consistently at a fixed distance away from the target by looking at the Y value of the centroid.
I wish I could say I used some kind of crazy NASA pico arcsecond-resolution measurement gizmo to calibrate the angular values I plugged into terminal.c. To be honest, at about 8:30 PM the night before the kick-off (last Friday), I finished the code and did a half-arsed calibration using my eight-year-old son’s cheezy protractor. Using the equation found in terminal.c, I would do another calibration <grin>.