I need someone help me do some math for launch optimization

[tavert]

They're in MechJeb, I don't really know what the default window settings are but it might be there in a window called "Ascent stats" or something to that effect. If there's not a preset for them, you can add them to a window with the custom editor. I don't remember which category they're under, but they're in there somewhere.

[K^2]

im struggling with understanding the following

When i start straight up, shortest possible path through the thick atmosphere, then i coast for over a minute to 80 km. 20 sec before i reach AP i turn east, full thrust.

So i accelerated in the most efficient way to reach the altitude and didnt waste any force to gravity but accelerated horizontally where i had zero drag resistance.

I built a test rocket with 4100dv, with this attempt i reached 1600 orbital speed when the fuel ran out.

If i launch with mechjebs auto with turn at 8 and 40%, i reach 1900 orbital speed...

So im wondering where am i losing in the first attempt or what effect gives the second one this gain. Thats why i brought oberth into this.

Simplest way to understand this is to consider the centrifugal effect of your orbital velocity as reduction of gravity. As you start to accelerate horizontally, it's as if you perform ascent in lower gravity, letting you reach higher altitude with lower vertical velocity. So going straight up, then accelerating horizontally is way less efficient than starting to build your horizontal speed early. Of course, you don't want to start too early either, because that would result in too much drag. Hence the whole procedure of gravity turn, and figuring out the best way to do that.

Speaking of which, I have an idea on how to do full 2D optimization in a much more elegant way. But I'm finding that just running simulations is a bit boring. Is there a way to feed a curve with throttle and attitude to MechJeb, or some other plugin, perhaps? Or am I better off writing one from scratch?

[numerobis]

