Ball Trajectory Planning

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

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/showthread.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.

projectile.c (7.09 KB)
Projectile_Motion_1~0.zip (7.1 KB)


projectile.c (7.09 KB)
Projectile_Motion_1~0.zip (7.1 KB)

[Bill_B]

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??

[waialua359]

I am growing more and more convinced that any kind of consistent shooter will be rendered useless by the thoroughly inconsistent balls. :mad:

This is why we believe the majority of this year’s challenge is a programming one.
No successful basketball player has one type of shot making ability from different areas of the court or with defense.
However, our robots are limited to being of one type, thus making it a bigger challenge for the programming folks vs. everyone else.

[lcoreyl]

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??

Definitely. Top teams will likely use this. You could do a more simple method (but possibly less effective) and instead of having the code drive, just have it alert the driver when they are in the correct spot.

I can’t imagine having a wonderfully repeatable 3 point shooter and then having drivers try to eyeball it from across the court.

[Grim_Tuesday]

Our team didn’t even consider drive controlled shooting as an option. Imagine the driver with little dials for pitch, yaw, velocity, etc… They would never get anything done on the field.

[lcoreyl]

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.

throwing a dodgeball as hard as you can is much faster than shooting from the key. Also, I think we can agree that the density of this year’s ball is much higher than a dodgeball.

[JamesBrown]

throwing a dodgeball as hard as you can is much faster than shooting from the key. Also, I think we can agree that the density of this year’s ball is much higher than a dodgeball.

There is a big difference between me throwing a traditional dodgeball (playground ball) as hard as I can and a 6 or 7 year old throwing a foam ball (simmilar in density to this years ball) as hard as he can (as described in my anecdote). The latter I am sure is much closer to the speeds we will be seeing in this game, and again I have observed the effects of drag on the ball.

[mwtidd]

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??

This is exactly what we did in 2006, and made it to the finals solely based on autonomous. In teleop we used the same function but because of defense we only able to score in teleop in a couple of matches. Where auto aiming will pay off is from anywhere where you can be incontact with they key, or close to the key. I have a feeling if you’re a few inches off the key, a robot will be hesitant to interact with you.

In 2006 we were shooting 10 balls in sequence for about the same range. We shot at about 8 or 9 for 10. This year is a tougher shot, but you are only shooting 2 or 3 balls so you will be able to be more consistent by taking one shot at a time.

My hope is to also make it better by providing feedback, so when the robot takes a shot I can provide feedback as to if it was too far, short, left, or right. Allowing it to learn and adjust similar to a player would if it had to take a similar shot again. Also it could auto adjust to a location it knows a little better. Similar to a player shooting from a familiar location, or a foul shot.

[Zook]

Good programming and STABILITY are the keys.

[lcoreyl]

Ok, I’m going to table the debate of whether drag and magnus are significant in order to clarify the second point I was trying to make: who cares?

remember the science lesson when you learned about accuracy vs. precision (repeatability)?

all the calculations discussed are concerned with accuracy; however, your FIRST concern should be building a shooter with very good precision!! drag and magnus won’t cause bad precision.
drag and magnus depend on speed and spin. If you build a shooter that always has exactly the same speed, angle, and spin, then there will be an “accuracy” error, but the ball will land in the same place each time. a few tweaks and you’re golden.

[Michael_Hill]

Ok, I’m going to table the debate of whether drag and magnus are significant in order to clarify the second point I was trying to make: who cares?

remember the science lesson when you learned about accuracy vs. precision (repeatability)?

all the calculations discussed are concerned with accuracy; however, your FIRST concern should be building a shooter with very good precision!! drag and magnus won’t cause bad precision.
drag and magnus depend on speed and spin. If you build a shooter that always has exactly the same speed, angle, and spin, then there will be an “accuracy” error, but the ball will land in the same place each time. a few tweaks and you’re golden.

Because teams will be shooting from different parts of the field requiring different speeds/angles/what have you.

