Launching Speed Calculator

Hello everyone!

About a week ago I started to look into calculating required launcher speed (or angle) from a position on the field without neglecting air resistance.

To start with the Wikipedia article (it covers the cv approximation first and then cv^2 later) was incorrect, with incorrect constants of integration all over the place which didn’t help. :frowning:

Anyway, the formulae there should now be correct (thank Oliver too for that). Anyone with an interest in these calculations should probably look at them - they’re pretty complex though.

Finally (what you all probably came for) I turned these equations into a Launching Speed Calculator where you can enter a robot position and launcher angle and it will output a required speed. :smiley:

I’d be quite interested to know how these values correspond to real-world values (if anyone has done accurate speed measurements of their launcher?). It doesn’t include the Magnus Effect (ie. spin), but regardless should be a lot better than assuming no air resistance.

Hopefully this helps some people with planning their robots, enjoy! :cool:

Excellent! This is fantastic! Our thanks to you and to Oliver for putting this together. My kids got their prototype ball shooter running for the first time yesterday and they love this ballistics stuff more than anything else they’ve ever dealt with. I’ve never seen them so motivated to actually analyze things in so much detail. One of the kids has an iPhone with a slow-motion feature, which they were using to watch the balls launch, so hopefully we will be able to get some data in the next week or so to compare landing angles, etc. with your model.

Thanks so much! :slight_smile:

I’m planning on doing some actual ball launching tests with various wheel sizes after my finals are over. I will make sure to post the results

Your calculator is awesome! This is a big help to figure out speeds I should start testing at. Thanks!

This is pure awesomeness.

Thanks. This is everything we need to play NBN.

I’m surprised by how much those calculations differ from the ones I did with no air friction, thanks for the info, I may have to re-think some things

I was digging through the equations, and all of them involve mass, what did you use for the mass of the balls?

has anyone weighed some of the balls to see if weight is consistent, if it is not, how much does it vary by? does anyone have a good average? or maybe even know the company the produces the ball so I can look up it’s specifications?

its 0.11lbs + or - 10% you can find the field and game object specifications in appendix A here
http://link.vex.com/docs/vex-nothing-but-net/VEX-Nothing-But-Net-Appendix-A-Field-Specifications

suppper job with this. Just a question: is it possible to put hash marks and the x-y value for each pile of balls so we would not have to keep futzing with the numbers? I’m not looking for you to do all the work here because it is mind boogling that you did this so well. I’m not being ungrateful.
Just wondering. And thanks again.
What programming language did you do this in? Java? I’m just guessing when I inspected the element and saw your code.

ok, can someone explain to me how this works,
I am planning to use a program that track you robots position in X and Y then calculates the required velocity based on that, exactly what the program posted here does.
I have spent more hours than I’d like to think about going through thoose equations and trying to figure out how to isolate initial velocity and I have not been able to do it. it’s probably not helping that I haven’t take any physics or calculus courses.
If someone could dumb this way down for me, or even just throw me the equations I need, that would be great.

Velocity is distance over time, since you have x and your previous x coordinate you would just subtract the two to get your change in x and you would do the same for y. after this you would do xdiff^2 + ydiff^2 to get your total change in distance. Time you can just put a wait 10-15ms at the end of your task, I haven’t really tested this yet so I don’t know if having a wait time would cause error to accumulate.
The formula would just be (xdiff^2 + ydiff^2)/your wait time

the answer is not that simple, I know how to calculate how far I am from the target in a straight line, but the velocity of the ball depends on the exact arc it travels, and that arc changes depending on velocity, you cannot just arbitrarily assign a time, time is dictated by velocity, drag, gravity, curve ect. what I need is that equation that relates the straight line distance to the goal, and the vertical distance to the goal, to the required initial velocity, this equation cannot contain time, unless there is a second equation solving for time that does not contain V0

I’m not sure exactly what you’re looking for, but would this help?

I can’t vouch for all the equations there - I haven’t personally gone through all of them. I’m told Oliver W from AURA found some mistakes in one of the wikipedia articles that takes air friction into account.

oh woops sorry my bad I thought you meant the velocity of the actual robot

If anyone wants to know speeds at certain distances from the Red goal, and subsequently the blue goal too, I hacked up a quick python script with the help of Nathan and Jordan(Legomindstormsmaniac)

This is the outcome: http://pastebin.com/1JmTJwct

This is the script: http://pastebin.com/Cqv93hzZ

Great to see people have found this useful so far!

I added in being able to drag the current position (red dot) around the image, as well as clicking anywhere on the image will set the position to where you clicked - hopefully that’s an even easier way for what you wanted! :smiley:

The front-end bit is all Javascript (what you saw), but the actual velocity calculations are done server side (PHP) through an Ajax call.

I’m pretty sure it’s impossible to get an equation for v0 directly, ie. you can’t analytically solve it. I have to numerically solve it (essentially guess and check, but your guesses are well-founded) to find a v0 that meets all the requirements (horizontal and vertical displacement at the same time).

That’s what I mentioned in the initial post, the Wikipedia article had issues with these equations that Oliver and I discovered so we fixed them - I’m pretty sure they’re correct now :slight_smile: The ones that are there are now the same ones I’m using.

That’s so cool! You were reading my mind. Thanks for doing this. :slight_smile:

Oh, okay. That’s awesome. I can’t praise this enough without sounding ridiculous. :slight_smile:

could someone explain this process to me?

So when you include drag in the trajectory equations, it adds a differential aspect to the equation. Basically, this means that there is no easy path from your initial conditions (velocity) to you final solution (distance). Instead, these differential equations tell you what will happen to the ball in a fraction of a second. You can use these equations to figure out where the ball will be and how fast it will be moving say .001 seconds after launch. Then, using the information about the ball at time .001, you can figure out where it is at .002 seconds. You repeat this until the ball has landed. Now that isn’t too bad. It sounds like a lot, and would be if you did it by hand, but a computer can run that calculation in a fraction of a second.
The problem here is that we are specifying what the end condition is (how far it shoots) and are trying to solve fore the initial conditions (velocity, because the angle is pre-determined). However, you can’t just repeat the above steps backwards. Instead, you make an initial guess, the computer runs through the entire process above, and then it sees how far off it is from your desired distance. It uses this to adjust the guess and try again. It does this over and over until it gets close enough to the distance you have specified (you set the error window) and thennit tells you its best gurss. This process can take some time. I remember doing a 1D rocket sim that took 30 seconds to solve because my initial guess was poor :slight_smile:

Just as a disclaimer, most of what I said above is semantically wrong in some way or another. However, it should be rough enough that people with and without a background in physics, calc, and diffEQ can share in understanding the process.

Nice calculator!

Is this always measured to be on the downward part of the trajectory?

e.g. No shots upward that hit the backboard before the downward arc starts. (I get Invalid with up close ones with smaller launch angles so I guess you coded that minimal trajectory to hit above the front bar)

so i have been trying to be able to make this work myself so that I could use it on my robot, and I made an excel spread sheet to prototype the system, and the values I am getting do not match the values from the calculator that was posted here. I know the problem is in my system because it has a lot of other errors as well, it says I cannot make any shots from closer than 5.5 ft, which seems unacceptable to me. it also seems to have disturbingly low Vo’s for shots of like 40 ft, the answers it gives for thoose distances seem very unrealistic

if some one could look over the spread sheet and try and find my errors, I would be very grateful, as I have been unable to figure it out.

here is the link, make sure to download the file
https://drive.google.com/file/d/0B1LLlSCW4Hm5WGE4NzhnR3JtQU0/view?usp=sharing

by the way I am using the equations from the wikipedia article posted here