Calculating Angle to fire at

[Issues]

Ok I don't know why but I am kind of stumped as how to calculate the angle needed to fire at a targed x meters away that is y meters above the launcher when your robot is capable of firing at v meters per second.
From the kinematic equations
y= -0.5*g*t^2+v*sin(theta)*t
x= v*cos(theta)*t

t=x/(v*cos(theta))

Now I plug that into the first equation which is dandy but then I cant isolate theta... It is rather easy to do when the beginning and ending heights are the same. Maybe I need to brush up on my trig but this is as far as I get
y= (-g*x^2*sec^2(theta))/(2*v^2) + x*tan(theta)

Help would be appreciated

[mechanicalbrain]

Here are some formulas. http://www.ngsir.netfirms.com/englishhtm/ThrowABall.htm goole "projectile motion" and remember to calculate air resistance in your equations! :)
Also good guides:
http://hyperphysics.phy-astr.gsu.edu/hbase/traj.html
http://www.ac.wwu.edu/~vawter/PhysicsNet/Topics/Vectors/ProjectilesMotion.html

[chris31]

I havent got around to looking at formulas becuase i dont have the camera code finished becuase i dont have the camera with me. Once i do, ill post the formulas that i used.

[Hutch]

Well once you get air resistance (which is significant with these) along with any spin, those equations don't quite cut it; some sort of expirementation and creating just an n-th order polynomial approximation might be better (that maps some parameters [distance, angle of camera, power, whatevever] to angle).

Anyhow, my TI-89 doesn't give me anything for those equations so perhaps if I have time in a little bit, I'll solve it by hand.

[Issues]

I understand all of those things are important, but first I need to figure out how to calculate it simply right :) . Plus do you think experimenting and finding out the average spin of the projectile will help all that much? Won't it vary a lot from launch to launch?

[Hutch]

I meant experimenting to find the coeffecients... Anyhow, it depends on how you design your mechanism - I know we are trying to come up with something that will give predictable spin for example. Air resistance is probably more important than spin though and would be something to consider if you have anyone on your team who can run the numbers.

Btw, now that you have the links to the projectile motion equations, would you still like me to solve those equations or do you have what you need?

[mechanicalbrain]

Also something to keep in mind. Your velocity is not going to be constant (assuming you use a motor to propel the ball) Since your motors power will continue to decrease as the battery drains. As I recall every year their are teams that will drain the entire battery in a single match. I would highly recommend using a Hall effect sensor to monitor your levels and integrate the equations for you motors power into the equations. Also Spin has the potential to really change distance and should be a variable in your equation.

[Alan Anderson]

Your velocity is not going to be constant (assuming you use a motor to propel the ball) Since your motors power will continue to decrease as the battery drains.
If you measure the motor speed, you can make the velocity be constant. Battery voltage will only be relevant if you're trying to make the motor go faster than the available battery power will permit.

[Donut]

Something I just thought of about an hour ago that you might also want to consider. It still needs to be calculated, but rather than changing the angle (as most everyone on here has said they plan on doing) that the ball is released at, why not keep the angle constant and vary the speed at which it leaves the robot? It gives you the same desired effect, and saves you one motor or servo (and who knows how much weight).

This is going to take alot of testing to get right. Air resistance you could factor in, but spin will be hard to, especially if/once balls start getting deformed from extensive use (eventually this form is going to squish!). Deformations can also effect how much contact the ball will have with the launcher and change speed.

[Elgin Clock]

I found a nice tutorial for projectile motion here:

http://www.physicsclassroom.com/Class/vectors/U3L2f.html

Using the equation in the example involving this question, you can find some nice info:

A football is kicked with an initial velocity of 25 m/s at an angle of 45-degrees with the horizontal. Determine the time of flight, the horizontal displacement, and the peak height of the football.

Horizontal displacement is the info which would be most valuable, along with max height. Time is nice to know, but unless you are calculating how many you can shoot in a match, then it's not really relative.


And if you want to cheat, and use the max allowed velocity here (12m/s), and know how much the mass of the balls are in KG's you can use this.

http://galileo.phys.virginia.edu/classes/109N/more_stuff/Applets/ProjectileMotion/jarapplet.html

[DonRotolo]

I understand all of those things are important, but first I need to figure out how to calculate it simply right :) . Plus do you think experimenting and finding out the average spin of the projectile will help all that much? Won't it vary a lot from launch to launch?
Come up with some basic aiming equations, and then refine them with experimentation. A look up table might be faster to do (and execute). All you need (for now) is the launch velocity, assume 12 m/s (the max allowed). Camera angle to the target gives distance.

Be sure to impress upon the mechanical design team that variability in the launch velocity is VERY bad, they need to consider that in their design. (I think you will find that the variability is really not much, assuming the system is designed to be stable.)

Now, also remember to consider the added velocity if the robot is moving!!!

Don

[DonRotolo]

