Shooter Aiming with Tables

[blueyoshi256]

Okay. You have a really cool idea. You want to be able to hit the target from any distance. This is a really tricky problem. First, you have to find the distance. Vision tracking is the common approach, and it sounds like you have an idea for how to do that, so I will skip it.

I think you can accomplish your goal without a table, but I can share how we "used" a table in 2013 too. First, without tables, but with some math ahead of time.
Start by turning it into a math problem. Relevant image found with some googling:

Your shot is a parabola with the vertex right over the center of the goal (because y-velocity is 0). This means that you need the horizontal distance to the goal from your camera (since vertical height can be calculated based just on your robot and the height of the goal off the ground). You can find this with basic trig using the distance to the center of the goal, and the angle of the camera. Great, so you know the coordinates of your parabola! On to the physics.
I was going to derive some of these in the post, but I realized I could google them, and found this wikipedia page. Look at the height at x category. We are going to be using this backwards. You know the x, y, y0, and g (think about gravity and robot height). You need an angle theta and a velocity v. Good news, there is a solution! Bad news, there are infinitely many solutions! Each velocity has a corresponding angle, and vice-versa. However, you can just pick one. I'd recommended picking a velocity, and using it for all of your shots. Once you choose one, solve the equation for theta, and you have your angle.

Okay, now for the tables. In 2013, we attached a camera to our shooter (which had angle control). This meant that as we went up and down, the center of the goal we saw changed. In addition, if we were further away, the goal appeared smaller in the camera, both the height and width. To figure out what angle we needed to hit from a distance (width), we manually found angles (center) that hit (5 of them), and then recorded the width and center of the goal for each. Table acquired!

Now for how to use the table. First, using a table in competition is mostly silly. A function is superior in every way. Just plug in some value, and get the result you need out. Functions don't care if your value happens to be off by a tenth. Plus, most functions are just multiplying a few numbers together (think y=ax^2+bx+c type function), and so will run faster. However, you can use your table to find a function to match it. For 2013, we ran a quartic regression (basically finding a,b,c,d, and e, given y=ax^4+bx^3+cx^2+dx+e). A computer can calculate this for you. The function took in the width of the goal as the x, and gave out the height of the center as the y. Even though we may only have recorded at 5 points, the function used those points to extrapolate in between. Note that 5 points are required to find a quartic function (quadratic only needs 3), and that the function always passes through all 5. We used the function in competition, and it was as accurate as our shooter.

Our exact 2013 setup might not apply to this game. However, the general idea still applies. You could use a table of successful points between two variables, and extrapolate a function. For example, you could use angle vs. goal distance, or rpm vs. goal distance.


In case this was way too long, the basic gist is that you can do the math and physics to find the angle you need, but you can also use a table of correct values to find a function for the variable you need. Functions don't take much time in competition, so using a table instead is probably more work than it is worth.