Altitude prediction?

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
That's the one.

It isn't so much that I like the Aerolab + wRASP32 as much as I like wRASP32 for quick ballpark sims. Fill in three values, select a motor and sim the flight. You don't have to "build" a model first or load files or anything else. Editing the .eng files is also very easy. Just cut and paste the RASP file from Thrustcurve. If you do an Aerolab drag profile, you can save a model file and then reopen whenever you want to sim a new motor.

BTW, I do have and use RASAero too, and have started using Open Rocket. Those are good when you are working a specific project, but I still prefer wRASP32 for quick sims.

Agreed. With wRASP, you don't need to build a rocket. It is as easy as Thrustcurve, but with more accurate numerics.
 
We could do a rough, back-of-the-envelope calculation. First, some definitions.
-Average thrust, F (in Newtons, from the motor label)
-Burn time, t (seconds, from the thrust curve or impulse/F)
-Rocket mass, m (kg, or pounds/2.2)
-Gravity, g (~10 m/s^2)
-Acceleration, a (m/s^2, which is an intermediate result)
-Velocity, v (m/s, which is an intermediate result)
-Altitude, h (in m, for feet, say h*3)

From Newton's second law, we say:
F-mg=ma
a=F/m-10

After some simple calculus, we get the conditions at motor burnout:
v'=t*(F/m-10)
h'=0.5*t^2*(F/m-10)

Of course, the rocket continues to coast after that. From some other equations of motion (not derived here), we see that the altitude covered on coasting is:
h''=v'^2/(2g)
h''=t^2*(F/m-10)^2/20

The total altitude reached will be equal to h'+h'', so
h=0.5*t^2*(F/m-10)+t^2*(F/m-10)^2/20
h=t^2*(F/m-10)*(0.5+(F/m-10)/20)
h=0.5*t^2*(F/m-10)*(1+F/(10m)-1)

h=0.5*t^2*(F/m-10)*(F/(10m))

To account for drag, take ~2/3-4/5 of that height. Sure, you won't be exactly correct, but you'll be in the ballpark.
 
h=0.5*t^2*(F/m-10)*(F/(10m))

I think I made a mistake somewhere. After running a couple of samples, I got some devastatingly wrong results. I did find that if you drop the final *(F/(10m) and replace it with just a *10, you get pretty good results. I'm not really sure why, but obviously my physics went wrong somewhere. So, I'll leave with this decent approximation (in meters):

h=0.5*t^2*(F/m-10)*10

Don't forget to then account for drag. It looks like 4/5-5/6 may be a better drag approximating factor.
 
I think I made a mistake somewhere. After running a couple of samples, I got some devastatingly wrong results.
Closed-form solutions are not easy for this problem, which is why most approaches involve simulation.

Treating the drag as a fudge factor will make the result useful for only a narrow range of motor/rocket combinations since Fd ∝ v².
 
There is no need to use simplified equations that omit something as important as aerodynamic drag. There are much better closed form solutions. Look up the Fehskens–Malewicki equations which handle the velocity squared term. They did all the hard calculus for you and the solution can be programmed in a spreadsheet or hand calculator. However, thrust, Cd, mass, and air density are still assumed constant.

Hence, the numerical simulations (Thrustcurve, wRASP, Rocksim, OpenRocket, RASAero, etc) are far better because they can easily handle all the time and space dependent variables. They use numerical integration which is very accurate, provided a high order Runge-Kutta scheme and small time step are used. If you want a fun DIY programming project, this is a far more powerful and practical way to go.
 
I think the whole point was to have some analytical solution that could easily be calculated at a vendor's booth or the RSO table. Of course a sim is always going to give a better result.

Treating the drag as a fudge factor will make the result useful for only a narrow range of motor/rocket combinations since Fd ∝ v².

If you treat the drag as an energy loss, you'll find that the energy loss is proportional to t_bo*v_bo^2. So, unfortunately, we're still stuck with that v term, but I did provide a linear approximation for that (v_bo=t_bo*(F/m-10)). A simplifying (albeit imperfect) assumption you can make is that this is an approximately constant proportion of the total flight energy, at least as far as the size and speeds of most amateur rockets goes.

There are much better closed form solutions. Look up the Fehskens–Malewicki equations which handle the velocity squared term.

I took the liberty of googling these equations, and while I'm sure they give better results than I, it assumes you know your average drag coefficient and the density (and that it's constant). It also assumes that you're a wizard at computing hyperbolic trig functions and natural logs in your head, which I am not.

I was just deriving a simple analytic engineering prediction that could estimate within a reasonable percentage the total altitude. And I feel like it's reasonably easy to solve.
 
