A generalised ideal rocket equation

Thorsten

Active member
Joined
Dec 7, 2013
Messages
780
Reaction score
53
Points
43
The rendezvous burn can be approximated to an instantaneous burn, while orbital insertion definitely can't. A huge difference.

We've been discussing a numerical solver that gets you the trajectory by summing vector forces in every timestep. While you can approximate a burn as instantaneous, you really don't have to, it doesn't make anything simpler.

Now tell me, why do you actually feel offended?

Offended? No. Somewhat frustrated? Yes.

I'm a theoretical physicist, I have developed codes to solve science problems for more than a decade so by and large I know how to solve equations of motion, I'm part of the development team of an OpenSource flight simulator, so I also know a lot about working in a real-time sim environment - and I happen to be of the opinion that I have coded (one) viable solution to the problem outlined already - which means I can give a few useful pointers.

Reading lots of handwaving arguments why my existing solution doesn't really work from people who have not yet coded such a scheme is not my idea of how to have a good time - if you try the scheme and see the numerics doesn't cut it for your use case, then we can discuss convergence and improvement schemes.

Or if you're not interested, you're not interested, that's also fine.
 
Last edited:

Thorsten

Active member
Joined
Dec 7, 2013
Messages
780
Reaction score
53
Points
43
Honestly, I'm not interested in Internet jousting.

That was really my point as well - I'm interested in discussing the actual math/numerics of the problem, not anything else.

Thanks for clarifying then.

Anyway - I'm sorry if you feel offended by anything I said - I'll just shut up and let you work it out your way.
 
Last edited:

Keithth G

New member
Joined
Nov 20, 2014
Messages
272
Reaction score
0
Points
0
Enjo

I haven't forgotten about this topic. I've given the matter some thought over the last couple of days and have mentally worked out the structure and content of what I want to say on the algorithm. But a significant-ish typhoon is now bearing down on us here in Hong Kong and I have a number of chores to complete today in order to prepare for its arrival. When the typhoon hits in about 36 hours, I should have more time to write something up.
 
Last edited:

RGClark

Mathematician
Joined
Jan 27, 2010
Messages
1,635
Reaction score
0
Points
36
Location
Philadelphia
Website
exoscientist.blogspot.com
Once you do it numerically, you might equally well add the atmosphere via
F_drag = c_d(alpha) * A_ref * rho * v^2
and
F_lift = c_l(alpha) * A_ref * rho * v^2
where the forces act along and perpendicular to the current velocity vector and alpha is AoA (angle of spacecraft axis with velocity vector) and the local density can be assumed to be
rho(h) = rho_0 * exp(-h/H)
where H is the atmospheric scale height (some 8 km for Earth) and
h = sqrt(x^2 + y^2) - R_earth.
At the end of the day, acceleration is the (vector) sum of all forces acting divided by mass - I'm not sure I'd call that a generalized rocket equation :)

It seems that you could provide a particularly accurate launch performance estimator with your knowledge of aerodynamics and flight trajectories. It's surprising that there don't seem to be any available online considering the great interest in the topic by space advocates.

The only one I'm aware of is by Dr. John Schilling on his Launch Performance Calculator page. But this doesn't really calculate trajectories. It just makes a comparison to prior launch vehicles dependent on the specifications of the users rocket and makes a statistical estimate of the payload based on that.

A true calculator seems doable. For instance I understand most orbital launch rockets launch initially vertically, then after a minute or so of ascent, they steer the engines to angle the trajectory over a small angle, the pitch-over, but then after that the engines are set directly through the center line of the rocket, no more steering and steering losses required.

This is the "gravity turn", where the force of gravity gradually pulls the rocket over into the horizontal attitude needed for orbit.

Given this it shouldn't be difficult to derive a numerical solution to the payload to orbit, given the specifications for the rocket.

Bob Clark
 
Last edited:

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,658
Reaction score
6
Points
38
Location
Hildesheim, Germany
Website
www.enderspace.de
Given this it shouldn't be difficult to derive a numerical solution to the payload to orbit, given the specifications for the rocket.Bob Clark
But we do have this and it's called Powered Explicit Guidance. Launch MFD has PEG implemented, and Multiustage2015 has it implemented even for multiple stages.
In Launch MFD I even solve PEG numerically to produce Direct Ascent program in the end.
 
Last edited:

Thorsten

Active member
Joined
Dec 7, 2013
Messages
780
Reaction score
53
Points
43
It seems that you could provide a particularly accurate launch performance estimator with your knowledge of aerodynamics and flight trajectories.

