Optimum Launch problem

[mardlamock]

Hello everyone, I was just wondering if there is an equation that can describe the optimal trajectory for a rocket launch. Relating drag to velocity, altitude to air density, the drag coefficient as a fucntion of the mach number, the cross sectional area to the orientation with regards to the velocity vector, and also orbital mechanics. I know its a long list but if one was to actually have that equation then you could potentially get the least use of delta v and optimize rockets a lot. Thanks!

[Ralathon]

No. The most efficient launch you can do is a gravity turn, where you do a small adjustment to your attitude on a low altitude and slowly let the rocket tip over into an orbit. That way all your thrust goes directly into increasing your velocity instead of changing the direction of your velocity. The problem is that the equations for this don't have a solution if the TWR of the rocket varies throughout your launch. You have to do numerical simulations to figure out what the optimal trajectory is.

Adding in aerodynamics means is even harder. Computational fluid dynamics is an entire simulation branch on its own, it is very difficult to calculate out how an object behaves in air.

[mardlamock]

So, only numerical approximations? That sucks.

[Ralathon]

So, only numerical approximations? That sucks.

Yep, reality is unfair like that.

It's not too hard to write a simple program that simulates launches until it finds a good trajectory for you. But if you want to use something like kOS to do this inside KSP you're going to spend a long time on the pad while the processor does the number crunching.

[K^2]

A number of us have been working on cracking this optimization problem at least for KSP. There have been some decent numerical results. I was able to derive analytical solutions for certain stages of ascent, but not the whole thing. But there is nothing even close to a formula for the whole thing.

For early ascent, prior to gravity turn, ascent at terminal velocity gives you most altitude gain for fuel consumed. (That's an exact solution if you ignore I_SP variations. There is an exact solution that includes I_SP variations, but it's complicated.) Late in the gravity turn, when you are flying balls to the wall, there is an exact solution for the trajectory as well. But it's the transition from vertical ascent into gravity turn that's critical, and there is no analytical solution there.

Starting with these two, however, you can use numerical methods to patch the early gravity turn phase. I was able to use simulated annealing to get semi-descent results. And I know some people used numerical optimization packages to get really good ascent profiles. Unfortunately, that's the sort of computation that has to be done for the specific rocket configuration, and it takes a while. If you really want to optimize ascent for a specific design with specific payload. It's doable. But it's not something you can build into, for example, an on-the-fly module for the game.

It's not too hard to write a simple program that simulates launches until it finds a good trajectory for you.

It actually kind of is, because small variations often result in escape or re-entry. But it's far from impossible if you know what you are doing and have some patience, yes.

[Westi29]

KSP is a Monte Carlo Simulation lol.

[TythosEternal]

"Optimization" can mean many things. Let's say you want to breech the Karman line with minimal delta-v expenditure. It becomes primarily a tradeoff between a minimization of "gravity drag" (how much delta-v you use trying to move directly up in a gravity well) and atmospheric drag (delta-v lost to air resistance).

We can furture constrain the problem by stipulating a gravity turn after some pitchover conditions are meet. This is now a local optimization problem, and there may be solutions you won't capture, but in exchange we now have a fully-deterministic ascent profile, given certain boundary conditions.

Lastly, for a given vehicle configuration, we can search this well-formed space (altitude, pitchover angle, and turn control parameters) to converge on an optimal solution. At this point, the biggest problem is accounting for the staging characteristics of each unique vehicle--you've entered a min-max problem space, constrained by subjective measurements like separation risk.

The last sensitivity I should point out is that of models. How high are you shooting (i.e., what model determines your objective), what kind of atmospheric/drag/gravitational models are you using, how are you modeling and/or integrated control through the beginning, pitchover, and throttling sequences, etc.

If you are a controls scientist or systems engineer, "optimization" means something very specific. With a problem with these qualitative sensitivities and discrete/discontinuous behaviors, analytical optimization is a pipedream. However, proper constraints of your design space and selection of appropriate models will let you find a near-optional solution numerically.

[Z-Man]

- Continue at 45 degrees until 72000m, then turn to 90 degrees

Umm, if you mean actual height of 72km, that is almost certainly too late to be optimal. By the time you reach that height, your apoapsis is already way too high for anything close to an optimal flight for a typical rocket. If you mean "until your apoapsis as displayed in the map screen is at 72000 m", yeah, that would not be the worst rule of thumb.

[cpast]

Proper gravity turns are at an angle of attack of zero. Air drag really isn't that big a problem for real rockets; gravity drag is a bigger factor by far (plus, in reality, you cannot really fly at an angle of attack of 45 degrees; the rocket will break apart).