The ascent computer in MechJeb is almost written in a general way (there's an IAscentPath), so it's a good start.

[K^2]

Ah, I see. I didn't realize source for MechJeb was available. Yeah, that gives me an ideal starting point. Thank you.

[rkman]

im struggling with understanding the following

I built a test rocket with 4100dv, with this attempt i reached 1600 orbital speed when the fuel ran out.

If i launch with mechjebs auto with turn at 8 and 40%, i reach 1900 orbital speed

You need to count on at least 4500dv for low Kerbin orbit (the record is at little over 4300dv iirc), final orbital speed is a little over 2200.

[K^2]

I think I just wrote the worst optimizer ever. Pro-tip. Discrete space techniques do not work for trajectory optimization. This would make an awesome path-finder, though. Back to the drawing board.

[NikkyD]

If mechjeb can be fed some path, what would/should be the criteria for control ? I mean like "at x altitude do this" ?!

What points define when to turn and how much, i think its altitude or not ?

[tavert]

I think I just wrote the worst optimizer ever. Pro-tip. Discrete space techniques do not work for trajectory optimization. This would make an awesome path-finder, though. Back to the drawing board.

That's about what I expected for genetic algorithms, but I was kinda hoping you would come up with something that surprised us all

If you want to try a different approach (besides PSOPT which has successfully worked for alterbaron and mhoram), I recommend using the Ipopt solver (I've tried many, and Ipopt is the only general-purpose open-source nonlinear optimization solver that's worth using) via either the Coopr/Pyomo modeling language, or through Casadi.

If mechjeb can be fed some path, what would/should be the criteria for control ? I mean like "at x altitude do this" ?!

What points define when to turn and how much, i think its altitude or not ?

The MechJeb ascent autopilot parameterizes its trajectory with a handful of numbers: target orbit altitude, gravity turn start altitude, turn end altitude, final flight path angle, and turn shape. Then there are optional thrust control settings like limit to terminal velocity, limit to a specified throttle percentage, or limit to a maximum acceleration in m/s^2. There's also a "corrective steering" option which adjusts pitch up or down to try to make the rocket's velocity direction match the provided pitch-versus-altitude path, rather than the default behavior of just setting pitch equal to the provided path and not trying to control the velocity direction.

[mhoram]

The ascent computer in MechJeb is almost written in a general way (there's an IAscentPath), so it's a good start.

IAscentPath is there to calculate pitch based on altitude.

As a starting point it is good, but it will run into problems when the same altitude is crossed twice or more often.

Generating ascent profiles based on my PSOPT simulation I ran into such an example while testing one of Kasuhas' lifters.

For testing my implementation I created several rockets with different TWR distributions.

https://www.dropbox.com/sh/3pi0zifgfsn0ehp/cm2atqMjya

Feel free to use them for your tests under the CC BY-NC-SA 4.0 license. So far I did not manage to bring "Slowgoing.craft" into orbit.

Currently I am writing a reimplementation of my PSOPT-based simulation for an arbitrary number of states, but it still has some issues.

If you want to try a different approach (besides PSOPT which has successfully worked for alterbaron and mhoram), I recommend using the Ipopt solver (I've tried many, and Ipopt is the only general-purpose open-source nonlinear optimization solver that's worth using) via either the Coopr/Pyomo modeling language, or through Casadi.

PSOPT also uses Ipopt as standard solver besides the commercial SNOPT.

I found http://bocop.org/ to be interesting as a control solver, but did not get too much into the details.

Is there a way to feed a curve with throttle and attitude to MechJeb, or some other plugin, perhaps? Or am I better off writing one from scratch?

kOS Scriptable Autopilot System seems to have a reasonable manageable interface via file loading. Last time I looked, it seemed abandoned by it's creator, but a few days ago, a new maintainer and 0.23 compatible version emerged.

[K^2]

That's about what I expected for genetic algorithms

Nah. That was a different approach. Genetic algorithms have demonstrated an ability to take an almost optimal path, and tune it up. They just aren't very good at converging when you start very far from an optimum. So I might still make use of them if I find a good approximate solution analytically.

I do have a couple of other ideas I'm trying out. I'll figure something out eventually.

[Suzie's Brother Max]

I'm not sure if this is the best way to bring this up, but here goes.

alterbaron's optimized ascent profile from an airless body from page 6 seems to imply a standard gravity turn from launch. Tavert, I've been stalking your math around the forums for a few days. Topic of interest here is that his profile doesn't include constant altitude burning, which you have proven fairly rigorously elsewhere. Does the physics not reverse such that a constant altitude descent onto an airless body isn't equivalent to a constant altitude ascent? Is one of these models flawed in some way? I'd appreciate some clarification here.

[tavert]

alterbaron's optimized ascent profile from an airless body from page 6 seems to imply a standard gravity turn from launch. Tavert' date=' I've been stalking your math around the forums for a few days. Topic of interest here is that his profile doesn't include constant altitude burning, which you have proven fairly rigorously elsewhere. Does the physics not reverse such that a constant altitude descent onto an airless body isn't equivalent to a constant altitude ascent? Is one of these models flawed in some way? I'd appreciate some clarification here.[/quote']

Hm, good question. I never rigorously proved that constant-altitude is actually optimal, just demonstrated with some numerical simulations that it takes less delta-V than a retrograde landing. And suspected that it is likely optimal in the case of target altitude at 0, since it's on the boundary of the feasible space - it's a non-convex problem though, so that suspicion could be wrong.

Ascent and descent are (almost) time-reversals of one another, they're equivalent up to swapping the initial and final conditions, or changing the sign of the specific impulse - in takeoff you get lighter as you speed up, landing you get lighter as you slow down. It might be that with a high target orbit (400 km in alterbaron's example) it's actually advantageous to do some of the burn at higher altitude than just above terrain, since the higher your altitude, the higher you can raise periapsis to. That will make the circularization burn at your target altitude smaller than the case of constant-altitude takeoff to low circular orbit then Hohmann transfer to high orbit.

If you're up for some math, the airless landing/takeoff case may be tractable as a Pontryagin principle boundary value problem to get a provable optimum. I hope it would output the constant-altitude trajectory if target altitude is set to 0, but the higher your target altitude the more divergence you might see.

Edited February 7, 2014 by tavert

[K^2]

Ascent and descent aren't quite time-reversals due to mass of the ship changing the wrong way. Since thrust is constant, you can actually end up with different optimal profiles for airless landing and ascent.

Edit: I've been able to do a bit more with analytical side of things. First, for vertical ascent, given variations in gravity and drag coefficient with altitude g(y) and k(y) respectively, yielding thrust

T[y,t] = g(y(t)) + k(y(t)) y'(t)² + y''(t)

The solution y'(t) = Sqrt(c(y(t))/k(y(t))) is locally optimal whenever c'(y) = g'(y). In other words, vertical ascent is optimal at terminal velocity even with arbitrary variation in gravity and air density with altitude.

I know everyone suspected as much, but it's nice to have a rigorous proof of it.

The other thing is that in constant density and gravity ascent, if you have to apply some horizontal thrust to maintain course, say T_x, the optimal ascent velocity goes from Sqrt(g/k) to Sqrt(Sqrt(g²+T_x²)/k). In other words, it behaves as if instead of gravity g, the craft experiences gravity Sqrt(g² + T_x²), which does make a lot of sense. Unfortunately, I have not been able to prove this for general g(y) and k(y), because algebra is a total mess, but it should at very least be close for small g'(y) and k'(y).

Finally, if we now take 2D motion, and consider drag along y, we have k v_y Sqrt(v_x² + v_y²). This can be expanded nicely under two possible conditions. Whenever v_y > v_x, this becomes k v_y² + k v_x²/2. While expansion for v_y < v_x yields, k v_x v_y + k v_y³/(2 v_x).

What this lets me do is split the horizontal and vertical motion and then use some iterative methods to find mutually-optimal v_x and v_y throughout the ascent. There is still a whole list of nuances with that, but it should at least put me on the right track.

Edited February 7, 2014 by K^2

[hydropos]

I will start by admitting that I skimmed most of this thread after about page 4, so please let me know if I missed something. This and other threads on the topic seem to focus on simulating different paths and rocket constructions. What I sought out to do was find the minimum ∆V ascent trajectory to Low Kerbin Orbit (LKO) purely mathematically. This ignores anything about mass, thrust, or ISP. I caught some inspiration yesterday and appear to have something. The two most notable findings were this:

1) You should only ascend at terminal velocity until you hit 440 m/s, then stay at that speed until your gravity turn

