I need someone help me do some math for launch optimization

[rkman]

I hadn't seen this mentioned yet, seems similar to what you guys are trying to do:

Ascent Komputron

http://forum.kerbalspaceprogram.com/threads/59899-NET-Ascent-Komputron-rocket-simulator-ascent-optimization-aerobraking

[Nao]

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.

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

Yeah, calcualtion of deltaV changes due to the Oberth effect is above my mathematical ability at the moment, that's why i turned with the idea to this forum . The one thing that i like about this it is that it solves every orbital and momentum related element of ascent (including vertical speed, angle of climb, lift due to centripetal acceleration) just by speed (and altitude) variable. And it could then be directly compared to another variable based on speed and altitude, the drag. It just looks like it could work.

It would be hard to implement this to low TWR rockets, but i'm just trying to simplify the problem, to actually get a working solution for whole ascent.

Actually even without looking at Oberth, the "fix to prograde" could be useful to weed out one variable from late ascent. I feel like steering looses would be one thing that would trend to zero during ascent with optimal path. And coming with the solutions from both sides of ascent path (vertical climb and late ascent) could potentially help determine the hardest part, gravity turn.

[K^2]

Yeah, calcualtion of deltaV changes due to the Oberth effect

There aren't any. Obereth effect only affects the energy gains. Delta-V is always the same and depends only on I_SP and mass ratio of consumed fuel.

[Nao]

There aren't any. Obereth effect only affects the energy gains. Delta-V is always the same and depends only on I_SP and mass ratio of consumed fuel.

Ah yes sorry i'm dead tired. Thought about "Dealta-V requirement to target orbit", as a measure of efficiency.

This also points on the my main problem, as common energy losses (gravity, drag, steering) can be shown in speed change (deltaV) over time. But i have no idea how to show dynamic energy changes during transfers from orbital state to another using different paths. (The best i know is about impulsive burns at Ap/Pe but that's no good for ascent where we never burn at orbit's major-axis)

[K^2]

It's not that simple. If you take a circular-to-circular transfer, the optimization problem has very simple solution. Infinitely short burn to go to Hohmann, then another infinitely short burn at ap to circularize. Naturally, you can't do infinitely short burns, as that requires infinite thrust, but you do the best you can, and that's your fuel-optimal policy.

