Ball Trajectory Planning

[DonRotolo]

Originally Posted by mikegrundvig

To that end, we need to know quite a few things starting with the ball diameter, density, and mass (does someone have the weight of the ball measured accurately?).

because determining the coefficient of friction for a pebbled surface seems exceptionally difficult.

Another potential nasty problem is the Magnus Effect.

Diameter is 25"/Pi
Weight is 302 grams +/- about 2% (based on an unreasonable sample size of 3)
Density can be calculated, and is not necessarily uniform.

Also consider that the surface WILL change as the ball gets used in a tournament.

The Magnus effect is NOT trivial nor can it be ignored, if your launcher imparts spin greater than about 2 or 3 spins per second. That spin also has a significant effect upon how the ball will bounce after it hits the backboard.

Originally Posted by mikegrundvig

no need to over-complicate it.

Right. Use the match for a first order estimate, and go empirical from there.

BUT, understanding all those variables will come in handy when you try to solve any problems with variability of your trajectory.

[SenorZ]

Ball diameter ~ 8"
Hoop diameter ~18"
That is some serious leeway for close shots, but a little tighter percentage-wise for shots from the top of the key and beyond.

What I would do, and will attempt to for my kids, is implement the solution to this set of equations:

y = height difference from launcher to hoop
x = horizontal distance from launcher to hoop center
a = angle above horizontal for launcher
t = time in air
g = accel of gravity

y = v*sin(a) - 0.5g*t^2
x = v*cos(a)*t

If you know y, and g, you can substitute and solve to eliminate t. Then the two variables are x and a. The analytic solution is, well, ugly, and you'll need a computer to assist, but if you enter values it is a bit easier.

[slijin]

I made this for my team (you need GeoGebra to run it), which basically simulates projectile motion of the ball (ignoring all other factors). You can drag around V to shift the muzzle velocity and firing angle, as well as Height and Backboard to modify distances. Everything is considered relative to the point of release. There are obvious problems with it, but it does provide a nice model for the basic concepts here.

[guymon]

Simple Ballistic Calc

http://inceptus.org/calc.html

[mikegrundvig]

Wow, that GeoGebra thing is pretty sweet!

[AlDee]

Originally Posted by mikegrundvig

This paper says drag through the air on a full size basketball is negligible:
http://www.phys.ubbcluj.ro/~evintele...na/Baschet.pdf

But then it gets shot down a bit here:
http://www.wired.com/wiredscience/20...n-basketballs/ You can see in the graph at the end here that air drag has a huge impact on a baseball:
http://wps.aw.com/wps/media/objects/...cs/topic01.pdf

-Mike

I believe the ambiguity around the significance of the drag on the basketball vs. the baseball has to do with the density, size and speeds that they are being thrown at.

As an illustrative example imagine a two bowling balls dropped off a tall building. the first weighs 16 pounds, but the second has been hollowed out to weigh only 6 ounces. The exterior surfaces are the same. Neglecting wind resistance, both should hit the ground at the same time since gravity accelerates at -32ft/s^2, however in practice the heaver ball will land first. The aerodynamics of both balls are the same, but the added mass of the heavier ball will over come more drag.

With that said, I tend to agree with others here, that it's good to use math and physics, but my approach would be to keep the math as simple as possible, and build a mock up to see how well your physical results match your theoretical ones.

[engunneer]

I missed this thread earlier when I was looking for places to post my spreadsheet, so I made a new thread instead. I hope it doesn't fracture the conversation too much.

I wanted to share a spreadsheet I made with CD. It helps with calculations for the ideal projectile in a variety of circumstances. Most importantly, it helps with the case of a fixed-velocity varying-angle shooter, as well as other cases. Please see my blog post about it: link. The file is about 12KB too large to post directly here.

It doesn't take the drag into account, but will give an order of magnitude for different situations. It also tells you how much variation in your velocity or angle there would be between each of the hoops, so there is an indication of how much tolerance there is on the velocity or angle.

The formula for predicting the angle of a shot given a range and an initial velocity is non-trivial when you add in the height of the shooter and the height of the basket, so I have a macro doing iterative loop to calculate those values.

[JamesBrown]

Originally Posted by lcoreyl

The engineer in me says 2 things:
1) speed is a factor in how much drag comes into play. I don't think you're going to be approaching baseball speeds unless you're going for the robot that parks in the alley, receives the pass and chucks it full court (if you are--bravo!).
.