This is going to take alot of testing to get right. Air resistance you could factor in, but spin will be hard to, especially if/once balls start getting deformed from extensive use (eventually this form is going to squish!). Deformations can also effect how much contact the ball will have with the launcher and change speed.
Easy: use the Allen-Bradley sensor to measure the velocity, keep track of it and use it to make corrections on your next shot.

But, IMHO, angle will be easier than variable velocity. Not a bad idea, tho.

Don

[White_Orpheus]

This equation doesn't incorporate air resistance or spin, but it'll work for approximating. I have a sinking feeling that there isn't a way to do it with all the variables without forcing the controller to do a numerical integration every time you want to shoot the ball

(theta1)= the angle to the goal from the same height as your cannon
(theta2)= the angle of your cannon
(h)= height from your cannon to the goal (constant)
(v)= velocity of your ball (constant)


1/(v^2) = (tan(theta2)cos^2(theta2)/4.9h(cot(theta1))) - (cos^2(theta2)/4.9h(cot^2(theta1)))

It could use some simplifying, and it looks really ugly typed like that, but it works. I like this equation better because rather than accounting for distance to the goal, you only need the angle. I have a feeling the CMU cameras will be more accurate at giving the angle they are pointing at rather than giving a distance to the target.

[bombadier337]

For simplicity's sake, we are most likely going to have a shooter with a fixed vertical angle. We may lose the ability to shoot from every point on the field, but if we no where our good positions are we can increase our accuracy. We are simply having an adjustable angle (like that on a LCD projector, though a little more substantial and stable), so we can tweak it before competitions to fine tune it. Just my $0.02

Also, using the y axis signal from a camera set to lock on to the green target could simplify that a lot. You'd just need a formula to convert it to something usable for a lifting mechanism and compensate for an arc.

[varcsscotty]

OK! something really funny just happened. I was working on these trajectories and having quite the frustrating time with them....
In walks my brother with the comics section of The Oregonian newspaper. He tells me to read the Foxtrot comic, so I do. And what do I find? I find the Foxtrot dude doing equations to calculate the trajectory of a snowball. That made my day! So I got the equations now...heeheehee

[artdutra04]