Drag calculations can be very nonlinear even at speeds we may see in this competition.

[mwtidd]

Ok, I’m going to table the debate of whether drag and magnus are significant in order to clarify the second point I was trying to make: who cares?

remember the science lesson when you learned about accuracy vs. precision (repeatability)?

all the calculations discussed are concerned with accuracy; however, your FIRST concern should be building a shooter with very good precision!! drag and magnus won’t cause bad precision.
drag and magnus depend on speed and spin. If you build a shooter that always has exactly the same speed, angle, and spin, then there will be an “accuracy” error, but the ball will land in the same place each time. a few tweaks and you’re golden.

Your goals determine which is more important. A very precise robot is easier to defend, and more susceptible to problems. An accurate shot in this game has the opportunity to land in one of the other baskets. If you’re shooting from the key, I’d definitely agree with you that precision is critical, however from the open court, putting it in a vicinity may be better than being precise.

Shooting for THE hoops as opposed to A hoop is not necessarily a bad strategy.

[lcoreyl]

Because teams will be shooting from different parts of the field requiring different speeds/angles/what have you.

Drag calculations can be very nonlinear even at speeds we may see in this competition.

I see. I guess I hadn’t considered that teams would have the goal of being able to shoot from anywhere on the court. I was figuring for being able to shoot from the key, and from 1 particular spot on the opposite side of the court.

[lcoreyl]

It depends on what your goals are to determine which is more important.

You don’t have to choose between precision and accuracy.

A very precise robot is easier to defend, and more suseptable to problems.

I’m not sure I understand what you mean

from the open court, putting it in a vicinity may be better than being precise.

I’m assuming you mean a shooter that has GOOD accuracy and BAD precision MIGHT make it, where one with BAD accuracy and GOOD precision, WON’T make it. I agree, but I’m not encouraging the latter robot be built.

Shooting for THE hoops as opposed to A hoop is not necessarily a bad strategy.

That’s completely fine if this is your strategy, but why worry about drag/magnus? Say your software automatically compensates your expected landing spot by 2 feet; however, mechanically your margin of error is 10 feet. What’s the point there?

[Bill_B]

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.

Samuel, Thanks for posting this. Very neat way to visualize the basic trajectories involved this year. I was moving the backboard value and got a y-displacement doing it that altered the paths. Whoa, says I. Backboard distance should not alter the path, should it? Then I went on a search for a formula using y(backboard) - fruitlessly. Turns out that theta is defined as an angle involving backboard as a vector. I changed theta’s definition to be angle(V) and things look more reasonable now. But in case I missed something (neophyte geogebra-ist and all) I hope you can explain why you had theta defined the way you did.

[Frank_C]

This is exactly what we did in 2006, and made it to the finals solely based on autonomous. In teleop we used the same function but because of defense we only able to score in teleop in a couple of matches. Where auto aiming will pay off is from anywhere where you can be incontact with they key, or close to the key. I have a feeling if you’re a few inches off the key, a robot will be hesitant to interact with you.

In 2006 we were shooting 10 balls in sequence for about the same range. We shot at about 8 or 9 for 10. This year is a tougher shot, but you are only shooting 2 or 3 balls so you will be able to be more consistent by taking one shot at a time.

My hope is to also make it better by providing feedback, so when the robot takes a shot I can provide feedback as to if it was too far, short, left, or right. Allowing it to learn and adjust similar to a player would if it had to take a similar shot again. Also it could auto adjust to a location it knows a little better. Similar to a player shooting from a familiar location, or a foul shot.

This pretty much sums up where we’re headed. Design a consistent shooter (arc and distance) and shoot from the same spot (top of the key) with an auto-aimer with a swivel head (that will adjust for position of the target) and take a shot. I’m not sure we can design a program that will auto-adjust and “learn” as the tournament progresses… sounds very complicated to me, although we may have to manually adjust some parameters as the balls become more worn. Good luck!!