Wow, that GeoGebra thing is pretty sweet!
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.
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. :yikes:
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.
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.
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.
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.”
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)
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)
Make a sticker we can put on the side of the shooter giving you some “props” for the research?
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 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.
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.
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.
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.
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.
Good programming and STABILITY are the keys.
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.