Shooter Aiming with Tables

[btcshields6]

Hello. First of all, I'm going to preface this with a few details about my situation. My team has never successfully integrated vision tracking or sensor data. This is our fifth year, my second. I am the only programmer/control systems person. We use labview. Unfortunately we do not have a programming or electronics mentor.

Those things aside, I am determined to put together a shooter that through angle actuation and rpm modulation is able to send a ball through the high goal from any distance with a final y velocity of 0.

I'd like a final y velocity of 0 so that the ball enters the goal flying straight, and therefore does not shorten the goal surface area (or lack of surface area).

So after a long conversation with one of our mentors, he and I determined that the code should accept an input distance from the vision tracking (not sure if this needs to be distance to goal or to base of goal), and give an rpm and an angle as an output to the shooter.

I figure that the best way to do this would be to use a calculator of some kind to find the values of rpm and angle required for every possible distance (up to a reasonable maximum) and feed those values to a table. Then the code could reference the table rather then have a calculator running constantly, eating up processing power.

I have several problems. Firstly, I don't know how to create a calculator to do this. I've looked at Ether's calculator (beautiful by the way), which outputs two distances (not necessarily with y velocities of 0) which you can fire from at an input speed and an input angle. Perhaps I can edit this calculator to input distance, and output rpm and angle. I don't know how to do that...

I also don't know how to create a table that labview can use, or utilize any sort of table in labview.

So, if you have any experience that could be helpful to me, either through this thread or through some direct messaging with me, please respond.

Thanks,

Benjamin

[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.

[ScottRhine]

I would keep a fixed velocity (max) and adjust the angle only. I can send you an excel spreadsheet. The angle for low goal is a uniform 5 degrees. From max range on the high goal, I recommend 30-35 degrees. At point blank on the high, 60-65 degrees.

[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.

[btcshields6]

So Ether, I'd like to be able to determine these experimentally, but due to some build constraints, I'm left without a shooter to test. For now. I'd like to start by getting a table of theoretical values. Is the only way to go about it using the stuff you described in your most recent post?

Solving this has got my coach and I (a physics teacher) scratching our heads.

[James Juncker]

If I could link you over to my post of ether's trajectory calculator with my additions to the base framework of it all, I gave perspective to the field as to where you would be shooting from and the distance as well as ideal shooter values http://www.chiefdelphi.com/media/papers/3217

The base equations didn't change however I put in a few approximate values of upper and lower gates where the boulder this year would go into the goal. the range finder has lines placed on the field for where the boulder would need to shoot from to get into the goal. if you work out the direct output from your mechanism to the ball for speed you could also then adjust the rpm for launch velocity. at the peak time on the sheet the Velocity in the Y direction should be equal to 0 and would allow for you to get the ball into the goal.

I would recommend as high of an entrance point into the goal so that if there are variations in power or rpm the boulder will still pass the plane of the goal.

[Ether]

Originally Posted by btcshields6

For now. I'd like to start by getting a table of theoretical values.

Solving this has got my coach and I (a physics teacher) scratching our heads.

It's not clear to me what you're having trouble solving.

In my earlier post I gave the formula for finding launch angle and launch speed, given the coordinates of the apex of the parabola (the horizontal and vertical distances xp & yp from the launch point to the center of the goal).

This assumes there is no air drag, so it may be quite inaccurate.

If you want to include air drag, you'll have to measure (or calculate) the relevant drag coefficients... or measure the terminal velocity of the ball.

And when you include air drag, I don't think there's a closed-form solution. You'd have to use numerical methods and iteration. Not hard to do, just not as straightforward as an explicit solution.

Does that help? If you still have questions, please keep asking until it makes sense.

[btcshields6]

Thank you. I think I misunderstood your earlier post.

I'll try again tomorrow and ask again if I get stuck and can't figure my way through.

Benjamin

[btcshields6]

We actually had a bit of a breakthrough today. One of our teachers figured out that if the apex is at the same height (the height of the goal remains constant of course), the y-velocity and time to the apex must be the same. If the y-velocity is the same, then we can enter it along with our other variables, and calculate the combined velocity, angle, and distance. Now we have a corresponding velocity and angle for each distance. We haven't factored in drag, and I'm not sure we will, since these values were just some estimates to get us ready for the experimental value.

But we're happy it's done. Thank you all for your help!

[Turing'sEgo]

The next step is to implement it on the robot. Hope all goes well!

http://i.lvme.me/dljyhoh.jpg

[Ether]

@btcshields6: If I'm reading your last post correctly, you're going to write some code using a lookup table based on no-air-drag computed values, and after that gather empirical data to populate the lookup table. Yes?