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.

[Ether]

The shot is a parabola only if you neglect air resistance.

Does anyone have a good number for the terminal velocity of this year's ball? If so, you can use this trajectory calculator (ignore the green lines).


If you want to hit the goal at the trajectory's apex at different distances from the goal, you can't pick one wheel speed and use it for all shots. For a given desired distance to and height of the apex, there is a unique launch angle and launch speed solution.


Shooter consistency is going to be your number one challenge. Consistency will be affected by:

- errors in measurement of distance to goal

- errors in setting and maintaining a wheel speed

- errors in setting a launch angle

- variations in ball weight, size, compressibility, elasticity, and surface texture

If you can solve the above problems, then using a lookup table is likely the most straightforward and accurate approach.

Experimentally determine the proper angle and wheel speed for each distance from the target and put it in the table.

You have a big challenge ahead of you. I hope you are successful.

[Turing'sEgo]

You are given one variable, distance, and want to find 2 output variables, power (wheel speed) and angle. So, you really have two problems you want to solve. At distance d: what angle does the shooter need to be at? What power does it need to be at?

You can solve this problem via regression. Get a bunch of data points, and fit a function to it in excel or a similar program. Then, put the regressed equations into your program. In the end, you would have 2 equations, one that solves for angle and another that solves for wheel speed.

It isn't a table, but it does the same thing and is easy to program a basic math function.

[Ether]

Originally Posted by Turing'sEgo

You are given one variable, distance, and want to find 2 output variables, power (wheel speed) and angle.

No. You are given two values: the horizontal distance to, and vertical height of, the apex relative to the launch point.

From that information, you can directly compute the parabolic (no air drag) launch angle and speed.

It's all explained here.

For coordinate system XY whose origin is at the launch point,
the equation for the parabola is:

y = a*x^2 + b*x

Let the (known) apex coordinates in XY be [xp,yp]

then

a = -yp/xp^2
b = 2*yp/xp

So now you know the equation of the parabolic trajectory,
and from that you can find the launch angle theta and launch speed V:

theta = atan(b);
V = sqrt((g/2)/a)/cos(theta);

It's good to be interested in this stuff and to learn it, but for the immediate task at hand it may not be so useful. See my previous post explaining why.

[blueyoshi256]

Ether is right. I was trying to oversimplify the physics.
However, the second possibility I suggested (which Turing'sEgo described far more clearly would accomplish something close to what you want. If you remove the criteria that it has to pass through the center, and use a single velocity, you can compare goal distance (diagonal) and shooter angle, and run a regression. It will not always be quite as nice a shot, but if you grab enough data (angles and distances that you hit at), the regression will basically mirror a table of the data. It does not use variation in velocity, and it will not hit at the exact vertex every time. However, this regression did work for us in 2013, and is a poor man's alternative to the calculations that Ether is describing.

[apalrd]

Originally Posted by blueyoshi256

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.

Not sure why you would say this, but a well implemented table is way easier to modify/generate than a function.

For a function, if you want to 'recalibrate' based on test shots, you have do do a bunch of shots, and then make a huge list of inputs vs outputs, and generate a curve fit somehow (probably in Excel or something similar). If you used a table, and aren't trying to extrapolate (interpolate only), you should be able to just type the test shots into the table and allow the software to solve for the outputs.

A table also allows you to manually tweak individual points that don't follow the regressed equation well, since it's likely that points on the extreme might not follow the trend, without adding too many dimensions to the function and resulting in overfit.


Lookup tables used like this are extremely common in industry. The simplest tables are made up of a sorted vector of the inputs and a paired vector of the outputs. More dimensions can be added with multiple sorted vectors of inputs and a matrix of outputs. The output is interpolated from the nearest points to the input values.