How about using nomograms? They're a bit hard to read initially, but all you need is a straightedge. It's a sort of hardcoded paper computer.
https://www.aerotech-rocketry.com/c...ogs_Flyers_Data_Sheets/aerotech_nomograms.pdf

These are very, very cool. However, each motor needs a nomogram, and there are a bazillion motors out there, with new offerings seemingly every month. Also, my way of thinking is to build a rocket, then quickly see how a variety of motors make it perform. This is not easily done with the nomograms, but it is easy with the Thrustcurve motor guide.
 
I think the whole point was to have some analytical solution that could easily be calculated at a vendor's booth or the RSO table. Of course a sim is always going to give a better result.

Agreed, and I would dare say the consensus of this thread is that the flier, vendor, or RSO should have a prepared notebook of sim data, nomograms, a computer, internet access, or a smartphone app to easily and reliably predict performance.

I took the liberty of googling these equations, and while I'm sure they give better results than I, it assumes you know your average drag coefficient and the density (and that it's constant). It also assumes that you're a wizard at computing hyperbolic trig functions and natural logs in your head, which I am not.

Nobody suggested that the equations can be solved in your head.

I was just deriving a simple analytic engineering prediction that could estimate within a reasonable percentage the total altitude.

Nice effort, but you derived nothing. By your own admission, you don't understand the physics, haphazardly removed terms from the equations with no justification, added additional fudge factors, and can't explain what you did. I highly doubt that your professors at Georgia Tech would let you get away with this line of reasoning on an exam.
 
Nice effort, but you derived nothing. By your own admission, you don't understand the physics, haphazardly removed terms from the equations with no justification, added additional fudge factors, and can't explain what you did. I highly doubt that your professors at Georgia Tech would let you get away with this line of reasoning on an exam.

Quite to the contrary. This is what engineering estimation is all about--making simplifying assumptions to give you a close but non-exact answer, a back-of-the-envelope gut check. In rocket flight, we can say that the rocket travels nearly vertical (small angle assumption causes theta term to vanish), that the force of thrust is orders of magnitude more significant than the drag (causes the non-linear drag term to vanish), and that gravity and air density are essentially constant. Nearly every engineering equation makes assumptions to get rid of tricky, time-variant, non-linear terms. This sort of analysis is the sort of thing every major engineering firm (Boeing, Lockheed, SpaceX, NASA, etc.) does when developing a new product or analyzing a situation. Of course, the design is then made to much stricter equations and simulations down the road, but they all start with the basic back-of-the-envelope design.

And, no, in a theory-based class, this kind of estimation would generally not be rewarded, but in a design-based class, this is the type of reasoning that is encouraged. It actually shows a great understanding of the physics, namely which forces dominate and how they interact with a body.
 
... that the force of thrust is orders of magnitude more significant than the drag (causes the non-linear drag term to vanish)
But it's not and it doesn't. I suggest you run through some actual calculations (I provide simple simulation equations on my Flight Physics page).

You can always add fudge factors to an equation to make it match one or more known points, but that doesn't make it have any predictive power beyond those fitted points. IMO you do need to fully understand the equations before you can make a determination of what does and doesn't matter.
 
If anybody would like to offer some better analytic expressions that are easy to solve out at the field without a computer, I'm all ears, but I haven't seen it yet. I have proposed a solution that approximates the altitude pretty well and captures the relevant flight physics.
 
I did find that if you drop the final *(F/(10m) and replace it with just a *10, you get pretty good results. I'm not really sure why.....

Umm, please explain this mathematical magic and why we should believe you have any clue about what you are talking about.

This is the grilling you will get in the real world, and no engineering manager would accept your nonsensical reasoning in a project review.
 
You can find the rocket equations here. https://www.rocketmime.com/rockets/rckt_eqn.html

The equations are summarized here. https://www.rocketmime.com/rockets/qref.html and in .pdf format at https://www.rocketmime.com/rockets/RocketEquations.pdf

The simplified method that Joe used assumed a drag free situation.

1.) The acceleration of a rocket under power is a = g* [(T/W)-1] where g = ~ 32 ft/s/s or 9.8 M/s/s (Joe approximates this to 10 M/s/s) and T/W is the thrust to weight ratio of the rocket (pounds/pounds) or Newton/Newton.

2.) The burnout velocity is simply vb = at where tb is the burn time of the motor.

3.) The burnout altitude is simply h1 = (1/2) a tb^2.

4.) The coast time is simply tc=vb/a where vb is the burnout velocity.

5.) The coast distance is h2 = (1/2) a tc^2.

6.) The apogee is the sum of the burnout height and the coast distance = h1 + h2.

7.) No drag is accounted for and drag is proportional to velocity squared.

8.) You guys can do the algebra to shove it all into 1 equation......

Bob
 
Back
Top