2) Any gravity turn under 30km will cost you ∆V

Note, this also produces the result that the "ideal" gravity turn should be instantly 90°, and assumes your TWR is absurdly large (~10), which may explain why most launches do not work this way.

Here is my reasoning. Let me know if I'm missing something:

1) It's already been established that the most efficient ascent at low altitudes is totally vertical at terminal velocity. However, since all that vertical velocity will eventually be gone (assuming a roughly circular orbit) continuing to accelerate to the exponentially-increasing terminal velocity must become wasteful at some point. Here is my math:

lost ∂V/∂t = gravity + drag + net acceleration

where gravity and drag are their corresponding accelerations, rather than raw forces. At terminal velocity (VT), gravity and drag will be equal. If you're trying to maintain terminal velocity, then net acceleration will be the derivative of terminal velocity (∂VT/∂t). I also rearranged things in terms of lost ∂V per altitude gained (∂y) so that the solutions at V = 0 didn't muck up my calculations. This means dividing the right side by the velocity (assumed to be VT):

lost ∂V/∂y = (2*g + ∂VT/∂t)/VT

where VT = 6.01*10â·*exp(y/10000)/(600000+y) {assumes ship drag = 0.2}

This function has a minimum value at a height that depends on drag coefficient, which is about 15.1km for liquid fuel rockets (drag 0.2) and 17.1km for solid fuel rockets (drag 0.3). However, they both happen at a velocity around 440 m/s. After that minimum, any additional acceleration is going to be wasted ∆V, since all that vertical velocity must eventually go to zero. Thus you should stay at 440 m/s until the gravity turn.

2) The cheapest ∆V way to gain altitude in the absence of atmosphere is to burn horizontally. With atmosphere, the centrifugal acceleration benefit of turning sideways must outweigh the added drag. Their accelerations are as follows:

centripetal acceleration = -V²/(Kerbin's Radius + Current Altitude)

drag ≈ V²*0.0011/exp(altitude/5000)

I use a negative sign in front of the centripetal force, since that quantity is ultimately being subtracted from gravitational acceleration. Also note that V is only the horizontal component of velocity. You can factor the V² out to get the net effect:

acceleration = V²[0.0011/exp(y/5000) - 1/(6*10âµ+y)]

Only when this term becomes negative is it beneficial to have any non-vertical velocity (32km). Note this drag equation is based on a mass-average drag value of 0.2, which is the case for liquid fuel rockets. For higher drag vessels (say solid rockets with drag 0.3) this altitude is just over 34km.

Final Notes

I did some numerical integration for both the low and high drag cases to toss out some values for the minimum ∆V. From launch to the critical terminal velocity of 440m/s should require 1935 or 2361 m/s for liquid and solid rockets respectively. From launch up to the "gravity turn" should require 2392 or 2816 m/s for liquid and solid rockets respectively. After this point you no longer have to spend ∆V to fight gravity and drag is next to nothing, so I would add to these the ∆V of LKO, 2293 m/s. If you've launched eastward, then you can subtract around 180 m/s from Kerbin's rotation. This gives:

minimum LKO ∆V: 4505 m/s for liquid fuel rockets and 4929 m/s for solid fuel rockets.

You can get pretty close you this in practice because most of these functions are aren't steep near the minima. In other words, you don't need a TWR of 10 to do well. If you've ever wondered if it's possible to build an all-solid fuel SSTO, you now know the answer is no, but only by about 150 m/s ∆V.

Edited February 11, 2014 by hydropos

[K^2]

I've managed to advance on the analytical approach. This will probably require a numerical solver in the end, but it could still be the closest to a true answer.

Lets start by looking at a simple problem of purely vertical ascent. I'm going to ignore gravity variations with altitude, as well as variations in I_SP, and even the change in mass of the ship during ascent. These can be added, but I want to keep the math clean for the purpose of explanation.

What we are after is minimizing the use of fuel. It is equivalent to optimizing the integral of thrust.

∫ g + k(y)y'(t)² + y''(t) dt

Here, k(y) is drag coefficient at altitude y, such that, sqrt(g/k(y)) gives terminal velocity at altitude y. And since this is KSP, I've set m = 1.

Plainly, this is Euler-Lagrange problem with L = g + k(y)y'(t)² + y''(t). Solution, if it exists, must satisfy Euler-Lagrange Equation.

∂L/∂y - (d/dt)(∂L/∂y') + (d²/dt²)(∂L/∂y'') = 0

Fortunately, in this problem ∂L/∂y'' = 1, which goes away after differentiation with respect to time. This leaves us with fairly simple terms.

k'(y)y'(t)² - 2k'(y)y'(t)² - 2k(y)y''(t) = 0

or

k'(y)y'(t)² + 2k(y)y''(t) = 0

It is fairly straight forward to verify that y'(t) = (c/k(y))^1/2 satisfies this equation. This presents us with family of potential solution, one of which, c = g, is the ascent at terminal velocity that we all know to be optimal for strictly 1D problem.

So the Euler-Lagrange method works extremely well. Even if we did not have means of finding this solution analytically, we could have integrated over it numerically with a good guess for initial conditions. But as soon as we go into 2D, we end up with a serious problem. The algebra there is significantly worse, but lets just look at the acceleration term in the Lagrangian.

L = ... + (x''(t)² + y''(t)²)^1/2

Unlike the 1D case, the (d²/dt²)(∂L/∂y'') term of the Euler-Lagrange equation for this Lagrangian is not zero. Worse, it contains y⁽⁴⁾(t) terms! That means that even after doing the monumental work of writing out the full differential equation, it will be fourth order in time. Not to mention extremely unstable to initial conditions. Solving such an equation numerically does not seem feasible. (I have made many different attempts.)

But there is light at the end of this tunnel. Instead of analyzing Euler-Lagrange problem, we can construct an equivalent Hamiltonian problem. First, let us re-write the initial Lagrangian in terms of individual variables T(t), y(t), and v(t), where T(t) is thrust and v(t) is vertical velocity. I'm going to define λ and λ_v as my undetermined multipliers. Also, for convenience of signs, I'm going to maximize integral over -T(t), rather than minimize one over +T(t).

L = -T(t) + λ(y'(t) - v(t)) + λ_v(v'(t) - T(t) + g + k(y)v(t)²)

With constraints y'(t) = v(t) and v'(t) = T(t) - g - k(y)v(t)². Substituting constraints directly into the above equation and getting rid of undetermined multipliers brings us back to initial problem, so it looks like needless complication, but it allows us to change the formulation of the problem. Stated thusly, we have are looking at a control problem, where T(t) is control, and y(t) and v(t) are variables. As such, we can find conjugate variables, ∂L/∂x' and ∂L/∂v', and write the Hamiltonian for this problem.

H = (∂L/∂x')x'(t) + (∂L/∂v')v'(t) - L

Looking after all the math and making a substitution x'(t) = v(t), we arrive at a very nice and clean expression.

H = T(t) + λv(t) + λ_v(T - g - k(y)v(t)²)

What's more amazing, the undetermined multipliers have become the conjugate variables to the variables of our problem, as they satisfy the following properties.

x'(t) = ∂H/∂λ = v(t)

v'(t) = ∂H/∂λ_v = T(t) - g - k(y)v(t)²

Which agree with our constraints. And that means we can apply the Hamilton Equations for the conjugate variables.

λ'(t) = -∂H/∂x = λ_vk'(y)v(t)²

λ_v'(t) = -∂H/∂v = 2λ_vk(y)v(t) - λ

And, of course, the actual optimization problem is stated very simply.

∂H/∂T = 1 + λ_v = 0

This works because there is no T' or higher order dependence. Other than that, the conditions are the same as in Euler-Lagrange equations. At any rate, we can solve the above by taking a time derivative and using one of the Hamilton equations.

(d/dt)(1 + λ_v(t)) = λ_v'(t) = -∂H/∂v = 2λ_vk(y)v(t) - λ = 0

Here, we can make use of the fact that 1 + λ_v = 0 to simplify it a bit. (I'm also going to flip the sign for convenience.)

λ + 2k(y)v(t) = 0

Which I can differentiate with respect to time once more and use the other Hamilton equation.

λ' + 2k'(y)v(t)² + 2k(y)v'(t) = λ_vk'(y)v(t)² + 2k'(y)v(t)² + 2k(y)v'(t) = 0

Using 1 + λ_v = 0 one last time, we arrive at the final differential equation.

k'(y)v(t)² + 2k(y)v'(t) = 0

This is clearly the same differential equation as earlier, with solution v(t) = (g/k(y))^1/2.

So the Hamiltonian method works. But that's not the best part. The best part is that we've completely gotten rid of the y'' terms from the start. Of course, what we are really interested is the 2D case with all the bells and whistles. And while the equations that the above procedure produces for the 2D Hamiltonian are absolutely monstrous, the terms with highest order are the T_x''(t) and T_y''(t).

In other words, the above procedure lets us cast the entire problem in terms of a system of non-linear second order differential equations. The sheer count of terms involved means that there is little to no chance of ever finding an analytical solution, but this is entirely within the reach of numerical methods.

Unfortunately, the solution is extremely unstable to initial conditions. This has not improved. Where this is miles better is that the time-reversed solution is stable. What does that mean? In simple terms, we start with the ship in orbit at the very edge of the atmosphere, we run the time backwards on the numerical integration. Thrust and variables of motion are going to be adjusted continuously until the ship hits the ground, and that's going to give us the initial conditions for the launch. To reproduce in the actual launch, we just run a PID trying to maintain program location and velocity from above, and it should perform an optimal ascent to a stable orbit.

There is still a lot of work here. Numerical solvers in Mathematica have not been of much help, because they miss a few optimizations I can do, and I have no idea how to point the built-in solver in the right direction. So I'll have to write my own solver, export the monstrous equations into C++, clean these up, run it, and then find a way to test it on real ships in KSP. But what I have so far looks promising.

Anyways, comments and questions are welcome.

[rkman]

minimum LKO ∆V: 4505 m/s for liquid fuel rockets

Experiments show 4500m/s is the rule-of-thumb required dv for LKO, minimum is a little over 4300m/s.

I more or less routinely get there with something between 4400 and 4500m/s. The critical part seems to be when to cut back thrust for the upper part of the ascent.

[mhoram]

Unfortunately, the solution is extremely unstable to initial conditions. This has not improved. Where this is miles better is that the time-reversed solution is stable. What does that mean? In simple terms, we start with the ship in orbit at the very edge of the atmosphere, we run the time backwards on the numerical integration. Thrust and variables of motion are going to be adjusted continuously until the ship hits the ground, and that's going to give us the initial conditions for the launch. To reproduce in the actual launch, we just run a PID trying to maintain program location and velocity from above, and it should perform an optimal ascent to a stable orbit.

For the Psopt-approach, an initial guess is also necessary. I made this by approximating the 3d-altitude and velocity vectors. Are you interested in the actual code I used?

There is still a lot of work here. Numerical solvers in Mathematica have not been of much help, because they miss a few optimizations I can do, and I have no idea how to point the built-in solver in the right direction. So I'll have to write my own solver, export the monstrous equations into C++, clean these up, run it, and then find a way to test it on real ships in KSP. But what I have so far looks promising.

I am also looking for a way to get my launch results to steer the rocket ingame. I came so far as to get my values (time, pitch, thrust) into the game via a socket connection, but had no time to improve it the last couple of weeks.

minimum is a little over 4300m/s.

I have read this minumum now several times here on the forum, but was unable to find an actual craft that could do it with this meager amount of dV. Do you have by any chance a link to the original thread where this was stated?

[rkman]

Launch Efficiency Exercise [updated for 0.21.1]

http://forum.kerbalspaceprogram.com/threads/39196-Launch-Efficiency-Exercise-Updated-for-0-21-1

A couple are in the range of 4.3..km/s

[K^2]

For the Psopt-approach, an initial guess is also necessary. I made this by approximating the 3d-altitude and velocity vectors. Are you interested in the actual code I used?

Sure, if you can paste-bin it, I'd appreciate a look.

I have read this minumum now several times here on the forum, but was unable to find an actual craft that could do it with this meager amount of dV. Do you have by any chance a link to the original thread where this was stated?

This figure also has some good pedigree in the optimization theory. A rule of thumb for minimal delta-V is orbital velocity + drag/gravity losses on vertical assent (4gH/v_t), and the later works out to be just shy of 2km/s for Kerbin. So any optimal ascent method should show something in the neighborhood of 4.3km/s for orbit. If you are getting much more than that from the method, then it's not converging properly. There could be local minima in this problem that can throw even a good optimization scheme.

[Nao]

I've managed to advance on the analytical approach. This will probably require a numerical solver in the end, but it could still be the closest to a true answer.

[math!]

Anyways, comments and questions are welcome.

This is really awesome! Although i'm unable to help with math i really appreciate the work going into it. Thinking ahead i'm really curious about how big the maximum optimal TWR of a rocket will be (excluding v=0 of course, it will most likely be achieved during gravity turn around 30-45deg, probably 3-4 TWR). And then optimize it for minimal launch mass .

Good luck guys! (PTW)

[tavert]

There is still a lot of work here. Numerical solvers in Mathematica have not been of much help, because they miss a few optimizations I can do, and I have no idea how to point the built-in solver in the right direction. So I'll have to write my own solver, export the monstrous equations into C++, clean these up, run it, and then find a way to test it on real ships in KSP. But what I have so far looks promising.

Isn't this just applying the Pontryagin principle to express the solution in terms of a boundary value problem? I don't see how this is any different than what I was trying on page 4. If you come up with a shooting solver, either forward or backward or multiple-shooting, that can converge to good values of the initial or final costates, let us know.

If C++ is too much of a PITA, you may want to have a look at writing in Julia. It's a new language, still a bit rough around the edges, but it's aiming at a nice best-of-both-worlds combination of Python's high-level productivity and close-to-C++ speed.

[K^2]

Yes, it's basically Pontryagin without discount. What I didn't realize is that a) this is equivalent to Lagrangian approach, and that it resolves a lot of the issues with the later. Sorry, I missed the part of the discussion where you talked about that. This was new to me, so I thought I'd share.

There are still a lot of problems with it, and I'm starting to get the feel for why. Usually, if you do reverse shooting with Pontryagin, you start near steady state solution, and evolve back. This problem doesn't have a (useful) steady state. And it also has a lot of regions where it's really, really unstable. So I can't find good boundary conditions for forward or reverse shooting.

I do have a completely different sort of a result, however. An analytic approximate solution for optimal 2D ascent with KSP drag model. There are a few main assumptions. Acceleration of the craft should be small, centrifugal effect negligible, and changes in gravity, mass of the ship, and efficiency of the engines is neglected. This is going to hold moderately well up to about 20km, but will get rather bad from there on. The solution requires the craft to move at terminal velocity regardless of angle, with the angle itself satisfying the following equation.

cos(θ) = c exp(y/2h)/sqrt(1 + sin(θ))

Here, y is the altitude, h is scale height, and c is some constant that determines boundary conditions. So for example, if you intend to have θ = 45 degrees at 20km, then c = 0.125. Angles at other altitudes can be easily solved for with the power method. (It converges rather well for this formula.) So for the same 45 degrees at 20km example, the following is the chart of ascent angles with altitude. (Apologies for Excel)

This is pretty consistent with typical ascent profiles. The question is, of course, what sort of angle the rocket should be holding to at the upper bounds of this approximation to do an optimal accent. I picked 45 degrees pretty much at random for this graph. Though, it should be in the ballpark, at least. With the correct figure, this profile can be patched together with other approximations for higher velocities.

Edit: Looking at some of the alterbaron's results, 20km was probably too generous. Centrifugal effects start to alter effective terminal velocity by then. But up to about 10-15km, all of the assumptions seem reasonable.

Edit2: I finally got around to checking the above solution against Euler-Lagrange equation. As suspected, it's extremely close to optimal ascent up to about 10km, and the rapidly gets worse thereafter.

Edited February 27, 2014 by K^2

[mhoram]

Sure, if you can paste-bin it, I'd appreciate a look.

I just looked over the code and realized that it is so fuzzy that I had myself problems understanding it. So I will do the hopefully better thing: describe the algorithm.

The following parameters are used for the estimation:

• Time of pitchover t_p
  
• Time when orbit is reached t_o > t_p
  
• Target Orbit altitude a_o > 0
  
• Target horizontal speed v_t = sqrt(PlanetMu / (PlanetRadius + a_o))
  

The altitude at time t is approximated by

alt = tanh((t - (t[SUB]o[/SUB] / 2)) / t[SUB]o[/SUB] * 4) * a[SUB]o[/SUB] / 2 + a[SUB]o[/SUB] / 2

The vertical velocity v_v at time t is approximated by

v[SUB]v[/SUB] = 2 * a[SUB]o[/SUB] / t[SUB]o[/SUB] * (1 - tanh((4 * t - 2 * t[SUB]o[/SUB])/t[SUB]o[/SUB])[SUP]2[/SUP])

As you can see, I don't use the time of pitchover for estimating the vertical components.

I came to this tanh-altitude approxmation by looking at the ascent paths that the algorithm found during my initial examples (see the pictures in this thread).

The velocity was chosen to reflect this altitude path.

The horizontal velocity v_h relative to planet rotation is 0 if current-time t < t_p, v_t if current-time > t_o and otherwise:

v[SUB]h[/SUB] = ((t - t[SUB]p[/SUB]) / (t[SUB]o[/SUB] - t[SUB]p[/SUB]))[SUP]2[/SUP] * v[SUB]t[/SUB]

I came up with this t² approximation by guesswork and since it worked reasonably well, I did not improve it further.

The angular distance from the launchsite I estimated by a simple euler integration via the horizontal velocity estimations. Again it worked reasonably well and did not need further improvement.

The mass of the ship in each stage is approximated linear in time.

This figure also has some good pedigree in the optimization theory. A rule of thumb for minimal delta-V is orbital velocity + drag/gravity losses on vertical assent (4gH/v_t), and the later works out to be just shy of 2km/s for Kerbin.

That sounds reasonable. Thanks for the explanation

@rkman thanks for the link

Edited February 28, 2014 by mhoram

[Nao]

There is a concept on the subject I had on my mind for some time. It's nothing special but ill post it in hope of inspiring others with some ideas and maybe fresh point of view.

After many launches I came to conclusion that maybe it could be possible to present optimal late ascent (after ~45deg) as a minimum losses between drag and dv lost to Oberth effect (with an attitude fixed to prograde simplification, just using throttle to control the ship).

I have no math ability to present this idea in equations. But just looking at the problem: during ascent, after the craft manages to accelerate to have an Apopsis of 40-50km (an altitude where it can achieve orbital velocity), the optimalization of ascent is simplified to balancing the acceleration while on the path to orbit. The idea is to use thrust to control pitch with shape of current orbit. High acceleration rate will shoot Ap up quickly, minimizing thrust in the atmosphere, increasing Oberth losses. Slow acceleration increases time spent in atmosphere and drag. Different non linear acceleration profiles will give better efficiency.

I think the idea of using attitude fixed to prograde late in ascent could really help simplify some equations. It shouldn't give much error too as steering angle looses can be quite big when burning more than 3-5 deg off prograde. At the same time calculating gains from Oberth also covers centrifugal acceleration as well as orbital vector elements etc.

It's of course hard to quantify the gains/looses from Oberth effect, but when doing real (by hand or MJ assisted) launches this is what i try to optimize for. After many tests I can get to very similar deltaV results with different starting conditions of late ascent (angle, speed, available thrust etc), just by using the correct amount of throttle at the right time, and following velocity vector.

Also assuming different target orbits another, even simpler, connection between target orbit height and "turn end" height could be made. Since for higher orbits its much easier to get out of the atmosphere. For example completing lunar insertion burn at Pe (0deg attitude) at 50km will be quite efficient and still will get out of the atmosphere quickly. Just comparing target orbit height with "turn end" on the basis of drag losses and Oberth gains, could give a simple but useful relation.

Sorry if this sounds like gibberish. I just feel like trying to rely mostly on terminal velocities and turn angles will not give good enough results (especially for late parts of ascent).

(Also damn, not filling up math equation quota makes this feel like an off topic post. Haha)

[mhoram]

I think the idea of using attitude fixed to prograde late in ascent could really help simplify some equations. It shouldn't give much error too as steering angle looses can be quite big when burning more than 3-5 deg off prograde. At the same time calculating gains from Oberth also covers centrifugal acceleration as well as orbital vector elements etc.

It's of course hard to quantify the gains/looses from Oberth effect, but when doing real (by hand or MJ assisted) launches this is what i try to optimize for. After many tests I can get to very similar deltaV results with different starting conditions of late ascent (angle, speed, available thrust etc), just by using the correct amount of throttle at the right time, and following velocity vector.

Keeping attiute at prograde seemed to me the way to go at first. It works quite well for most rockets with a "reasonable" TWR in all stages. However this method does not work for rockets with a low TWR in late stages. See this post for an example craft where the attitude=prograde method does not work.

Sorry if this sounds like gibberish. I just feel like trying to rely mostly on terminal velocities and turn angles will not give good enough results (especially for late parts of ascent).

(Also damn, not filling up math equation quota makes this feel like an off topic post. Haha)

It is an interesting idea, but I think that the calculation of "oberth losses" based on the thrust-altitude-distribution is quite a difficult task by itself.

Edited September 26, 2015 by mhoram
typo