When you start talking about transfers between general orbits, things are a bit more complicated, but you can still find optimum fairly easily by optimizing energy and angular momentum gains. Former would be accounted for with Obereth effect, yes. Later is optimal at maximum distance from parent body. (And that's the reason why you get the ap/pe burns in circular-to-circular optimization.)

But things get way more complicated once you introduce drag. Losses to drag are velocity-dependent. Which means you can't optimize transfer points. You have to optimize the entire trajectory. And that's what this thread has been about. So far, the most successful method has been projection method with collocation points on Pontryagin conditions, it seems, done using a library designed specifically to solve this sort of a problem. The downside is that such a trajectory has to be pre-computed.

What would be far more valuable is on-the-fly method. Unfortunately, it doesn't look like a precise solution can be done on-the-fly, but there are approximate methods which lead to a very sensible solution which would be very hard to beat. I've posted a bit of it earlier, for early ascent. I believe, I have a solution that will guide the rocket through the entire ascent at near-optimal fuel consumption. Should be far better than anything Mechjeb does, at least.

[hydropos]

Well, I figured out why my logic failed. You need to use circular coordinates (r, θ) instead of x and y. The radius of Kerbin is sufficiently small that the "x-velocity" you pick up at 20km is pointing in a distinctly different direction than the "x-velocity" you get at 40km. I've had a few too many beers tonight to be working the actual math out, but I am confident in this.

EDIT: I just started doing the math. It's hideous. Parametric equations everywhere...

EDIT2: For clarification, what I meant was that to accurately represent the effect of gravity, you need to consider the angle between the velocity vector and the radial position vector. You'll also need the angular velocity to determine the centrifugal offset to gravity. Both of these will require you set up relations for r and θ as a function of x and y.

Edited March 6, 2014 by hydropos

[hydropos]

Well, the flaw in my logic was facepalmingly obvious. If you need to gain both radial and angular velocity, you would not burn up then sideways (even if you had infinite TWR). If you burn at a 45° angle, you have to burn only 1.4 times the fuel as you would need in either direction, but you get both components of velocity. Not sure how to take this into account mathematically, as it essentially means ∆V efficiency isn't just dependent on velocity, but also rocket orientation.

[fibonatic]

I do not have access to good optimal control solvers (tried ACADO), but since I also would like to understand the algorithm behind the solver I thought I would come up with one of my own. I haven't had any courses about optimal control during my study, so everything I kown is self-taught.

Initially I came across the Hamilton Jacobi Bellman equation, which seemed applicable to this problem, however it did not bring me any closer to a solution, neither analytical nor numerical.

My next idea was to see if I could get an analytical expression from the integral, which calculates the total expelled delta-v, using this expression:

by using a polynomials for the velocities and then derive this expression for every coefficient to find for which values for the coefficients the integral would yield the lowest value. However no general equation for the integral seems to exist.

After this I gave up on the idea of finding an analytical solution and came up with a finite element like method. For the velocities I used a finite amount of control point (for now evenly distributed with hiehgt) and interpolated between them. And to find the optimal trajectory I applied Golden section search on the velocity of every point and repeated this until solution does not change much any more. There is a little bit more to it, such as the boundaries, since I assumed that the TWR is not restricted and therefore the rocket could undergo an instantaneous velocity change at launch and circularisation.

The optimal solution does gives a promising minimal amount of delta-v, namely roughly 4250 m/s, this is for a launch from 70 m (launchpad height) at the equator to a 75 km circular orbit. The velocities as a function of radius look as follows:

The thrust, in terms of acceleration, as a function of radius looks as follows:

The total acceleration clearly drops down after an altitude of 40 km, therefore I will also use this as a cut-off value for angle of the thrust in the following graph (since for low thrust levels the angle does not mean much). The following graph shows the angle of the thrust and the total velocity relative to the surface as a function of the radius:

It is interesting to note that there is a very notable sudden change in angle a little bit before 10 km. However what I can not explain is why initially the angle is negative (moving against the rotation of the planet).

I might try to implement this trajectory in KSP with kOS and test this in-game.

PS: I might also post similar graphs for other planets with atmospheres, such as Eve, such that we could also compare our solutions for other bodies.

[K^2]

These results have a lot of similarity to what I got using policy optimization in this thread. In particular with thrust curves, which I did not show in the thread. The method is somewhat similar, but I used polynomials for the velocity functions.

[indroth]

However what I can not explain is why initially the angle is negative (moving against the rotation of the planet).

I haven't really looked through the details of your equations, but my first thought is that maybe you don't take into account that drag is dependent on surface velocity not orbital velocity. This will result in non-zero drag at zero surface velocity.

Actually, how does that work in KSP? Is the atmosphere like a rigid shell so it is moving faster as you move higher up? Or is drag just proportional to the square of the surface velocity?

[K^2]

Actually, how does that work in KSP? Is the atmosphere like a rigid shell so it is moving faster as you move higher up? Or is drag just proportional to the square of the surface velocity?

Constant angular velocity. So yes, you would have gotten stronger effect at higher altitude, if it weren't for exponentially decreasing density.

[mhoram]

I do not have access to good optimal control solvers (tried ACADO)

Have you had a look at PSOPT? It is open source.

I managed to get some good results with this system.

The optimal solution does gives a promising minimal amount of delta-v, namely roughly 4250 m/s, this is for a launch from 70 m (launchpad height) at the equator to a 75 km circular orbit.

Nice Work!

It is interesting to note that there is a very notable sudden change in angle a little bit before 10 km

I would explain it this way. In order to reach orbit you need a lot of horizontal speed. Trying to achieve this below ~10km is inefficient because of the dense atmosphere.

I might try to implement this trajectory in KSP with kOS and test this in-game.

If you manage to do this, I would be very interested.

[fibonatic]

Have you had a look at PSOPT? It is open source.

I managed to get some good results with this system.

I do remember that abbreviation when looking at solvers, but I am not sure why I did not look into that one more. Maybe it was because I also wanted compatibility with Matlab, since that allows me to display and manipulate results very easily, however I think that PSOPT also can also be used with Matlab. Thanks, I will definitely look into PSOPT some more, but I am also glade that I came up with my own approach, since I also learned from it.

I would explain it this way. In order to reach orbit you need a lot of horizontal speed. Trying to achieve this below ~10km is inefficient because of the dense atmosphere.

I was more referring to that the "noob" launch path is vertical up to 10 km and then tilt 45°, so I thought it was worth mentioning that that altitude is some kind of tipping point.

If you manage to do this, I would be very interested.

I was trying to look for an easy way to import my trajectory into kOS. Instead of copying all my points I thought I should just use equations, which fir on the data. I also tried to think about how to control this in KSP. The main control parameters are your throttle and your pitch, so I tried to fit my total surface velocity and the angle of the velocity. Finding a good fit took a little bit of work, but I succeeded. After this I also wanted to check if the fit did damage the required amount of delta-v, but it turned out to be slightly lower, namely 4195 m/s.

Those fitted parameters might be able to be tweaked and maybe even reduce the delta-v even more, however I will leave that for now and I will first focus my attention on getting this to work in kOS.

[K^2]

The general features for total thrust are definitely the same.

I was worried about that double-hump, but it seems to persist in all of the optimization results. That's very interesting.

[mhoram]

The general features for total thrust are definitely the same.

I was worried about that double-hump, but it seems to persist in all of the optimization results. That's very interesting.

I can confirm that this "double-hump" double-hump is consistent with the results, I got. Have a look at the violet "thr" line.

[K^2]

Nice. Capped throttle. I'm still working on that. What was the lift-off TWR on this run?

[mhoram]

Click on the picture to get to the post with greater details.

At launch it had a TWR of 2.11.

[fibonatic]

I have a working kOS script and my first results tell me that my test ship used 4330 m/s of delta-v, which is 135 m/s more than predicted. One of the sources which will lead to higher delta-v consumption is infinite TWR at launch, which is assumed (the ship instantly reaches roughly terminal velocity). The ship I used had a TWR of 2.8 at launch. Another source might be that I did not worked out the derivative of the velocities to find the target acceleration, but used central finite difference (with h=0.5 meter and x is the radius). I also looked like the apoapsis during the ascent was getting to high, so I used another script to circularize. While coasting towards apoapsis while above the atmosphere it also becomes clear that KSP probably has insufficient "simulation" accuracy, since I see the apoapsis height the predicted by KER slowly drop while not in time-wrap (I would suspect that the physics engine of KSP uses Euler integration).

I did these tests on my laptop. When I get the change I will also do some tests on my desktop PC and probably also record a launch and post it here. If anyone want to mess with kOS, here is my script (It does not have any comments but I hope most of it will be clear).

[K^2]

Neat. I'll have to try this with my results. (They are inherently parametrized.)

[fibonatic]

I did a lot of testing, especially with the controller. My first try contained feedforward and only a P controller, however it turned out to be better to use less feedforward (I only calculated which acceleration would be needed to counteract gravity, drag and centripetal force) in combination with a PID controller. I also added some extra term to the radial velocity.

Here is a sample video of a rocket with constant Isp (always 390 s):

It used 4326.533 m/s of delta-v (KER says 4322 m/s, but I think that it uses g0=9.81m/s^2, while it should be 9.82 m/s^2)

I also played around with the thrust to weight ratio at the launchpad by further editing the config file of the engine and got the following fit from it:

For infinitely large TWR it seems to approach ~4303 m/s. I think that this figure might also be useful when designing rockets, such that you can find a balance between using a lot of engines such that you have a good TWR or less engines to save on mass.

This is an improvement from my first take (4350m/s) but still not my predicted 4200 m/s, but still not bad results.

EDIT:

I just found out that I used an incomplete model for my solver (I forgot the Coriolis effect in the tangential direction). After adding this to my model I got 4325 m/s, so my tests in KSP did slightly better, but reasonably close enough.

Edited August 31, 2014 by fibonatic

[fibonatic]

I tweaked my solver a bit, instead of searching between locked velocity bounds I now search between the initial value plus or minus a given value, which can be varied. This gives a result of 4297 m/s (it will get close to 4290 m/s if I set the termination criteria a lot tighter but it takes a lot longer). The resulting thrust and angle graphs look as followed:

In these results the gravity turn happens much more gradually.

I have not managed to find a good fit for these results which I could use in kOS (I initially tried a Fourier fit, however kOS seems to take a lot of time calculating 8 sin and cos terms resulting in a lot of delay in the control).

PS

I actually have not seen any results for other planets with atmospheres, so I thought I might as well be the first. For the launch height and target orbit I choose values which seemed realistic. For example when landing on Duna you want to use the atmosphere as much as possible and thus launch from a fairly low altitude, while for Eve landing is not the issue however picking your landing site can be hard so I used a value which was not to high and for Laythe I also used a low value since it will be very likely that you will land near a coast. For the orbital heights I just added a few kilometers above the atmospheric cut-off altitude.

[table=width: 600, class: grid]

[tr]

[td]Celestial body[/td]

[td]Launch height [m][/td]

[td]Target orbital [km][/td]

[td]Delta-v [m/s][/td]

[/tr]

[tr]

[td]Duna[/td]

[td]500[/td]

[td]45[/td]

[td]1275[/td]

[/tr]

[tr]

[td]Eve[/td]

[td]3000[/td]

[td]100[/td]

[td]9810[/td]

[/tr]

[tr]

[td]Laythe[/td]

[td]500[/td]

[td]60[/td]

[td]3200[/td]

[/tr]

[/table]

The graphs for these results can be found here.

Of course when designing rockets you would want to minimize the amount of mass used and thus is engine dependent, but these results might help as a guide when designing rockets, such as TWR and a rough estimate of how much delta-v would be required.

Edited September 11, 2014 by fibonatic
added results for other bodies

[mhoram]

Nice job on the other planets. Have not seen this done before.

About the approximation for KOS import:

Have you had a look at Lagrange polynomials with a Legendre Gauss Lobatto grid? That is the way PSOPT approximates the solution and is described in chapter 1.6 of its manual. I find the method very promising and should get rid of the trigonometric functions.

And thanks for the KOS script. I will have a look at it.

[fibonatic]

I have not looked at that, I will try to check that out. Another option might to to just interpolate, since currently I only use 136 elements between which I already interpolate. I might even switch to quadratic elements (instead of linear) in my solver, which might allow me to reduce the amount of elements even more. And using variable spacing of the elements might also help reducing the amount of elements.

PS: my kOS scripts basically has no comments. I intended to add them later (initially I just wanted to share it as soon as possible). However once I realized I made a mistake in my model, used to generate the launch path, I wanted to implement the new trajectory and have not got around to add comments.