PEG is from the 1970's or so... computing power was scarce then. These days numerically solving a trajectory in non-spherical gravity and a moderately detailed atmosphere model in discrete timesteps given an ascent guidance model doesn't even make your cellphone sweat.

In fact, Orbiter itself provides the computation capability (you can just fast-forward at a high rate if you don't fly manually).

So yes, I don't think if you provide the capabilities of a craft and the guidance program (if it deviates from the one you outline) writing a tool that computes the trajectory would be something difficult or exotic - I have an old offline atmosphere entry tool somewhere that does a numerical solution of the trajectory given a (simplistic) set of AP instructions, which is kind of similar to what you outline.

As I said earlier, you can even compute trajectories fast enough these days to fit a limited number of burn parameters to a target (i.e. compute a couple of iterations) within a reasonable time - in an offline tool, you can probably cram a few thousand trial launches into a few seconds of running the tool.
 

RGClark

Mathematician
Joined
Jan 27, 2010
Messages
1,635
Reaction score
0
Points
36
Location
Philadelphia
Website
exoscientist.blogspot.com
PEG is from the 1970's or so... computing power was scarce then. These days numerically solving a trajectory in non-spherical gravity and a moderately detailed atmosphere model in discrete timesteps given an ascent guidance model doesn't even make your cellphone sweat.
In fact, Orbiter itself provides the computation capability (you can just fast-forward at a high rate if you don't fly manually).
So yes, I don't think if you provide the capabilities of a craft and the guidance program (if it deviates from the one you outline) writing a tool that computes the trajectory would be something difficult or exotic - I have an old offline atmosphere entry tool somewhere that does a numerical solution of the trajectory given a (simplistic) set of AP instructions, which is kind of similar to what you outline.
As I said earlier, you can even compute trajectories fast enough these days to fit a limited number of burn parameters to a target (i.e. compute a couple of iterations) within a reasonable time - in an offline tool, you can probably cram a few thousand trial launches into a few seconds of running the tool.

I was looking for something more user friendly, like Dr. Schilling's page:

Launch Vehicle Performance Calculator.
http://silverbirdastronautics.com/LVperform.html

where you don't have to know Orbiter programming to get a reasonably accurate answer. You plug in the specs, and it would spit out the answer.

Bob Clark
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
780
Reaction score
53
Points
43
That's chiefly a question of creating an UI that creates sets of simulation parameters according to your menu selections and passes it to the computation tool.

I'm not really a web or UI programmer, so I don't know how difficult it would be to make it nice. A raw C++ trajectory simulation tool to the accuracy you imagine is really not difficult to do, gathering the data on the rockets likely takes longer than coding it.


(Disclaimer: I unfortunately don't have the time to do work on this - most of my current coding time goes into my Space Shuttle project, most of the rest into the rendering framework I maintain, and whatever is left into an exoplanet simulation - I simply can't add more to my to-do list - I'll be happy to help anyone who wants to do it with pointers and advice).
 

Notebook

Addon Developer
Addon Developer
News Reporter
Donator
Joined
Nov 20, 2007
Messages
11,700
Reaction score
564
Points
188
I was looking for something more user friendly, like Dr. Schilling's page:

Launch Vehicle Performance Calculator.
http://silverbirdastronautics.com/LVperform.html

where you don't have to know Orbiter programming to get a reasonably accurate answer. You plug in the specs, and it would spit out the answer.

Bob Clark

Playing with this to see what would make Blue Streak(http://www.spaceuk.org/bstreak/bstreak.htm) get into orbit.

Getting "try again" with these values:

http://i89.photobucket.com/albums/k207/Notebook_04/Image2_zpsqwndxrtl.jpg

lift off mass 205000lbs = 92250kg

Fuel mass 190000lb = 85500kg

dry mass = 15000lb = 6750kg

Thrust = 1334kN sea level

ISP = 285

Payload fairing 1000kg

Blue Streak was a ballistic misile and never designed to get into orbit. But just for fun, what can I tweak first to get some result out of the calculator?

On second thoughts, the thing to do would be use Europa as a model in this. Please disregard or delete this, and I'll start a separate thread for the calculator



Thanks, N.
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,881
Reaction score
1,537
Points
203
Location
Langendernbach
PEG is from the 1970's or so... computing power was scarce then. These days numerically solving a trajectory in non-spherical gravity and a moderately detailed atmosphere model in discrete timesteps given an ascent guidance model doesn't even make your cellphone sweat.

You are aware of what a control loop is, yes? :tiphat: You are not doing those calculations once - you do them about every major cycle in a real time system, comparing real world reaction and sensor data to expected data and then fitting the model to the data, not the reality to the model.

The current state of the art for the task is actually a cute mathematical tool: Convex optimization.

http://www.techbriefs.com/component/content/article/12247

Yes, your idea works GREAT in a world, where you know the exact physics because those are also just a model and you know this model. But in reality, you could not even use your algorithm effective for making a robot arm carry a glass of water from point A to point B.

You can of course use your analytical solver iteratively. But then a simpler and faster solver will beat you: While your algorithm produces more exact results from the input data, the simpler solver will allow less errors to accumulate because he has less delay between sensor input and control action.
 
Last edited:

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,658
Reaction score
6
Points
38
Location
Hildesheim, Germany
Website
www.enderspace.de
You are aware of what a control loop is, yes? :tiphat: You are not doing those calculations once - you do them about every major cycle in a real time system, comparing real world reaction and sensor data to expected data and then fitting the model to the data, not the reality to the model.
Emphasis mine.

I've had exactly the same dilemma in the earliest version of Direct Ascent program - I had a idealistic trajectory plotted and guess what? It was never achieved.
The question is: how much of your theory are you able to program and verify by experiment in at least a simulator (if not real world). Ideally - in Orbiter. That's what this forum is about.

But what do I know? I'm just a dumb coder without official qualification proofs.
 
Last edited:

Thorsten

Active member
Joined
Dec 7, 2013
Messages
780
Reaction score
53
Points
43
You are aware of what a control loop is, yes?

Quite - but I'm also aware I don't need one for the launch performance tool Bob has mentioned. At least I have been discussing offlinish tools which don't receive any feedback from a real (or simulated 'real' - Orbiter reality) environment.

I also briefly talked about closed loop guidance earlier, and Keith G specifically said that this thread isn't about that.

I'm sorry if anything I said made you think this is about a control problem.

You can of course use your analytical solver iteratively.

Sorry - what analytical solver?
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
780
Reaction score
53
Points
43
I'm sorry if anything I said gave you the impression that I think PEG is inadequate for guidance problems - I wasn't talking about those. And I'm really not interested in 'internet jousting' as someone else put it and have everything I say tested whether it really is water-tight outside its context.
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
36,881
Reaction score
1,537
Points
203
Location
Langendernbach
I'm sorry if anything I said gave you the impression that I think PEG is inadequate for guidance problems - I wasn't talking about those. And I'm really not interested in 'internet jousting' as someone else put it and have everything I say tested whether it really is water-tight outside its context.

Come on. You know communication is bi-directional and you cannot not communicate.

I also don't have too much brain around for checking everything I write against the amount of flak I catch for it, but I know I must make sure that everybody I talk to must also understand what I say, otherwise I can save my breath for something better.
 

Enjo

Mostly harmless
Addon Developer
Tutorial Publisher
Donator
Joined
Nov 25, 2007
Messages
1,658
Reaction score
6
Points
38
Location
Hildesheim, Germany
Website
www.enderspace.de
I'm sorry if anything I said gave you the impression that I think PEG is inadequate for guidance problems - I wasn't talking about those.

Yes, you were:

PEG is from the 1970's or so... computing power was scarce then. These days numerically solving a trajectory in non-spherical gravity and a moderately detailed atmosphere model in discrete timesteps given an ascent guidance model doesn't even make your cellphone sweat.

My point is, I'd like to make Orbiter better. 70's or not, we have it and it works perfectly, even for multiple stages. The original topic was about ideal rocket equation. The guidance / non guidance / PEG discussion resulted form discussing a bad example of the rocket equation (example 1.), which mistake Keithth G already admitted. Why we are still on the discussion is out of my perception.

I just hope Keithth G survives the hurricane and he can bring input on the original topic, so that I can code in his stuff, resulting in more precise BTC and TransX models.

Call it a draw?
 

Thorsten

Active member
Joined
Dec 7, 2013
Messages
780
Reaction score
53
Points
43
Why we are still on the discussion is out of my perception.

It has to do with Bob Clark asking for feasibility of a launch performance estimator, to whose question I replied. As I said earlier, I'll leave you and Keith to solve your problem and won't speak up with regard to this any more.

The launch performance estimator of course needs a guidance model (look at the webpage he linked) - you need to tell it for instance how high you want to go vertically before you initiate the gravity turn and you need to tell it into what orbit to launch. But this is not a closed loop guidance requirement.

Yeah - I didn't spell this out explicitly, my bad...

So no, I really wasn't talking about PEG applicability for guidance problems.
 
Last edited:
Top