Ball Trajectory "Calculator"

VEX V5 General Discussion General Forum
#1

I have been working lately on solving the aerodynamics problem presented with launching a ball in this year’s game. After a ton of math and help from the community, especially Nathan from AURA, I would like to present the first version of my own Ball Trajectory “Calculator”

What it does:
It allows a user to input known initial parameters of the ball (initial height, angle of launcher, etc.) and/or the final range. Then, it reports back all of the possible solutions to the remaining undefined parameters that will result in a trajectory that makes it into the high goal, if any.

How it works:
Using Google Sheets, the user enters in any known conditions at the initial launch time such as angle of launcher or initial height. The Sheet then queries a Google Fusion Table that is already filled with solutions to various initial parameters. The Table responds back with all the possible conditions that will result in a ball trajectory into the high goal. The user can then select one of these trajectories to plot in order to verify it’s integrity.
MATLAB is used to numerical solve for the trajectory of the ball. It iterates over all the possible initial conditions at predefined step sizes.

Why is calculator quoted?
Because this isn’t really a calculator. It is a glorified lookup program. All the calculation has been done already before hand, courteous of my university’s server :slight_smile:

Instructions:
Log into your Google Account
Open up the Google Sheet
Go to the menu File/Make a Copy
On the copy of the sheet, enter in any known data to the left
The right side will list all possible results where the ball hits the goal
One can enter an x in the corrisponding column to the left of the list in order to plot the trajectory. Note that if there are multiple x’s, it will plot the first one.
One may change the error percent on the left in order to show more or less accurate results to your entered parameters

Notes:
This is just the first version and there are still quite a few things to do. The data is not very fine (V0 has a step size of 1 m/s, Theta0 has a step size of 1 degree, etc.). As is with this rough version I had around a million cells of data if you include the trajectory plots. This came to a .csv file size of about 64 MB. In addition, it took about an hour to simulate this data. I plan on reducing the step size, but by doing so I will greatly increase the simulation time and size. Before doing so, I would like to work out any kinks if possible. Please let me know any problems you find.
If you enter in parameters such that the ball won’t go high enough to make it into the goal, there will be no results listed. This is intentional. Also, there are no listed trajectories such that the ball is rising when it goes into the goal. Again, this is intentional because it wouldn’t be physically possible.
V0 (initial speed) iterates from 1 to 10 in 1 m/s steps.
Theta0 (initial angle) iterated from 0 to 90 in 1 degree steps.
Spin iterates from -40 to 40 in 5 rad/s steps.
Y0 (initial height) iterates from 0 to 0.4572 (18in) in 0.1 m steps.

Known Issues:
There are a few null trajectories that got past my filter. I need to figure out how they did and correct it.
There are some trajectories in which the ball curves so much that it is moving backwards (in the x direction) when it goes into the goal. Seeing as how this wouldn’t be possible (it would hit the bar on the goal) I need to figure out how to remove these.
If you don’t enter in enough initial parameters there will be no results. This is because Google Fusion Tables limits the query response size to 10MB.

Please let me know what you think. If there are any problems or additional features you would like to see tell me! I was considering iterating the ball mass over the tolerance range but didn’t know if anyone would be interested in that.

How fine of results are people looking for? Is it good enough to increment the initial angle in whole degrees? How about the initial velocity? Let me know.

I plan on going into more detail as to how it actually works at a later time.

One final thing. Google Fusion Tables allows for 25,000 requests per day before it will 404 and it allows for 30 requests per minute so if it gets busy you may have to keep trying for the query to work. Please don’t write a script that feeds off of this calculator and shuts it down. Instead, I will send you the data itself if you want it.

#2

it is throwing out results that don’t make sense, I was using it to try and just get a few basics to see if they match, and it throws out no responses for a requested range of 6M at 60 degrees, which is totally possible. so I conclude that there are no variations of which a 1 m/s step size will result in the correct result at any angle and spin, is that correct? if so the 1 m/s step size is vary limiting

#3

Collin, if you are going to enter the range and backsolve for the velocity you should try making the error percentage larger for now. Try this and let me know how it goes.
You are right, a step size of 1m/s for the velocity is too big to be useful, but for the first version I needed to do this for time reasons.
Reducing the step size to a tenth of this will probably be good enough in the future, but it will take 10 times longer to simulate (hours). Thanks for the feedback!

EDIT:It looks like my limit of 30 requests per min isn’t cutting it. I’ve increased this so it should handle the extra usage. This change should propagate relatively soon. In the meantime I would recommend refreshing the page, that might help…

#4

I’ll be updating my calculator to use numerical solving soon assuming all goes well, so this look-up-table approach probably won’t be needed :stuck_out_tongue: But interesting nonetheless!

#5

I went up to 100% error and still nothing, once I tried above 100% error the spread sheet told me “#N/A” here is what I am doing
theta = 40
Yo = 1
Range = 3, no spin I left Vo blank

#6

Nathan, out of curiosity, how will you be taking this approach? Will the computation be done server side or client side?
Also, have you had success with the boundary value problem converging? I was able to solve for initial velocity fairly easily with a decent initial guess, but I couldn’t get the initial angle solver to converge reliably. It seemed to have alot of issues caused singularities in the Jacobian matrix that I couldn’t hash out. I even tried just using a proportional error feedback to guide the guess, but that failed because the partial derivative of the range with respect to the initial angle has sign changes over the domain…
Now that I think about it, you might have luck if you use the secant-method for your root finding algorithm…maybe. But with the angle there can be multiple solutions and you really aren’t sure which it will converge to.
I would realllly be interested in the details of how you got it to work because I have been mulling this over for a while now with no luck.