Now I know that all those hours I seemingly "wasted" in middle school playing Pocket Tanks (http://www.blitwise.com/ptanks.html) has finally come to some use! And all my teacher's never believed me when I told them that learning how to calculate ballistic trajectories on the fly and in my head would become an important skill someday. :rolleyes:

[EOC]

It seems to me that there are so many factors(air resistance, spin, etc.) that are not in standard projectile equations that calculations won't be very useful. Experimentation will be required.

[Rick TYler]

It seems to me that there are so many factors(air resistance, spin, etc.) that are not in standard projectile equations that calculations won't be very useful. Experimentation will be required.

I was trying to explain to a teammate that the US Navy has been calculating ballistic trajectories for at least 150 years, and even with their experience they still frequently miss on the first shot. If you don't combine your math with experimentation and the ability to fine-tune shooting angles at the competition you are probably going to have troubles hitting the goal.

[Brokoro]

Here is an old equation i used a looong while back... see how you like it...

(It's a very simple equation)

V= Ft/s
A=Angle of take off

(-16/V^2 *((CosA)^2)*X^2) + (X(TanA))

Though this is a great equation, I'd would only use it in approximation. It is very simple and can be done by hand but is meant to be seen on a graphing calculator. So I hope this helps for the newcomers.

[Eldarion]

Here is an old equation i used a looong while back... see how you like it...

(It's a very simple equation)

V= Ft/s
A=Angle of take off

(-16/V^2 *((CosA)^2)*X^2) + (X(TanA))

Though this is a great equation, I'd would only use it in approximation. It is very simple and can be done by hand but is meant to be seen on a graphing calculator. So I hope this helps for the newcomers.

All that is is the standard position equation with the trig to split an angle up into its component vectors. We need to be able to compute the desired angle, given speed and range, which I don't think that equation can do. :)

[Kevin Watson]

It seems to me that there are so many factors(air resistance, spin, etc.) that are not in standard projectile equations that calculations won't be very useful. Experimentation will be required.Air resistance at these velocities can be effectively considered to be zero. Spin stabilization of projectiles is done to decrease the effect of orthogonal forces like wind. I would just stick with the projectile motion equations, which should work just fine at these velocities and distances.

BTW, I've seen a 'bot that can use the camera to position itself and fire ball after ball into the target, so I know that teams can do it if they put the effort into it.

-Kevin

[Kevin Sevcik]

Air resistance at these velocities can be effectively considered to be zero. Spin stabilization of projectiles is done to decrease the effect of orthogonal forces like wind. I would just stick with the projectile motion equations, which should work just fine at these velocities and distances.

BTW, I've seen a 'bot that can use the camera to position itself and fire ball after ball into the target, so I know that teams can do it if they put the effort into it.

-Kevin

Using your standard Fd=1/2*Cd*rho*A*v^2, I get a drag force of over 1N. On a 183 gram ball, it works out to an additional 6 m/s^2 deceleration. Is that really negligible?

Assumptions: Cd=0.5, rho=1.29 kg/m^3, A = (7/2)^2*pi in^2 = 0.025 m^2, v=12 m/s

I know it's not as significant as if we were firing ping-pong balls, but I don't think standard ballistics will give much accuracy without a large fudge factor.

[Kevin Watson]

Using your standard Fd=1/2*Cd*rho*A*v^2Hmmm, while we're picking nits, is your assumption that Cd = 0.5 a good one? 0.5 is worst case for a smooth sphere with perfect laminar flow over the surface. These balls are more like golf balls, which produce quite a bit of turbulence behind them, which can drop the Cd by at least half. Also, your drag force assumes a constant velocity. Is this really the case?

I guess I should have said that the effects of wind resistance should be ignored. Discussing drag coefficients and the Reynold's number of a nerf basketball is silly and will only serve to confuse people, who might get turned-off to the idea of going for the three point score.

-Kevin

[kmcclary]

OK! something really funny just happened. I was working on these trajectories and having quite the frustrating time with them....
In walks my brother with the comics section of The Oregonian newspaper. He tells me to read the Foxtrot comic, so I do. And what do I find? I find the Foxtrot dude doing equations to calculate the trajectory of a snowball. That made my day! So I got the equations now...heeheehee Here's the comic: http://www.ucomics.com/foxtrot/2006/01/08/

Enjoy!

- Keith

[Kevin Sevcik]

Hmmm, while we're picking nits, is your assumption that Cd = 0.5 a good one? 0.5 is worst case for a smooth sphere with perfect laminar flow over the surface. These balls are more like golf balls, which produce quite a bit of turbulence behind them, which can drop the Cd by at least half. Also, your drag force assumes a constant velocity. Is this really the case?

I guess I should have said that the effects of wind resistance should be ignored. Discussing drag coefficients and the Reynold's number of a nerf basketball is silly and will only serve to confuse people, who might get turned-off to the idea of going for the three point score.

-Kevin

I will grant you all those points. I didn't really want to pull out my fluid dynamics book or anything. I've got a quick and dirty spreadsheet I'll be posting later tonight to help out any teams lacking in physics. I'll probably settle on a .25 Cd as a good compromise, .5 was just the first that popped to mind. It should give teams a second more conservative datapoint to judge from.

Edit: Predictably, 12 m/s puts the Reynold's number right in the critical range for a rough sphere where Cd drops a ton depending on the roughness of the sphere. At 10 m/s the Cd is comfortably 0.5 for most roughnesses. So go figure. It's still an estimate, but it will err on the side of shorter than reality.

[Yan Wang]

So ignoring the fun stuff (air resistance, spin), suppose your ball's point of release is at the origin with velocity v0 and you want to hit the point (h,k) in the first quadrant. I quickly found a cubic equation which you can solve for theta. I'm sure you'll have fun learning how to solve cubics. Let me know if there's some algebra error. The general idea seems right.

[Matt Adams]

Ah, I love the lunch break. If this is correct, which I'm pretty sure it is, I'm proud to say I did it myself. if it's not, then you get what you paid for. :]


Given:
X (desired position in horizontal direction),
Y (desired position in vertical direction)
Vo (firing velocity)

Find: Launch Angle, A

Starting with your two basic projectile motion equations:

X = Vo * cos(A) * t
Y = Vo * sin(A) * t - 1/2 * g * t^2

First, solve for t to eliminate it from the equation.

t = x / (Vo * cos(A) )

Substituting:

y = (x * Vo * sin(A)) / (Vo * cos(A)) - (g * x^2)/(2 * Vo^2 * cos^2(A))


Trig Identity: tan(A) = sin(A) / cos(A)

y = (x * tan(A) ) - (g * x^2) / (2 * Vo^2 * cos^2(A))


(x * tan(A) - y ) * (2 * Vo^2 * cos^2(A)) = g * x^2

(2 * Vo^2 * x * sin(A) * cos(A)) - (2 * Vo^2 * cos^2(A) * y) = g * x^2


Simplify some more:
(2 * x * sin(A) * cos(A)) - (2 * cos^2(A) * y) = (g * x^2) / (Vo^2)

Fancy Trig:

(x * sin(2A)) - (2 * cos^2(A) * y) = (g * x^2) / (Vo^2)

Little More Fancy Trig:

(x * sin(2A)) + (-y)(1+cos(2A)) = (g * x^2) / (Vo^2)

Not So Fancy Math:

(x * sin(2A)) + (-y * cos(2A)) = (((g * x^2) / (Vo^2)) +y)


Pretty Fancy Trig Identity: (if there's a mistake, it's bad application here!)
a * sin(A) + b * cos (A) = sqrt(A^2 + B^2) * sin(A + T)

Where T:
arctan(b/a) if a>=0;
pi + arctan(b/a) if a<0

I simplified this with the common(?) matlab function atan2 which is a 'smart' arc tan function that takes the sign of the x and y components into account when returning an angle.

Note, however, that since A in our case is X, it should never be negative, assuming you're aiming in front of you...


Using Pretty Fancy Trig Identity Above:

sqrt(x^2 + y^2) * sin(2A + atan2(-y/x)) = (((g * x^2) / (Vo^2)) +y)


Finally, when you put this in terms of A:

A = 1/2 * (asin( (((g * x^2) / (Vo^2)) +y) / sqrt(x^2 + y^2) ) - atan2(-y/x))


The reason I feel pretty comfortable about this, because when you set Y=0, you get your basic range equation:

2A = asin(g * X / Vo^2))

That's that!

Sources:
http://en.wikipedia.org/wiki/Trigonometric_identity
http://hyperphysics.phy-astr.gsu.edu/hbase/traj.html



Matt

[Issues]

That is precisely what I was looking for, if it is correct anyways. I knew it would require some mad trig. Thank you = ).


edit.

Now I am trying to add air resistance in the calculation. I think the easiest way to do it would be to determine the terminal velocity of the poof ball and use that with a known weight of a projectile to find the proportionality constant of a poof ball k such that F= k v(y) beacuse the force of air resistance is proportional to speed right? and this k would be the same one to use for the x direction because it is a sphere. Has anyone experimentally determined this value of k? I guess I could try something with my schools logger pro stuff =)