[Ralathon]

Ok, you guys are obviously very knowledgeable about the formulas. But for practical use, a general set of guidelines might be more helpful...

Assuming a straight, aerodynamic rocket with a single stage firing at a time, I'd imagine it like so:

- Ascend vertically until Terminal Velocity (aerodynamic effects begin showing)

- Tilt to the edge of Prograde indicator, maintain that edge until reaching 45 degree angle of attack to surface

- Continue at 45 degrees until 72000m, then turn to 90 degrees

- wait for Apoapsis and fire until circularized.

Now, the big question is whether to wait until Apoapsis or to keep burning and turning (edge of prograde) until circularized... This is where it gets confusing, because the rocket will generally still be within atmosphere at this point.

That's a guideline for beginners in stock KSP, where the atmosphere is made of corn syrup and angle of attack doesn't exist.

During a real launch you never want your rocket to point more than a few degrees from your prograde marker because the atmospheric stress will wreck your rocket and cause it to flip over. Furthermore, you want to continuously burn until you're in orbit since real life engines don't like restarts. You also want to use as little attitude adjustments as possible since a large attitude adjustment means wasted fuel which means a less efficient rocket.

All these things add up to a real gravity turn where you turn a few degrees right after launch and then follow the prograde marker down. By the time you're horizontal you're at orbital speeds.

Try flying a few rockets with FAR using your method. They'll break apart.

[R0cketC0der]

Furthermore, you want to continuously burn until you're in orbit since real life engines don't like restarts.

Actually there are quite a few engines that do have the ability to restart. However they usually don't restart in LEO missions, only in GTO or higher or when secondary payloads need to be put into separate orbits.

[Ralathon]

Actually there are quite a few engines that do have the ability to restart. However they usually don't restart in LEO missions, only in GTO or higher or when secondary payloads need to be put into separate orbits.

I know, but restarting an engine is a fairly complicated task. It means extra mass and the risk that they don't restart, which is why launch vehicles almost never bother.

If you'd launch IRL with a "Burn untill ap > 300km then coast" profile like KSP you'd be in serious trouble if your engine fails to reignite. You'd reenter the atmosphere at a very steep angle, so the G forces would squish you. Better to do it all in one long burn.

[cpast]

I think I've confused everyone with poor terminology. I meant hugging the edge of the prograde marker throughout launch, until reaching 45 degrees from vertical. At that point, I'm not sure whether to continue hugging the edge of prograde, or cut engines and wait for Apoapsis before burning horizontal.

Even that isn't done on real rockets - in a proper gravity turn, the only time that thrust is used to control direction is at the very beginning, during initial pitchover. Once the initial pitchover maneuver happens, the rockets are gimballed to point straight through the CoM (i.e. not gimballed to turn the rocket), so thrust is straight prograde. The trajectory flattens out due to gravity, not due to steering.

[Ralathon]

... but that doesn't happen in KSP... unless you turn off the SAS??

That's.... that's suicide....

Why do you think the rockets where blowing up left and right during the early years of the space race?

[rkman]

I think I've confused everyone with poor terminology. I meant hugging the edge of the prograde marker throughout launch, until reaching 45 degrees from vertical. At that point, I'm not sure whether to continue hugging the edge of prograde, or cut engines and wait for Apoapsis before burning horizontal.

The larger the angle to the horizon, the higher the gravity drag. Your trajectory seems to be far from horizontal for a major part of the ascent, so it will incur a lot of gravity drag. Atmospheric drag is in the order of a few 10's of m/s at altitudes above ~20k or so. (the total difference between an efficient ascent and an inefficient ascent can easily be in the order of a few 100m/s)

The part of the ascent above ~15k is more like a launch from an airless body, where you'd want to keel over to horizontal asap.

If the goal is to optimize for least delta-v to orbit then checking how close to optimal an ascent is, is simple with Mechjeb. It can show gravity drag, atmospheric drag, steering loss and delta-v spent.

[sgt_flyer]

... but that doesn't happen in KSP... unless you turn off the SAS??

That's.... that's suicide....

if your rocket is stable, with low drag parts (like nosecones) above the CoM and high drag (if any) below the CoM, it's actually quite feasible to turn off SAS to make a gravity turn the key is to know when to do it to make the pitchover (especially with keyboard - pretty difficult to make a small pitchover at low altitudes - so a bigger pitchover of a few degrees from vertical near 4000m is easier - then once it's stable after pitchover, disengage SAS - and the rocket will naturally try to follow the prograde marker - which will turn slow at first, then faster and faster just don't try it if your rocket is not stable in stock KSP (ex : tend to tumble as soon as you disable the SAS )

