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.
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.
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.
You don’t have to choose between precision and accuracy.
I’m not sure I understand what you mean
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.
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?
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.
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!!
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.
My team was actually planning on having a camera track the target, direct the turret to that target, use a laser rangefinder to determine distance, and have the turret adjust velocity and angle to adjust for that range. So, yes, some teams were planning on being able to shoot from anywhere.
We want to be able to get balls in the vicinity of the hoops from our player station, across the field, and were planning on a 70fps+ muzzle velocity. does that seem fast enough to range 55’?
With a intitial velocity os 12m/s teams were able to shoot at a higher target from half court in 2006 with a ball of similar density, 70f/s should get you the whole way across the field. Keep in mind it will not be easy to shoot that far accuratly, and the faster you shoot the more effect drag has on the ball.
If you do the math, at 45-degrees, neglecting drag and air resistance, you would need to be going about 40ft/s to shoot 50ft. Probably going to need a little more to hit that top hoop.
I really don’t think the variable here is the drag though. You can calculate for that, sure. But after the first match, the majority of balls are going to be ripped, torn, and not appropriate for your calculations.
Keep the calculations simple, like everyone is saying. Going for a consistent shooter is the best you can really do. Doing the 2d physics is plenty because after that you are throwing in variables that are going to change after every match.