[David Brinza]

Here's a "quick and dirty" Excel spreadsheet that allows the user to vary speed, angle, height, drag coefficient, and for the Mars version of AimHigh (special feature for Dave Lavery ;) ): air density and gravity.

The algorithm is based on the white paper found here:

http://wps.aw.com/wps/media/objects/877/898586/topics/topic01.pdf

I made sure the integration gave accurate answers for some test cases (verify max height for vertical shot with zero drag coefficent, etc.).

The user should be able to perform some "sensitivity analyses" on parameters like speed, drag coefficient, etc. to get some idea of how the trajectory is affected by changes in the various parameters.

You can answer: How much further does a new (low drag) ball fly in Colorado than a beat-up (high drag) ball at the Florida Regional? :cool:

[Alan Anderson]

You can answer: How much further does a new (low drag) ball fly in Colorado than a beat-up (high drag) ball at the Florida Regional? :cool:
The answer depends on whether you take spin into account. A rough ball gets better loft from backspin than a smooth one does (that's why golf balls are dimpled).

[seanwitte]

Why so complicated? Build your shooter and iterate through the ranges, keeping track of the shooter launch angle and camera tilt servo position. Then all you have to do is look up the value for the shooter angle based on the camera tilt servo and forget about the range. You can use a joystick button to add a fixed offset to adjust in realtime if something changes on the field and it starts missing.

When I tested the camera code I could only get about 20' away before the trackable pixel area becomes too small. At 6" increments your lookup table is only 40 entries long.

[KenWittlief]

I agree with Sean. With so many variables in the system the only sane way to approach this is by testing your shooter, and averaging the results for each angle or distance or launch velocity, then using a look up table for each distance (or angle)

and if possible, only allow your launcher to vary one setting (angle or launch velocity).

Rick had a good point. In the real world military pilots let the computer do all their magic, they pull the trigger, then they use a joystick to walk the rounds into the target.

Even an A10 warthog with its computer controlled targeting system cannot hit a target 1 mile away with the first round (bullet).

[varcsscotty]

it's not the only way trust me....

[X-Istence]

While I agree that a table lookup would be a lot easier, why not go all out this year, and use the CPU that was given to you, and calculate on the fly. I know that is what my team is doing. While a hash table would be fast, it would be less accurate, and we are personally looking for going for the perfect bullseye at least 60% of the time.

[KenWittlief]

While I agree that a table lookup would be a lot easier, why not go all out this year, and use the CPU that was given to you, and calculate on the fly. I know that is what my team is doing. While a hash table would be fast, it would be less accurate, and we are personally looking for going for the perfect bullseye at least 60% of the time.

the reason for using a lookup table is something they don't tell you in college. The real world in not linear. There IS no equation for the trajectory of a foam ball through the air for different angles, launch velocities or distances.

You can come up with equations that approximate what the foam ball will do when you launch it from your robot, or you can test fire the mechanism several times, record the results, and know exactly what it will do as each variable in your system is changed.

No matter what equation you use, your going to have to test fire your launcher to get its actual parameters, so you have to go through the same procedure anyway.

but once you test fire your launcher over its range of settings, and measure the results, you now HAVE the answers to the equations you need to write. At that point why calculate the answers each time you fire the launcher? you already measured the results during testing.

besides, a lookup table in SW takes 2 or 3 simple instructions to execute. You add a variable to the table start address, and read the answer from that memory location.

Trig functions on a microprocessor can take hundreds of instruction cycles to calculate.

"everything should be as simple as possible, but not simpler" -Einstein

[Salik Syed]

I think we may also end up using the same method... collecting real life data.
Calculating it is less accurate due all the real world factors that are out of control and too hard or random to factor in(friction, spin etc.)

[X-Istence]

the reason for using a lookup table is something they don't tell you in college. The real world in not linear. There IS no equation for the trajectory of a foam ball through the air for different angles, launch velocities or distances.

You can come up with equations that approximate what the foam ball will do when you launch it from your robot, or you can test fire the mechanism several times, record the results, and know exactly what it will do as each variable in your system is changed.

No matter what equation you use, your going to have to test fire your launcher to get its actual parameters, so you have to go through the same procedure anyway.

but once you test fire your launcher over its range of settings, and measure the results, you now HAVE the answers to the equations you need to write. At that point why calculate the answers each time you fire the launcher? you already measured the results during testing.

besides, a lookup table in SW takes 2 or 3 simple instructions to execute. You add a variable to the table start address, and read the answer from that memory location.

Trig functions on a microprocessor can take hundreds of instruction cycles to calculate.

"everything should be as simple as possible, but not simpler" -Einstein

Ah, I knew I was missing something. I see why a lookup table would make more sense.

[seanwitte]

While I agree that a table lookup would be a lot easier, why not go all out this year, and use the CPU that was given to you, and calculate on the fly. I know that is what my team is doing. While a hash table would be fast, it would be less accurate, and we are personally looking for going for the perfect bullseye at least 60% of the time.

Theres nothing wrong with that approach, but time is a finite resource and it is not the hardest problem here. It seems to me there are two very difficult problems involved:

1) Build a contraption that consistently shoots the balls at roughly the same speed (and hopefully direction!)