#7

So the issue is your Y0 value. Y0 is the initial height of the ball at launch, not the final height. I didn’t iterate Y0 all the way to 1 because a robot is not allowed to be 1 meter tall :slight_smile: If you try a more legal Y0 of say .4 it works with an error of 7 percent. Sorry that I wasn’t more clear.

Assuming there aren’t any big problems, I will start the extended simulation tonight so that V0 has step sizes of .1 m/s, among other improvements. It may take a day or so to finish :confused:

#8

ok so here is the real question
I am planning on having my robot calculate my robots position, then calculate the distance from the goal, calculates the required Vo then sets the motors to the right speed, and then shoots into the goal.is Whatever funny and totally baffling calculus method you guys have been using since you discovered the error in the equation, and also to account for spin practical for this, or is it totaly crazy to thing the cortex could solve for this, on the spot?

#9

Server-side, as it is now.

I managed to get it to converge while using the previous equations, and from my solver’s perspective the only difference should be that it calls a different function so I’m sure it’ll still work.

Yes there are (usually) two angles that it is possible for and I always picked the larger of the two using the no-air-resistance equations as the initial guess then just doing a binary search until the exact value is found.

#10

I’m pretty sure it’s totally crazy to think the Cortex could solve it. Making a map of distance -> initial velocity or distance -> initial angle and using that is how I’d say it should go. (I have the code for this done, but I just didn’t deploy it until I fixed the calculator :P)

#11

but would the earlier equations be adequate for that(the ones off the wikipedia page) I have the code to solve for initial Vo based on that, but is it good enough?

#12

That will probably work then if you don’t include spin. The biggest problem I have had with spin is that if you add backspin, you make it so that there is now some point in the angle domain such that the ball will reverse direction and start going backwards. If your initial guess is on the wrong side of this point, the solver will diverge away rapidly. This angle will start high, and come down as you increase the backspin and can cause real problems in realistic situations (the spin isn’t crazy high or anything).

If you exclude spin, I don’t see any reason why it shouldn’t converge given your good initial guess except under weird circumstances.

#13

To be honest, I think the idea of a calculator like this is entirely useless for competition use and I do not plan on doing it. I have only done this out of my own curiosity and enjoyment of aerodynamics.

Firstly, if you are going to be exact there is really no way the cortex would be able to solve these problems on the fly, like Nathan just said. I mean, it takes my school’s server a second or so to complete 100 iterations. I would probably get better performance on my laptop, but there is no way the Cortex would be able to do this.

Secondly, let’s say the Cortex could do this math at a reasonable 10 or 20 Hertz. So I know what my initial velocity should be, how does that translate the the rpm I need for my shooter? Sure, we can run through a bunch of theoretical math and come up with a solution. However, using empirical data from the videos already posted, we know that the launch velocity is dependent on the density of the ball in some way. This can’t easily be quantified with VEX sensors, so that means we would have to create a model based on empirical data.

Well if we are already making part of our model based on empirical data, why not do it all?
This is what I think will be the most effective.
Set your shooter to a certain speed. Aim it at a table that is the height of the goal. Take 100 shots and measure the distance. Rinse and repeat at a variety of shooter speeds. Average and plot your data that relates shooter speed to shot distance and either create a lookup table or fit some finite term polynomial to it and use that on the Cortex.

The simpler equations may work. But really, nothing will be better than taking empirical data and fitting a model to it. There are just too many factors that we can’t take into account when making theoretical models.
There are far easier ways to do this than by these equations. If you do get it to work using these advanced aerodynamics equations and such, Kudos cause that’s something to be proud of.

#14

Okay, so I went back and looked at this problem from the beginning. I looked at where I got stuck before on the boundary value problem and realized a solution that I had overlooked. I can now solve the boundary value problem in MATLAB. No need for these clunky tables.

So, my question to anyone interested is this:
How should I present my calculator?

The easiest and quickest way for me is to just make the MATLAB executable like I did in the original position calculator thread. However, this requires the user to download the MATLAB runtime (like you do java). The advantage to this is that I don’t have to convert all my code to some other language or maintain some sort of server. However, will anyone actually download the MATLAB runtime to get this calculator? I don’t want to waste my time for naught. Also know that I plan on expanding the calculator or making separate ones for other stuff like figuring how to maximize flywheel rate of fire while not overheating motors or anything really that anyone requests.

If nobody will download the MATLAB runtime (its free btw), but they are still interested in the calculator, I can look into converting the code to some other language that can be compiled and executed online. Honestly, I am not a programmer so this would be an adventure for me. The advantage to this route is that I might be able to get it to run in your browser without any add-ons (except maybe Java?). The disadvantage is that it will take a while to implement and update progress will be slowed greatly.
Any opinions?

#15

My knee-jerk reaction is this: if you can figure out a way to get this to work inside MineCraft, you’d make a billion dollars! :slight_smile:

#16

I wish!
It’s really the front end stuff that I can’t do. I can make a GUI in MATLAB easy, but I would have no clue how to do that in java for a webpage. I should be able to port my MATLAB code to C/C++, but I don’t know how I would interface that with a front-end GUI in another language… :confused:

#17