Launch Efficiency Exercise [Updated for 0.21.1]

[tssn1611]

Tried it a couple times and got 7.74 L of liquid fuel left. My orbit could probably have been a bit lower, but I was having a hard time properly circularizing my orbit such that the periapsis was above 75 km. Anyway, I guess this would put me in 9th place currently? Oh, and this was completely stock.

Munfrod knows something's up. They forgot to pack parachutes ... this won't end well for him.

Edited July 11, 2013 by tssn1611
Clarification on lack of MechJeb

[Tarmenius]

Congratulations on your great first entry! If you're able to get your Pe and Ap exact enough, you can bring them down to 74km (but no lower than that). That will likely improve your score noticeably... not that it isn't awesome already, of course!

I hope Munfrod brought something to read and eat while a rescue can be mounted... if a rescue is even planned, that is

[g00bd0g]

A couple hours of screwing around and I managed 8.13, over-burned a smidge on the correction. Auto enabled with Terminal Velocity and 22.5m/sec limits until coast-to-orbit, then allow full power for final burn (makes for a more accurate orbit).

[Bystander]

I've been attempting my own sub-challenge for this one. The most efficient completely automated Mechjeb launch.

Basically I tweak some settings, hit launch, tab away and get on with some work then come back in 6 mins.

Unfortunately (because I didn't come up with it), Tavert's first attempt from pg 4 is the best I've had. It reliably produces either 10.4 or 10.3 over many runs.

Lim Acc 22 m/s2, Ascent Path 8,48,0,55, no Corrective Steering.

On the upside it beats the 10.0 he got with the numbers - most likely because Tavert went full throttle for the circularize. There may be room for improvement as I haven't tweaked in the vicinity of Tavert's numbers yet - assume he did that though.

As an aside other things I tried were,

* Looking up during the launch - no difference.

* Waiting for a Muna/Kerbin alignment at the Zenith - took time and made no difference, thought maybe some tidal effect might give me a couple of points.

* Takeoff inclination, not surprisingly the standard 0 degrees is optimal - 90 and 270 get you to the Ap but not enough fuel to circularize, 180 won't even get you to Ap. At take-off the navball shows zero Surface Speed but of course you are already orbiting at 174.6 m/s.

[mootavic]

Well this is the best i can get tonight/this morning. 9.56L left. Flight profile as follows.

Mechjeb - Autopilot/Throttle control [Terminal Velocity/Acceleration limiting]

Gravity turn starts 8.5km - ends 50km

Turn shape 39.9%

Acceleration limited to 25m/s² from 0 to 42km

Acceleration limited to 18m/s² from 42 to 59km

Acceleration limited to 10m/s² from 59 till atmosphere end

Full power burn to circularise @ 74.1km

managed to get near on identical numbers 3 times in a row [all within about .01L] with this being the most fuel remaining.

Might give it another crack soon but for now a few hours is enough trying lol.

Edited July 11, 2013 by mootavic

[Tarmenius]

...thought maybe some tidal effect might give me a couple of points.

Unfortunately, KSP doesn't model gravitational influence from multiple bodies. But kudos for the idea! And Congratulations on making the Double-Digit Club! A prestigious group of pilots, to be sure.

Might give it another crack soon but for now a few hours is enough trying lol.

I don't blame you one bit. Spending a couple hours getting something just right can be draining. But you made a great first entry, so Congratulations to you as well. And the same goes for you, g00bd0g. Well done!

[Tarmenius]

As this Challenge has begun to slow down, I'd like to compile these results into some visual representation of the average ascent path. Ideally, I'd like to create a graph with Pitch Degrees on one axis and Altitude on another. Would those of you willing to help be able to provide the details of your ascent, with degrees of pitch for every 5 or 10 km after the start of your gravity turn? Also, I've never made a graph like this before, so if someone has any suggestions on what software I could use, that would be greatly appreciated as well.

Again, I want to thank and congratulate everyone who took part in this. I was consistently impressed with every new entry. You guys are awesome!

[Raptor831]

As this Challenge has begun to slow down, I'd like to compile these results into some visual representation of the average ascent path. Ideally, I'd like to create a graph with Pitch Degrees on one axis and Altitude on another. Would those of you willing to help be able to provide the details of your ascent, with degrees of pitch for every 5 or 10 km after the start of your gravity turn? Also, I've never made a graph like this before, so if someone has any suggestions on what software I could use, that would be greatly appreciated as well.

Again, I want to thank and congratulate everyone who took part in this. I was consistently impressed with every new entry. You guys are awesome!

My path was in a previous post, so hopefully you can use that!

I'd just have a plot, y-axis for altitude (0 km at the origin and 75 km at the top) and x-axis for pitch (start at 90 deg and go to 0 deg). It'll also look a bit like the arc, so it'd be intuitive visually. It'd also be nice to compare when people start their gravity turns, how flat or curved the turn is, and when they just push for velocity.

[Tarmenius]

I'd already planned on using the info from that post of yours, it's very helpful. And I can probably glean more data from the videos in the thread.

[mootavic]

was the info i provided sufficient? i mentioned all the things i did manually and mechjeb pretty much did the rest...

[Tarmenius]

Oh, it was sufficient for the challenge, don't worry. The data I want to gather will be plotted on a graph to give a more visual representation of the different ascent paths flown by everyone. I already know they will be pretty similar, but with the bulk of the entries being very close, I'm curious to know how much deviation will still produce such similar results. Basically, I want to plot out the "zone" of ascent profiles that will achieve the most efficiency (for this rocket).

[Raptor831]

Any luck on the visual aid?

Oh, and *BUMP*

[Tarmenius]

Heh, I kinda got distracted with the start of Summer Quarter classes. I should have some free time later this evening or on Thursday to compile the results, though. And now that I figured out how to convert an Excel spreadsheet into a graph, it shouldn't be much work at all.

[Raptor831]

Heh, I kinda got distracted with the start of Summer Quarter classes. I should have some free time later this evening or on Thursday to compile the results, though. And now that I figured out how to convert an Excel spreadsheet into a graph, it shouldn't be much work at all.

Sweet! And RL comes first, no worries. I'm just really curious as to what the graph turns out to be!

[numerobis]

I've coded up in python a little script that tries the following simple strategy: at each timestep, burn in the direction that, after gravity and drag, maximizes acceleration in the direction we're facing. Also, drag loss must be less than gravity loss. And a hack: at the start, burn vertically for a kilometer, because otherwise the previous strategy makes you go sideways for a couple seconds.

This makes it follow ascent paths similar to what we're used to, and reach total burn costs like we're used to. In a simulation in python, mind, so I'm not going to give you precise numbers, since I don't fully trust them. In particular, I'm testing with craft that don't burn fuel or stage; also, the craft are assumed to be able to flip from sideways to vertical every few timesteps if the algorithm feels like it.

What I notice from this strategy is that the path it takes is basically:

1. vertical at max thrust until terminal velocity

2. cut throttle to stay at terminal velocity, and track it

3. when you get back up to max throttle, begin a gravity turn

So a TWR 2.5 craft starts to turn at just shy of 10km; a TWR 5.0 craft turns at 17.5km; a TWR 2.0 craft turns right away, since it can never quite reach terminal velocity (remember: these simulations aren't simulating fuel burn, so the TWR is constant throughout flight).

Next step: put this logic into MechJeb and try some flights in KSP!

[numerobis]

A more mathematical description:

  maximize (T + drag + gravity).T
  subject to dragloss < gravloss
  where      gravloss = length(T) - (T + gravity).T
             dragloss = length(T) - (T + drag).T

T is the thrust, a 2-vector, a force quantity (kN or N or lb-f or whatever).

drag and gravity are also 2-vectors, same units.

Loss is that we assume we didn't have the effect, and see how much force we'd be achieving. Then we add the effect in and see how much less force we have achieved in the direction of thrust.

So this is a nice simple quadratically-constrained quadratic optimization problem. It's clearly convex, and now that I wrote it this way, I'm starting to think there's simplifications possible (looks like the quadratic terms in the constraint cancel out? they didn't in an earlier formulation). The way I'm solving it in python is choosing a couple thousand solutions randomly and picking the best one.

[tavert]

Are you treating drag and gravity as parameters here? Maximizing a convex function over a convex region (just a half-space in what you wrote after cancelling the quadratic constraint terms, but it appears you've left out a few constraints like maximum thrust magnitude) is a non-convex problem - it's essentially as hard as vertex enumeration.

What you've written is sort of a multiparametric quadratic program, but not one of the nice ones with a piecewise-affine explicit solution, since you're maximizing a convex objective and the parameters enter the slopes of the cost and constraints. For a small-enough problem you could fairly easily enumerate the active sets of constraints.

I had something much more complicated in mind, where you would actually consider the state dynamics discretized over a horizon, and you'd have a large optimization over the pitch and thrust inputs at every time step. Drag, altitude-varying gravity, and changing mass are part of the dynamics, and orbital velocity and altitude are the terminal constraint. Maximize final mass subject to dynamics and thrust magnitude constraints, and maybe pitch rate if the solutions are too unrealistic without it.

Edited July 18, 2013 by tavert

[numerobis]

I was working on a memoryless framework because I don't know how to do better; I'd love to see a more ideal solution! This method has the advantage of being adaptive to your spacecraft falling apart in flight, or other nominal situations.

Thinking more, the constraint is obviously a half-plane. Then as you point out I forgot to mention the thrust limit and that I force thrust to be in the positive quadrant (otherwise the solution is to burn straight down on launch, which is suboptimal).

Overall, the solution space is a quarter-disc cut by a chord.

In more prosaic terms, the optimization criterion says you should burn as hard as possible, perpendicular to the sum of the lossy forces (drag and gravity). Seems reasonable.

[Nao]

Lol 10.44 at first try, using MJ with a profile i created some time ago.

Unfortunately following attempts to get better results failed

There seems to be some more science going on in this thread that i'll try to catch on later

edit: A simple 1m/s change on a acceleration limit and we got 10.55, with some real time tinkering to MJ values. the Dv expended is 4333m/s I don't think i can do better thou as even slight changes to the way it is flown produce big fuel losses.

Just for comparisons i tried flying the challenge by hand without any assists and got 10.23 ... not bad

Edited July 19, 2013 by Nao

[Tarmenius]

And we have a new leader! Congratulations, Nao, very well done!

Edited July 19, 2013 by Tarmenius

[Raptor831]

A simple 1m/s change on a acceleration limit and we got 10.55, with some real time tinkering to MJ values. the Dv expended is 4333m/s I don't think i can do better thou as even slight changes to the way it is flown produce big fuel losses.

Sweet! Congrats! I think around 4330 m/s was the best I've ever seen in my launches (which funny enough came on a Mun landing mission, I think), so I'd agree that this is about as good as it gets! Unless, of course, you drop the Ap and the Pe down a to just above 70 km.

If you don't mind posting, what were the parameters you used? I, for one, would love to see that!

[Nao]

I used the first of the best ones i have found doing research in this thread. (8-37 one)

The first flight that i tied with you was done using 23m/s limit acceleration by accident, then i remedied it in the edit flight (10.55).

Also honestly i don't think we can go much lower than 4333 with lower orbit as below 74km you either spend much more time in the atmosphere or have very high profile that wastes the Oberth effect.

The part where most improvement can be made would be launch with more TWR but that requires another craft.

edit: welp with the craft as it is a 70km orbit gives 11.02 fuel with the same profile, so the drag effect isn't as bad as i thought. Although flying other crafts that had LV-N at the last stage (underpowered) the ~73km orbit required less fuel than lower orbits.

Edited July 20, 2013 by Nao

[Raptor831]

I used the first of the best ones i have found doing research in this thread. (8-37 one)

The first flight that i tied with you was done using 23m/s limit acceleration by accident, then i remedied it in the edit flight (10.55).

Also honestly i don't think we can go much lower than 4333 with lower orbit as below 74km you either spend much more time in the atmosphere or have very high profile that wastes the Oberth effect.

The part where most improvement can be made would be launch with more TWR but that requires another craft.

edit: welp with the craft as it is a 70km orbit gives 11.02 fuel with the same profile, so the drag effect isn't as bad as i thought. Although flying other crafts that had LV-N at the last stage (underpowered) the ~73km orbit required less fuel than lower orbits.

I think as long as you're heading upward at at least 100 m/s after 50 or 60 km, the drag doesn't kill you. According to MechJeb, you take most of your drag losses before 10,000 m, I think. I'd have to test that to be sure, but hey, guesstimation is Kerbal.

I've had orbit insertion stages that had a TWR of .6 and still made it. I like my launch stages to have around 2.3 TWR, so I can hit terminal velocity fast. After you hit 1500 m/s velocity, you're really only adding to your horizontal velocity, so TWR doesn't matter as much.

I'll have to try knocking down my max accel to 22 m/s^2 and see if that helps eek out a few more fuel points. The last one I did was a one off, so I could probably squeak out a bit more.

[Tarmenius]

... after 50 or 60 km, the drag doesn't kill you.

I've noticed that above 35km, drag is weak enough that extended solar panels won't be ripped apart... unless perhaps at very high speeds. I'm not sure exactly what terminal velocity is up there, but I have to imagine it's pretty fast.

[numerobis]

An update: using Nao's launch profile but not touching it during flight, I get 10.45 units of fuel, aka 131 m/s remaining deltaV.

Then I changed the meaning of the "limit to terminal velocity" to be the constraint I posted above: the drag loss should be less than the gravity loss. And I turned off the acceleration limit.

Using that, the same launch profile gets 84 m/s remaining deltaV. The best I get with a half-dozen tries is a start at 8 km, end at 35km, shape 66.6%, and 0 degrees final. That gets me 101 m/s. So I'm in the ballpark.

Two suboptimal pieces:

1. The terminal velocity limit flies a bit faster than intended. We're only talking about 1% faster, but over the course of the entire ascent that could add up to be significant given how tightly we're optimizing. I know this is wrong for the vertical portion; not clear on the diagonal and horizontal portions of flight.

2. I didn't code up the vectoring part; I'm still using the normal flight path code, just patching in the new limit code. (I say this is suboptimal, but that's not proven at all!)