2) Build a gimbal mount that can be quickly and accurately positioned to control the launch angle for the gizmo in part 1.

I think part 2 will be the deal breaker for most teams. Moving an appendage is one thing, but this requires tight tolerances to make it work.

[David Brinza]

Theres nothing wrong with that approach, but time is a finite resource and it is not the hardest problem here. It seems to me there are two very difficult problems involved:

1) Build a contraption that consistently shoots the balls at roughly the same speed (and hopefully direction!)

2) Build a gimbal mount that can be quickly and accurately positioned to control the launch angle for the gizmo in part 1.

I think part 2 will be the deal breaker for most teams. Moving an appendage is one thing, but this requires tight tolerances to make it work.
The KISS rule probably applies here (as in most things in life).

You need to understand the relative complexity of items #1 (consistent speed) vs. #2 (agile and accurate gimbal mechanism) and factor in the relative importance of 1 vs. 2. It seems to me that unless you plan to alter the launch angle based on the launch velocity on the current shot, #2 is not very important. If you shoot the ball at fixed angle and consistent speed, you should be able to deliver the ball in the proper height over a rather large range from the goal. I think that's the key in this game.

Hint: play around with the Excel spreadsheet I posted earlier in this thread, now attached below with a minor correction. I now divide by 8 in the drag factor parameter instead of multiplying by 0.128 (obviously I meant to multiply 0.125 in the original version...2% error - my bad!)

[Tatsu]

if anyone uses mathematica, here's a notebook to generate ballistic lookup tables..

initial values are declared at the top, target height is deltah (3.5 ft or whatever) * ft-> meter conversion.

all values should be done in metric.. at the end, just display the contents (or export to CSV) and load em onto the bot.

I'm sure a few of you'll figgure out some more inventive uses..

<-- currently working on a 3-dimentional version.

No, I'm not a programmer.

[Mark Pettit]

Another variable to your equations might be the "plug" that these balls have on them. The plug must be a necessary part of the manufacturing process. It really makes them wobble if any spin is introduced.

[BotLobsta]

I added the equation that Matt came up with into my firing calculations to have a basic trajectory to test with, and I got the following error:
Error - section 'MATH_DATA' can not fit the section. Section 'MATH_DATA' length=0x00000014

I looked in the linker script and could not find that section, nor could I find mention of it anywhere else in any documentation. Any help?

[Tatsu]

those of you intending to use lookup tables, here's a lookup table for you to play around with..

its around 108kb, but you can trim it by deleting the first portion (the ball wont even go in)

first column, theta
second column {distance-to-goal,total-distance-traveled-till-ground,risidual error}

risidual error shouldn't matter unless you're seriously nitpicky, it'll give you a relative idea of how much error there is for each theta..

[Korbin]

When I tested the camera code I could only get about 20' away before the trackable pixel area becomes too small. At 6" increments your lookup table is only 40 entries long.

was this tested using the four bulbs that came in the kit, or with all eight that will be used in competition?

[Andrew Blair]

There are eight cathode included in the KOP. Two per box. But I also wonder if only four were used; we were considering it, though we used eight, and with eight, it is pretty bright. But we haven't tested yet.

[craigbutcher]

