First and foremost, I am not by any means a “white paper” technical writer, and I dont intend for this to be conveyed in that way.

I have came across a method that has worked for my team to approximate distance that doesn’t involve having to know the height difference or anything like that and might take you 10 minutes to generate data for. The beauty of this method is sometimes the bounding rectangle around teh vision targets can be higher or lower than the actual height… so this can account for that as opposed to the usual method (triangulation and such). This equation requires pixel angle (“ty”) as an input and outputs distance (just use meters for everything, it’s so much easier). In order to make the equation, mark off distances from the target for the front bumper of your robot to touch (you can use feet here, but convert it for your data), then add in the distance from the front of your bumper straight back to your limelight. At each distance (distance to bumper plus to limelight), record the pixel angle (“ty”) (assuming your limelight is horizontal) at each distance. You should have several distances with their respective angles, all with the center of the crosshair lined up, this is imperitive, explanation in a moment. A quadratic regression fits this data best, using pixel angle as input and distance as output. You should get an r^2 of above .9, but it can be extremely accurate, I’ve had ~0.98 before. You will then need to divide this calculated value by the cosine of the negated horizontal angle (“tx”) so that when not centered, you still get the corect straight line distance (when you eventually get to shooting while moving, you wouldn’t be centering yourself on the target, so it gets more important). I suggest inputing this as a lambda function in your program so that any pixel angle can be converted to a distance based of the function. All of this is in our code, sorry if it’s no well documented yet, we are working on it.

More common, we use a similar style of data to then determine the desired RPM of our launching mechanism. at each distance, using smartdashboard, we command the launcher motor to go a a specified RPM until we find the projectile acceptable, then moved to the next distance and record the RPM for each distance. This data will have distance as input in meters and output as RPM of the motor (or the output shaft, you have to convert the RPM to counts per 100ms anyway, so you could just add in a gear ration if you have one). The best fitting equation is a logarithmic regression. Use natural log (“ln”) and calculate your coefficients. Same as the pixel angle to distance function, use a lambda function for this in your code would be the easiest and most understandable implentation in your code.

At this point as long as you can target on the center of the of the target you can calculated your distance which then can be used to calculate your RPM. Has this been explained before in many ways? Yes. Is it sometimes best to have just one more look at it from another view point? Also yes.

As always, this is the best I’ve found for my team, take it with what you will. I will be posting again shortly with the method for launching projectiles while the robot is in motion, it’s actually quite simple, it just takes some time to think about. Im with Team 3534 and here is our current code. (the main branch does not have a lot of the further updates, it will soon, look in the 1.5 branches).