Ball Trajectory Planning

[waialua359]

Originally Posted by Ninja_Bait

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

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]

Originally Posted by 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??

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]

Originally Posted by JamesBrown

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]

Originally Posted by lcoreyl

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]

Originally Posted by 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??

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.

[SenorZ]

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]

Originally Posted by 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.

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]

Originally Posted by 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.

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]

Originally Posted by Michael Hill

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]

Originally Posted by lineskier

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

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

Originally Posted by lineskier

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

I'm not sure I understand what you mean

Originally Posted by lineskier

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.

Originally Posted by lineskier

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]

Originally Posted by 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.

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]

Originally Posted by lineskier

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

[Polaris395]

Did I hear someone say something about this problem being at the University level?

I think 2D kinematics will be sufficient, but hey, maybe that's just trying to build for an ideal world. I'll post this link in the other thread to make sure that people see it.