When seeking guidance, look up. There is a very good website with the basics, not only on ballistics, but also on other cool and significant topics. I am really very impressed by this website. I recommend starting with this index page:

http://exploration.grc.nasa.gov/education/rocket/short.html


You will probably want to be sure to have a look at this particular page:

http://exploration.grc.nasa.gov/education/rocket/flteqs.html

Our government has borrowed trillions of dollars to fund this website, so you should take advantage of it!


The strictly ballistic part (without air resistance) you can do parametrically, using the Newtonian relation F=m*a, with first term physics/calculus, or algebraically by looking it up. That's a good first approximation and probably 80% right or so.

The drag part is a much harder problem because the drag always shows up as a force vector whose vertical and horizontal components are changing as a function of the magnitude and direction of the overall velocity vector. Drag in the horizontal direction, for instance, will be largest at the top of the projectile's arc. For this reason you cannot treat the components as ordinary differential equations with separable variables as you can using the simple Newtonian equations of motion. If the projectile is dropping straight down there is no horizontal component, and if it is a car there is no vertical component, which is why you can solve for terminal velocity using simple calculus.

You can make some simplifying assumptions about the average horizontal and vertical drag components, and that will get you closer if you pick the right assumptions. However, your best bet is to do prepare a numerical model using the state equations and some sort of calculation software--you can use Excel, or MATLAB, or Mathematica, or Mathcad, or program it in C. In other words, chop the problem up into N parts of the total flight time T (t0,t1,t2...tN), calculate an approximation at each interval, plug that value back in to calculate the conditions at t2, and so forth. The more the N, the more reality will be willing to cooperate with your answer...if the numbers you pick for the drag coefficient and for the area and so on are the right ones.

Oh, I almost forgot. There is also the Magnus effect which adds another wrinkle yet. A symmetrical spinning or rotating projectile moving through a viscous fluid (for example, air) will experience forces due to pressure differences caused by the Bernoulli effect created by the rotation. This is the subject of curveballs and so on. And while we're on that subject, I should probably mention surface roughness, reynolds number, airstreams, laminar flow, turbulent flow, and chaos theory. Not to worry, though. If even the very smartest of us really understood this stuff (and I am not one of those guys), we wouldn't need to build wind tunnels.

Your numerical simulation will get you in the ballpark. Once in, you need to build a pitching machine and do some testing.

Good luck.

[David Brinza]

When seeking guidance, look up. There is a very good website with the basics, not only on ballistics, but also on other cool and significant topics. I am really very impressed by this website. I recommend starting with this index page:

http://exploration.grc.nasa.gov/education/rocket/short.html


You will probably want to be sure to have a look at this particular page:

http://exploration.grc.nasa.gov/education/rocket/flteqs.html

Our government has borrowed trillions of dollars to fund this website, so you should take advantage of it!



Yes indeed, there is a good collection of resources here (correction to the first URL):

http://exploration.grc.nasa.gov/education/rocket/shortr.html