after that, it's trial and error for your various rockets models - each one will have a different pitchover. also, on kerbin, the planet's curvature will most likely make you need a coast phase to apoapsis.

Edited August 6, 2014 by sgt_flyer

[K^2]

sgt_flyer, an optimal trajectory meets first order optimal conditions. Back when I was starting to try and design an optimal path for KSP analytically, I've checked a few empirical ideas for optimal ascent, and "pitch over" was one of them. I can tell you that it does not make for an optimal gravity turn. It's close, but not optimal. (Specifically, simulation of a pitch-over ascent does not yield action which satisfies Euler-Lagrange equations.)

It might very well be, "Best one can do without doing complicated math," but it's not optimal.

[cpast]

In that case, why's it used on actual rockets? Is it just that it's close enough, and any more complicated thing leads to engineering problems?

[K^2]

Even with modern computers, solving a proper optimization problem for a real space ship ascent is a nightmare. Two decades ago, this was plain impossible. I think it's probably a case of "close enough for gov't work," combined with tradition arising from where it was best they could do.

Keep in mind, all I can test with Euler-Lagrange is if solution is optimal or not. I couldn't tell you how much fuel it actually costs you compared to optimal. In case of KSP, I know it's not much, because there isn't that much variation between an Ok ascent and great ascent to begin with. I suspect, that might be a case with rocket launches as well, and they might just be trying to go for something that's easier to compute, giving fewer places for things to go wrong, as well as something that has worked for decades.

P.S. Don't underestimate tradition in aeronautical design. I don't know how much of that they have in rocket design, but there are a number of features of modern airliners that are known to be sub-optimal, and yet they persist purely out of tradition. For example, the forward sweep of the tail stabilizers has been known to give better performance for a very long time. Yet there are very few airplanes like that.

Edited August 7, 2014 by K^2

[GoSlash27]

Hello everyone, I was just wondering if there is an equation that can describe the optimal trajectory for a rocket launch. Relating drag to velocity, altitude to air density, the drag coefficient as a fucntion of the mach number, the cross sectional area to the orientation with regards to the velocity vector, and also orbital mechanics. I know its a long list but if one was to actually have that equation then you could potentially get the least use of delta v and optimize rockets a lot. Thanks!

There's not, and I doubt there ever will be. There are simply too many interdependent variables at work. You can, however, come up with very good empirical launch profiles simply through simulation or trial and error. They won't be ideal, but they'll be close enough that you won't miss the difference.

When you get to the point where minor variations in your launch profile cost you less than the granularity of the parts themselves,... well, your profile might not be perfect, but you can rest assured that the imperfection is small enough to be negligible.

Best,

-Slashy

[Laie]

I was able to derive analytical solutions for certain stages of ascent, but not the whole thing.[...] Late in the gravity turn, when you are flying balls to the wall, there is an exact solution for the trajectory as well.

Care to share? I've been looking for that a while ago... in the meantime, I found a "good enough" solution in the way GoSlash describes. But I'd still like to know how good it really is.

[fibonatic]

I have come up with the following equations of motion:

Where C is variable containing all drag parameters and alpha the applied acceleration by the engine(s).

I also used this to solve for an optimal solution numerically and got 4200 m/s for a 75 km orbit. I also tested this in KSP with the help of kOS, but was only able to reach orbit with ~4300 m/s.

[K^2]

You are missing centrifugal and Coriolis terms due to ̉ۡ_s in your EoMs.

[fibonatic]

The centrifugal component is the final component of the top equation, however it might be confusing because I divided everything by v_r. The same goes for Coriolis effect, but I did assume that the trajectories always stays on the plane of the equator. And to clarify ̉ۡs is the sidereal angular rotational velocity of the planet. However I do would like to thank you because I did forgot to incorporate the Coriolis effect in my model which did change my predicted optimal solution (closer to the values of my experimental results).

[K^2]

Yeah, sorry, I got a bi mixed up. I thought you were in a rotating frame, but that is exactly when you would not need to subtract omega_s to get relative wind. So these are right. The v_theta/r takes care of Coriolis. Do you mean that you left it out of computation? That would, indeed reduce apparent dV requirement. Makes sense.

I think, I will switch over to these eoms for my tests. They are more convenient than coords I was using. The methods are very similar, but because I work with parameterized forms, I can dump optimizer into C# code and have it run on the fly as a plugin.