I agree that teams won't be approaching baseball speeds but a baseball is also significantly more dense than the basketball in the KOP.

I don't have any math to back myself up but 6 years of playing dodgeball with 6-8 year old kids at a summer camp tells me that even at low speeds drag effects the trajectory of a foam ball. I am sure that people involved in 2006 would back up this anecdotal evidence.

[Dan.Tyler]

Originally Posted by shuhao

Using the viscosity of the air, I'm able to estimate the resistive force on the sphere (since it is a sphere, it makes this calculation much simpler instead of using the drag calculations.. which is okay, but i just prefer this one).. at 10m/s you will encounter significant drag.

But, it's NOT a sphere. The little bumps? They change the boundary layer behavior and aerodynamic effects.

This both increases the effective diameter of the ball and changes every other aerodynamic factor. The bumps will act to actually REDUCE overall drag by reducing pressure drag significantly; but it increases skin friction drag which increases the affect of most aerodynamic forces, including magnus effects. (same way that the little holes in a golf ball work... increase range, make it harder to remain accurate).

Just saying... if you want to be ultra accurate, you're forgetting some stuff.
And to anybody that thinks it won't end up coming down to testing and evaluation... well... good luck with that. Most of these simple equations are made with some extreme aerodynamic simplifications that will introduce an error of 10-25% in your calculations anyways.

Drag WILL be important. Magnus effect MIGHT be (depends on your launching mechanism). Being able to adjust your scaling factors (you should definitely have these) on the fly, mid-match, will probably be a nice thing to have.


I'd give you the math... but you either wouldn't understand it, or already know it.

[Tom I]

I think the general agreement by most is that the math is VERY complex if you include all the contributing factors, but in reality it's not that important in the long run. I think teams should definitely put thought into the trajectory of their throwers, but anything beyond simple kinematic equations is going to be wasted effort. I think the quote from Ian Curtis put it best,

Entire books have been written on drag, but FIRST robots tend to operate pretty well on the back of a napkin.

Rather than worry about every little detail that could potentially throw off a throw, people need to realize that this game, by it's nature, is going to be full of variables. Heck, the balls are going to get sliced up, no doubt, so that right there is going to throw off any calculations of drag. The best thing to do is to do basic calculations to get a good idea, then build a shooter that is consistent, and try to get as accurate as you can but accept the fact that there will always be percent error. The old expression goes "measure with a micrometer, mark with chalk, cut with an ax."

[Dan.Tyler]

Originally Posted by Tom I

I think the general agreement by most is that the math is VERY complex if you include all the contributing factors, but in reality it's not that important in the long run. I think teams should definitely put thought into the trajectory of their throwers, but anything beyond simple kinematic equations is going to be wasted effort. I think the quote from Ian Curtis put it best,

Rather than worry about every little detail that could potentially throw off a throw, people need to realize that this game, by it's nature, is going to be full of variables. Heck, the balls are going to get sliced up, no doubt, so that right there is going to throw off any calculations of drag. The best thing to do is to do basic calculations to get a good idea, then build a shooter that is consistent, and try to get as accurate as you can but accept the fact that there will always be percent error. The old expression goes "measure with a micrometer, mark with chalk, cut with an ax."

I'd have to fervently agree with the sentiment here.

But, some people still like to do the math. So I thought I'd hand over a few more tidbits of information like the word "boundary layer" to open a world to as much math as they could possibly want (and the realization that all the math in the world can't describe how air behaves)

[Michael Hill]

See this thread: http://www.chiefdelphi.com/forums/sh...ad.php?t=99485

[kws4000]

I cooked this program up a while ago... more like more than a year ago, and I'm not sure how it still works, but it does. Based entirely on the metric system, uses meters/kilograms/seconds/degrees/jouiles/etc std SI units.

I planned on making it able to work backwards using given variables but never got that far. Feel free to edit, compile and post. Executable in the zip, scource in the .c file.

[Bill_B]

Originally Posted by mikegrundvig

Heh, thanks. I'm trying to get this whole cooperation thing though it goes against my extremely competitive nature

Make a sticker we can put on the side of the shooter giving you some "props" for the research?

[Frank C]

My thought is to build a (reasonably) consistent shooter and then trying to create an "auto mode" (similar to autonomous) where the operator, once he has the robot in range of the targeting system, could let go of the stick and put the bot into auto so it can position itself and shoot the ball... is that possible??