I'm taking serious offense to the statement above about our government borrowing trillions of dollars to fund this website. NASA's total budget this year is on the order of $17 billion dollars. Since NASA's inception (< 50 years ago), it hasn't spent $1 trillion dollars. The current NASA budget funds a huge list of activities: returning the Space Shuttle to flight, starting the development of the new human spaceflight vehicle, operating the ISS, supporting the Mars missions - operating (2 of Dave Lavery's "other cars" and 3 orbiters) and two in development (Mars Science Lab and Phoenix), operating Cassini at Saturn, launching New Horizons Pluto mission (later this month), operating Stardust (returning Jan. 15 with cometary and interplanetary dust particles), operating 2 Voyager spacecraft (at the real "edge" of our solar system), operating Hubble Space Telescope (including the final Hubble repair mission), operating Spitzer (a large infrared space telescope), developing the Space Interferometer Mission, supporting aeronautics research, operating and developing many, many Earth Science missions, plus many other missions and research activities that wouldn't begin to fit on a whole page of this thread.

On top of all the research and mission support, the NASA budget is providing some support to educational activities (such as FIRST and the above referenced website). The NASA education budget is on the order of 1% of the total NASA budget (which in of itself is about 0.7% of the federal government's budget). The website above was probably developed by a small handful of dedicated people - true educators, with a tiny budget and, most unfortunately, not a totally secure job future. (NASA's budget is under tremendous pressure and scrutiny as the agency is in a period of transition - there have be many layoffs within the agency and with contractors that support NASA in the past year).

Sorry for the rant, but I suspect there's a lot of people with the misconception that NASA's budget is large (it's less than 5% of the Department of Defense budget). I think the public gets a lot for what it invests (not borrows) in NASA.

[seanwitte]

was this tested using the four bulbs that came in the kit, or with all eight that will be used in competition?

I used what Dave gave me, which was an aluminum enclosure with two sets of 4 tube cathode tubes and an HDPE cover plate. I powered it with a 12V jump starter. With the target at the opposite side of my office at home (about 20' away) the number of tracked pixels was very small and the camera would occasionally lose the target and jump back into the search pattern.

[dababyjebus]

I don't know whether the question was sufficiently answered as far as calculating the angle goes. I certainly agree that with the trig involved and the other factors like air resistance and spin it's probably not going to be the way to go, but there is a simpler way to get theta than "A = 1/2 * (asin( (((g * x^2) / (Vo^2)) +y) / sqrt(x^2 + y^2) ) - atan2(-y/x))" ~Matt Adams.

Asumming:
Y = hieght to center of hoop
V = constant velocity
X = distance to goal from end of firing mechanism
Yo = height at which projectile leaves the firing mechanism

Vox = cos(A) * V
Voy = sin(A) * V

Y = Yo + Voy * t - 4.9 * t^2,
T = x/Vox,
Voy = Vox * tan(A);

Y = Yo + (Vox * tan(A)) * (X / Vox) - 4.9 * X^2 / Vox^2
Y = Yo + X * tan(A) - 4.9 * X^2 * sec(A)^2 / V^2
0 = Yo * V^2 - Y * V^2 + X * V^2 * tan(A) - 4.9*X^2 * (1 + tan(A)^2)
0 = (-4.9*X^2*tan(A)^2) + (X * V^2 * tan(A)) + ( V^2 (Yo - Y - 4.9X^2))

so just plug that into the quadratic formula with:
a = -4.9 * X * X
b = X * V * V
c = V * V * (Yo - Y - (4.9 * X * X) )

arctan( (-b + sqrt(b * b - 4 * a * c)) / (2 * a) )

Though it has been said that you will have to take into account the variables of air resistance and spin among others, this should give some people a good idea of where to start and fine tune from.

Hope this was at least somewhat helpful.

[MikeDubreuil]

When I tested the camera code I could only get about 20' away before the trackable pixel area becomes too small. At 6" increments your lookup table is only 40 entries long.
We tested the camera with Kevin Watson's camera code last night. I was astonished to find that we could track the vision target from approximately 55 feet away. In fact it was so far that we didn't have a tape measure long enough and we had to go through several connected rooms to get to that distance. We were not able to test the maximum distance because we ran out of room. We even tested different lighting situations and it had no effect on the camera's performace. We were really floored last night and I have to hand it to FIRST Engineering because this is simply awesome.

[seanwitte]

We tested the camera with Kevin Watson's camera code last night. I was astonished to find that we could track the vision target from approximately 55 feet away. In fact it was so far that we didn't have a tape measure long enough and we had to go through several connected rooms to get to that distance. We were not able to test the maximum distance because we ran out of room. We even tested different lighting situations and it had no effect on the camera's performace. We were really floored last night and I have to hand it to FIRST Engineering because this is simply awesome.

Its encouraging that you had better results. I'd heard from other sources that the range was quite far. I think the the color calibration values may not have been spot on for the cathode target when I was testing. Anyways, ignore my comments earlier in this thread, apparently the tracking range is not an issue.

[Cuog]

I don't know whether the question was sufficiently answered as far as calculating the angle goes. I certainly agree that with the trig involved and the other factors like air resistance and spin it's probably not going to be the way to go, but there is a simpler way to get theta than "A = 1/2 * (asin( (((g * x^2) / (Vo^2)) +y) / sqrt(x^2 + y^2) ) - atan2(-y/x))" ~Matt Adams.

Asumming:
Y = hieght to center of hoop
V = constant velocity
X = distance to goal from end of firing mechanism
Yo = height at which projectile leaves the firing mechanism

Vox = cos(A) * V
Voy = sin(A) * V

Y = Yo + Voy * t - 4.9 * t^2,
T = x/Vox,
Voy = Vox * tan(A);

Y = Yo + (Vox * tan(A)) * (X / Vox) - 4.9 * X^2 / Vox^2
Y = Yo + X * tan(A) - 4.9 * X^2 * sec(A)^2 / V^2
0 = Yo * V^2 - Y * V^2 + X * V^2 * tan(A) - 4.9*X^2 * (1 + tan(A)^2)
0 = (-4.9*X^2*tan(A)^2) + (X * V^2 * tan(A)) + ( V^2 (Yo - Y - 4.9X^2))

so just plug that into the quadratic formula with:
a = -4.9 * X * X
b = X * V * V
c = V * V * (Yo - Y - (4.9 * X * X) )

arctan( (-b + sqrt(b * b - 4 * a * c)) / (2 * a) )

Though it has been said that you will have to take into account the variables of air resistance and spin among others, this should give some people a good idea of where to start and fine tune from.

Hope this was at least somewhat helpful.

I already have a .c file with this already implemented and it will calculate angles in 3 dimensions as well as use accelerometer input, i am hoping to release this to teams by the end of the month since i still have to put finishing touches on the software and my team has side tracked my to starting to code for our robot which is unfortunetaly lacking a cannon

[dlavery]

We tested the camera with Kevin Watson's camera code last night. I was astonished to find that we could track the vision target from approximately 55 feet away. In fact it was so far that we didn't have a tape measure long enough and we had to go through several connected rooms to get to that distance. We were not able to test the maximum distance because we ran out of room. We even tested different lighting situations and it had no effect on the camera's performace. We were really floored last night and I have to hand it to FIRST Engineering because this is simply awesome.
While it is encouraging that we all recognize the contributions and value of the FIRST Engineering staff, I do feel that it is important to give full credit where credit is due for the camera system used in this year's Kit Of Parts. Like so many other things, the camera development was a collaboration of a lot of talents and resources. The camera design is obviously based on the CMUcamII developed by Illah Nourbaksh and Anthony Rowe from Carnegie Mellon University, and then reconfigured to fit within the physical constraints by the fine folks at Innovation First. The pan-tilt unit for the camera was designed by JVN at IFI. The software that allows the entire system to operate with the level of performance you are seeing was written by Kevin Watson at the NASA Jet Propulsion Lab. James Rahaim at FIRST, Peggy Caserto and Marcis Jansons at the U.S. Coast Guard Academy, and Sean Witte all helped with the testing and validation. If you like what you see with the camera system, please thank each of these folks for their efforts. If you don't like it, you can blame me.

-dave

[aaronm_k]

OK! something really funny just happened. I was working on these trajectories and having quite the frustrating time with them....
In walks my brother with the comics section of The Oregonian newspaper. He tells me to read the Foxtrot comic, so I do. And what do I find? I find the Foxtrot dude doing equations to calculate the trajectory of a snowball. That made my day! So I got the equations now...heeheehee

Here's a scan of the comic, with the formula circled:
http://www.marcuse.org/aaron/other/forums/ChiefDelphi/FoxtrotComicSnowballFight.jpg

The equation is not that simple, though, when you want it the other way around, with launch angle in terms of range/target distance. I calculated it as:
http://www.marcuse.org/aaron/other/forums/ChiefDelphi/LaunchAngleFromTargetDistanceFormula.jpg

Unfortunately, as Hutch noted, spin and air resistance make it almost pointless to try to use a physics function, so you're probably better off with a best-fit polynomial anyway.

[Bongle]

If you ever end up with an equation like
f(x) = g(x)

and you're unable to isolate x, there are many fast ways to get good approximations for x.

Newton's Method
Rearrange it so that you have
f(x) - g(x) = 0
Now your problem is reduced to finding the zeroes of f(x)-g(x). This is still difficult, unless you're clever, like Newton was. If you take a tangent to this function at some point x1, then find the 0-intercept of that tangent, the x-position of that intercept is probably closer to the zero of (f[x] - g[x]) than your start point was. Call the tangent's intercept x2. Repeat this process from x2. Unless you picked your start position poorly, you should iteratively get closer.

Code example:

float fcn(float v,float d,float h,float t)
{ return 0.5*sin(2*t)*d - (G*d*d)/(2*v*v) - h*cos(t)*cos(t);
}
float der(float v,float d,float h,float t)
{ return cos(2*t)*d + 2*h*cos(t)*sin(t);
}
float getAngle(float v,float d,float h)
{
// function: f[t] = 0.5*sin(2t)*d - gdd/2vv - hcoscos
// derivative: f'[t] = cos(2t)*dist + 2h*cos*sin
float xn = PI/8; // I start at 22.5 degrees because I know the solution will be somewhere nearby
for(int x=0;x<5;x++)
{
xn = xn - fcn(v,d,h,xn)/der(v,d,h,xn);
}
return xn;
}

In this code, I get close enough in just 5 iterations, and I could probably cut back on the iteration count. Note that this does not include any air resistance or spin or anything.


Also check out the wikipedia article on this: http://en.wikipedia.org/wiki/Newton's_method

[Bongle]

Here's a small application that demonstrates a calculation of firing angle.

The project zip file contains all the source code. It's meant for VC++ 6.0. If you want to use another IDE, you'll have to link comctl32.lib and figure out how to use the resource file.

[ldeffenb]

If you like what you see with the camera system, please thank each of these folks for their efforts. If you don't like it, you can blame me.


Well stated and my personal hat goes off to their efforts. I know we tackled the camera last year and *almost* had it working, but using reflected light from non-controlled sources introduced just plain TOO MANY variables. The emitted green light this year will hopefully eliminate those vagaries.

Our only concern at this point is the light warm-up period. I'm sure hoping they have the lights on *BEFORE* autonomous begins. Our camera takes 17 seconds to "see the light" from a cold start. After warming up for a bunch of minutes, it will still recognize it nearly instantaneously after a 40 second off period.

If the lights are not kept on most of the time, I suspect that the initial autonomous action will be entertaining for the audience and disappointing to the programmers!

Lynn (D) - Team Voltage 386