How do you get to orbit without going by trial-and-error?

[Hyperlynx]

I've been playing KSP for a while now, on and off (Steam says >350 hours). But yet, getting into orbit is still trial-and-error for me.

I use Kerbal OS. For each spacecraft I design, I write a script to launch it. The script is roughly the same each time:
 

1. Lock throttle to <target TWR>
2. When at <gravity turn speed>, pitch to <angle> degrees from vertical.
3. Wait 10 seconds.
4. Unlock steering.
5. Wait until apoapsis has reached <target apoapsis>.
6. Cut throttle.
7. Wait until <seconds before apoapsis>
8. Throttle to 100%
9. Wait until periapsis has reached <target periapsis>

What changes is the values of those variables (in <angle brackets>). The thing is, changing those variables is completely trial-and-error.

I can tell from experience how each one is going to affect my orbit. If I'm at a higher speed before I start my gravity turn then the pitch-over is going to be slower and higher, and I'll have to burn longer to circularise, but if it's too low then I'll pitch over too fast and won't reach space. Similar story with TWR - too low and I don't go to space, too high and I waste fuel due to air pressure. But finding the *right* numbers to use seems to be just keep trying and trying and trying until eventually I get into a nice, relatively circular orbit.

Surely there must be a better way to do this than trial-and-error hardcoded values. How can I work this stuff out beforehand? Or is there another algorithm I should use instead?

Edited August 16, 2019 by Hyperlynx

[VoidSquid]

Never used KOS myself, just doing some scripting as part of my job, but would'd be a kind of feedback-and-correction loop every few seconds be a good idea? Right now you're only giving a steering command once, for me, I'd expect that this particular value only works for this particular rocket.

You probably have a particular ascend trajectory in mind, which gives you several data points on the graph with altitude, speed, pitch. In such a feedback loop, you could check the current altitude and then compare it with the respective data tupel and if required make steering corrections.

Edited August 16, 2019 by VoidSquid

[dire]

So, if you really want to math up some math you can tinker with derivatives and circles, or crib this guy's notes: https://www.aerospades.com/uploads/3/7/3/2/37325123/apollo_moon.pdf

For myself, having launched many rockets by hand, I try to keep TWR between 1.5 and 2.

Grav turn speed is about 100 m/s, turn angle is 5 degrees off vertical.

Then I lock prograde (at the step where you say "Unlock steering"). I wait until pitch angle is 45 degrees and lock pitch to current angle.

When Apoapse time is at least 30 seconds and current altitude is at least 30 km I lock prograde (space) until 30 degrees.

If time to apoapse is greater than 90 seconds, cut throttle until apoapse time stops increasing and lock prograde. 

Wait until apoapse altitude is target altitude but at least 75 km, then lock prograde, cut throttle and prepare to circularize.

Depending on upper stage TWR, how you circularize is going to vary a lot. With a low TWR, you pretty much have to just keep burning and might even pass apo before you circularize, which can mess up all kinds of logic. With a higher TWR of at least 1, you can afford to get a prettier, lower orbit by waiting until closer to apo. In general you want your current speed plus (acceleration * time remaining to apo) to be greater than orbital velocity, otherwise you risk passing apo and falling to your doom.

This method will consistently get a final orbit that is just a little higher than your target and at least 75km, but if you are docking and a perfect orbit is important you can fix it after you stop falling out of the sky.

Edited August 16, 2019 by dire

[Hyperlynx]

38 minutes ago, VoidSquid said:

Never used KOS myself, just doing some scripting as part of my job, but would'd be a kind of feedback-and-correction loop every few seconds be a good idea? Right now you're only giving a steering command once, for me, I'd expect that this particular value only works for this particular rocket.

You probably have a particular ascend trajectory in mind, which gives you several data points on the graph with altitude, speed, pitch. In such a feedback loop, you could check the current altitude and then compare it with the respective data tupel and if required make steering corrections.

I've thought of maybe doing that. The tricky part would be how often to sample. Maybe I could do a bunch of flights to gather data on what a good trajectory looks like and then hope it fits into a mathematical curve that I can easily work out?...

 

 

23 minutes ago, dire said:

So, if you really want to math up some math you can tinker with derivatives and circles, or crib this guy's notes: https://www.aerospades.com/uploads/3/7/3/2/37325123/apollo_moon.pdf

For myself, having launched many rockets by hand, I try to keep TWR between 1.5 and 2.

Grav turn speed is about 100 m/s, turn angle is 5 degrees off vertical.

Then I lock prograde (at the step where you say "Unlock steering"). I wait until pitch angle is 45 degrees and lock pitch to current angle.

When Apoapse time is at least 30 seconds and current altitude is at least 30 km I lock prograde (space) until 30 degrees.

If time to apoapse is greater than 90 seconds, cut throttle until apoapse time stops increasing and lock prograde. 

Wait until apoapse altitude is target altitude but at least 75 km, then lock prograde, cut throttle and prepare to circularize.

Depending on upper stage TWR, how you circularize is going to vary a lot. With a low TWR, you pretty much have to just keep burning and might even pass apo before you circularize, which can mess up all kinds of logic. With a higher TWR of at least 1, you can afford to get a prettier, lower orbit by waiting until closer to apo. In general you want your current speed plus (acceleration * time remaining to apo) to be greater than orbital velocity, otherwise you risk passing apo and falling to your doom.

This method will consistently get a final orbit that is just a little higher than your target and at least 75km, but if you are docking and a perfect orbit is important you can fix it after you stop falling out of the sky.

I'll give that pdf a read. Thanks!

My TWR ranges between 1.3 and 1.5, grav turn speed between 80 and 100, turn angle 1 to 10, time before ap burn 30 to 15. Getting the right number within those ranges is what's annoying, particularly because I'm trying to get as close to optimal (circular) as I can/have the patience for, to save on the cost of the rocket.

But I should try the lock to 45 degrees thing, it's probably going to be more consistent.
 

Quote

In general you want your current speed plus (acceleration * time remaining to apo) to be greater than orbital velocity

That's a good point! I could use that to work out the proper burn duration!

[dire]

If you use the current speed + (accel  * time remaining) bear in mind that it's just a conservative estimate, and again the "true" number has more math in it. Because when you accelerate, you increase your time remaining. But it will generally keep you from falling out of the sky, and again depending on your particular launch the amount by which duration increases when you accelerate will be different depending on factors like angle of burn, how close you already are to apo, how circular your orbit already is and so on.

[VoidSquid]

10 minutes ago, Hyperlynx said:

gather data on what a good trajectory looks like

No need to reinvent the wheel again, why not check out MechJeb's ascend trajectories?  They already did put a lot of work into it, I'm pretty sure their ascend trajectories are much optimized.

[Zhetaan]

3 hours ago, Hyperlynx said:

What changes is the values of those variables (in <angle brackets>).

Don't forget that the spacecraft itself is a variable.  Unless you fly essentially the same design to orbit again and again, expect that the correct values for one rocket will not work for another.

That being said, I tend to build rockets that are variations on a consistent theme, and I usually tie my launch scripts to the altitudes rather than the apoapsis--but I just about always launch to an 80 km parking orbit before I do anything else.  If you're changing your target apoapsis, then that modifies the shape of the launch--but on the other hand, it shouldn't change the shape too much considering that your flight path is a (hopefully smooth) transition from a radial starting orbit to a circular final orbit.  On the gripping hand, that shape is going to change the most in the atmosphere, where drag is going to fight whatever you do.  It may be ultimately cheaper to launch directly to the target apoapsis, but traditionally, cost is in third place among rocket designers' design priority philosophy.

Your thought on sampling data is a good one.  I don't know what you're trying to optimise, though.  Is it fuel consumption?  Flight time?  Ratio of crashes to successful launches?

@VoidSquid:

MechJeb includes a preset trajectory shape that works most, but not all, of the time.  Since MechJeb doesn't know what you're launching, it has to use a one-size-fits-all approach and essentially tries to force the rocket to fit the ascent path, so it's not optimised at all--the mod for that is GravityTurn Continued.  There's a discussion of the difference between GravityTurn and MechJeb in the first few posts of the GravityTurn thread, if you're interested.  It's not technical, but it is correct.  In essence, good gravity turns do look a lot alike because however the rockets fly, they all need to ascend out of the same atmosphere and in the same gravity field.  But the subtle differences still count for a lot of efficiency.

@dire:

The pdf was a good read; thanks for sharing!  Since it covers the Apollo lunar module ascent from the Moon and not the Saturn V ascent from Earth, I don't think it will completely solve the launch problem, but it does show some interesting ways to look at it.  There are definitely some good ideas there.

Edited August 16, 2019 by Zhetaan

[VoidSquid]

Hey @Zhetaan,

I did read some time ago about that mod. No doubt, its iterative approach will, in the end, lead to better optimized trajectories than MJ's approach. The question (at least for me) though is, what solution is more practical for my play style. A huge factor here is time, time required for multiple launches and time for reverting (the  latter, like all scene changes takes a lot of time for my current game, game year 29, with hundreds of deployed vessels). My question for me then: what do I gain (optimized trajectory) at what costs - is it worth it or not?

For this reason, I prefer the MJ's solution, make the rocket follow a predetermined path. With this approach, I've learned to build my rockets in a way that they automatically and naturally follow MJ's ascend path, there is - save for the initial pitching - almost never any correctional steering during ascend required.Nowadays I don't even have to think much about it anymore, it's just became the natural way I build the ascend stages.

[Zhetaan]

Just now, VoidSquid said:

The question (at least for me) though is, what solution is more practical for my play style. [...] My question for me then: what do I gain (optimized trajectory) at what costs - is it worth it or not?

Exactly!  I certainly am not suggesting that your approach is the wrong one.  In fact, I follow the same philosophy overall--I don't want to spend my time making tiny changes just so I can reach orbit when there's so much more to do and see.  As the saying goes, once you can reach orbit, you're halfway to anywhere--well, I want to explore that second half.  Since my rockets all have nearly the same design, I only need to know one optimal trajectory.

Honestly, it appears that we have arrived at the same solution, but came to that solution from opposite ends of the problem.  You took the precalculated trajectory and designed your rockets to fit, and I designed the rocket and adjusted the trajectory to fit.  Either way, we get where we want to go, so that looks like success to me.

[VoidSquid]

Yepp  

The reason for my approach: when I started going to orbit and further, I totally had almost zero know-how and experience how to properly build a rocket at all. And I thought to myself, those guys developing MJ, they know what they do, have the experience, and are way more into the game mechanics and required math than I am. So: I'll follow their approach. And so far, no regrets

Like yours, almost all my rockets today follow the same basic design: initial stage (mostly just SRBs, with exception of the really heavy rockets) to 12k altitude, start TWR 1.3-1.4. Next stage close to circularization, the burned out stage does not reach orbit but falls down and self destroys. Final circularization does not take much dV and is done by the third stage with a vacuum engine.

As I said, why invent the wheel again...  

Edited August 16, 2019 by VoidSquid

[Snark]

5 hours ago, Hyperlynx said:

Surely there must be a better way to do this than trial-and-error hardcoded values. How can I work this stuff out beforehand? Or is there another algorithm I should use instead?

As folks have observed, a lot depends on your preferred play style and design types.  There are many different "right" (i.e. efficient, effective) ways to get to orbit.  Unfortunately, there are many times that number of wrong ones. 

So here's what I do in my own gameplay-- not saying that this is any more "right" than any other means, just that it works well for me and is totally consistent with minimal guesswork.

5 hours ago, Hyperlynx said:

1. Lock throttle to <target TWR>

I never do this, myself.  If engines are ever running at under 100%, that means wasted efficiency.  If I don't need the full power of my engines, it means I'm carrying too much engine and am wasting dV due to hauling too much engine mass as dead weight.

And as long as your launchpad TWR is no higher than 2 and you're reasonably streamlined, it's always most efficient to go at max throttle, because gravity losses far outweigh aero losses.

The only time I ever launch at under 100% is if I have the rare occasional "freak" vessel that's ludicrously un-streamlined due to needing to lift a really awkward payload, or something.

However, since you were mainly asking about repeatability rather than efficiency per se, I'll say this:  I've found that it really, really helps to have a rigidly consistent launchpad TWR.  Rationale:  As long as all of my spacecraft have the exact same TWR on the launchpad, that means that my initial pitch-angle for the gravity turn will be the same.  So holding the TWR constant means that I take the guesswork out of the pitch angle.

Myself, I like a launchpad TWR of 2.  No particular reason, that's just how I like to fly.  That's about the highest that's practical; anywhere from 1.3 to 2.0 can work (though that would entail a different design strategy, and the lower your TWR the less initial pitch angle you'd want).

Yes, the TWR will change as the rocket ascends (i.e. it climbs during each stage, then drops when I move to the next stage), but I've found that in practice that matters very little.  I just design my rockets so that they have a consistent launchpad TWR, launch at 100% throttle, and stay at 100% during the entire boost phase until Ap gets where I want it.

5 hours ago, Hyperlynx said:

2. When at <gravity turn speed>, pitch to <angle> degrees from vertical.
3. Wait 10 seconds.
4. Unlock steering.

I don't do any of this.  There's no wait, there's no unlocking of steering, and there's no "gravity turn speed" as a variable.

And "angle" isn't a variable either, because I always pitch by the same angle because I always launch at the same TWR.

What I do is this:

1. Launch
2. Immediately pitch east.  I mean, the instant it lifts off the pad.  The angle is fairly small, and depends on the TWR.  It takes a little bit of trial and error to find the right angle initially... but if you always launch with the same TWR, then once you find the right angle, you just use it all the time.
3. Also immediately, set SAS to hold .

That's it.  That's all there is.  No steering, that's why it's called a "gravity turn", because gravity is doing the steering for me.  I just hands-off the controls except for staging.

5 hours ago, Hyperlynx said:

5. Wait until apoapsis has reached <target apoapsis>.
6. Cut throttle.

Yup.  Exactly what I do too, no differences there.

5 hours ago, Hyperlynx said:

7. Wait until <seconds before apoapsis>
8. Throttle to 100%
9. Wait until periapsis has reached <target periapsis>

Well, I don't do that, mainly because I don't use kOS or any autopilot mods.  What I do is just wait until the craft leaves atmosphere, then go to map mode and drop a maneuver node right at my Ap point, with enough dV to circularize.  Then the burn timer on the navball takes the guesswork out of when to burn.

If you're using an automated tool that needs to run on a script, I understand that that might not work well for you.  However, I think you can take the guesswork out of step 7.  If the script knows the apoapsis, and knows the current and desired periapsis, then it's a fairly simple bit of math to calculate the amount of dV you'll need.  A bit more simple math (based on your TWR) will tell you how many burn seconds you need.  Start the burn half of that time before Ap, and there you go.

So, to summarize:  You mention the following variables in your OP:

1. Target Ap and Pe
2. Target TWR
3. Pitch angle
4. Gravity turn speed
5. Seconds before apoapsis

#1 will obviously be different on every launch, since that's your target orbit and will depend on the mission.  But the above technique eliminates basically all the other variables.  TWR goes away, because it's always the same, and throttle is always at 100%.  Ditto pitch angle.  "Gravity turn speed" simply isn't a thing, and "seconds before apoapsis" is a trivial bit of math based on Ap, initial and desired Pe, and TWR.

Does that help?

[VoidSquid]

No, everyone else but me is doing it wrong, my way is the only correct way!   

Now, wouldn't that be boring? Hell, yes! For me, and this is one of the best aspects of KSP, everyone finds her/his own style, there is no "wrong" or "right", in the end, the result is what counts, and even more important, that we all enjoy our time while toying around with KSP  

So, as a final "advice", I strongly suggest you find the right way for your play style, Hyperlynx, no need to copycat what other people do, take the posts here as suggestions, nothing more, nothing less.  

 

[dire]

2 hours ago, Snark said:

As folks have observed, a lot depends on your preferred play style and design types.  There are many different "right" (i.e. efficient, effective) ways to get to orbit.  Unfortunately, there are many times that number of wrong ones. 

So here's what I do in my own gameplay-- not saying that this is any more "right" than any other means, just that it works well for me and is totally consistent with minimal guesswork.

I never do this, myself.  If engines are ever running at under 100%, that means wasted efficiency.  If I don't need the full power of my engines, it means I'm carrying too much engine and am wasting dV due to hauling too much engine mass as dead weight.

And as long as your launchpad TWR is no higher than 2 and you're reasonably streamlined, it's always most efficient to go at max throttle, because gravity losses far outweigh aero losses.

The only time I ever launch at under 100% is if I have the rare occasional "freak" vessel that's ludicrously un-streamlined due to needing to lift a really awkward payload, or something.

However, since you were mainly asking about repeatability rather than efficiency per se, I'll say this:  I've found that it really, really helps to have a rigidly consistent launchpad TWR.  Rationale:  As long as all of my spacecraft have the exact same TWR on the launchpad, that means that my initial pitch-angle for the gravity turn will be the same.  So holding the TWR constant means that I take the guesswork out of the pitch angle.

Myself, I like a launchpad TWR of 2.  No particular reason, that's just how I like to fly.  That's about the highest that's practical; anywhere from 1.3 to 2.0 can work (though that would entail a different design strategy, and the lower your TWR the less initial pitch angle you'd want).

Yes, the TWR will change as the rocket ascends (i.e. it climbs during each stage, then drops when I move to the next stage), but I've found that in practice that matters very little.  I just design my rockets so that they have a consistent launchpad TWR, launch at 100% throttle, and stay at 100% during the entire boost phase until Ap gets where I want it.

I don't do any of this.  There's no wait, there's no unlocking of steering, and there's no "gravity turn speed" as a variable.

And "angle" isn't a variable either, because I always pitch by the same angle because I always launch at the same TWR.

What I do is this:

1. Launch
2. Immediately pitch east.  I mean, the instant it lifts off the pad.  The angle is fairly small, and depends on the TWR.  It takes a little bit of trial and error to find the right angle initially... but if you always launch with the same TWR, then once you find the right angle, you just use it all the time.
3. Also immediately, set SAS to hold .

That's it.  That's all there is.  No steering, that's why it's called a "gravity turn", because gravity is doing the steering for me.  I just hands-off the controls except for staging.

Yup.  Exactly what I do too, no differences there.

Well, I don't do that, mainly because I don't use kOS or any autopilot mods.  What I do is just wait until the craft leaves atmosphere, then go to map mode and drop a maneuver node right at my Ap point, with enough dV to circularize.  Then the burn timer on the navball takes the guesswork out of when to burn.

If you're using an automated tool that needs to run on a script, I understand that that might not work well for you.  However, I think you can take the guesswork out of step 7.  If the script knows the apoapsis, and knows the current and desired periapsis, then it's a fairly simple bit of math to calculate the amount of dV you'll need.  A bit more simple math (based on your TWR) will tell you how many burn seconds you need.  Start the burn half of that time before Ap, and there you go.

So, to summarize:  You mention the following variables in your OP:

1. Target Ap and Pe
2. Target TWR
3. Pitch angle
4. Gravity turn speed
5. Seconds before apoapsis

#1 will obviously be different on every launch, since that's your target orbit and will depend on the mission.  But the above technique eliminates basically all the other variables.  TWR goes away, because it's always the same, and throttle is always at 100%.  Ditto pitch angle.  "Gravity turn speed" simply isn't a thing, and "seconds before apoapsis" is a trivial bit of math based on Ap, initial and desired Pe, and TWR.

Does that help?

What I've found is that even if you're using an identical launch vehicle to launch identical payload masses into identical orbits, you still have some differences in launch profile based on the size of the fairing, how many draggy bits are sticking out,  and how tall the payload mass is (which moves COM around).

The danger with immediately pitching east is that on a tall, draggy payload, you can flex, spin and crash. Also, even for identical payload masses, the "right" angle to pitch is different depending on drag; it's easy to use muscle memory and reflex to "find" the right spot with a little practice, but it's much harder to specify what that spot is.

I've got a half-dozen craft files using identical launch vehicles I can toss up if you're interested in experimenting (At least, I think I still have them. I should). My last couple of standardized payloads have been leaning towards not just identical mass but also a more-or-less identical profile as well -- much stubbier and shorter, with fewer bits sticking out of the fairing and a single large "backbone" piece that can minimize flexure.

Edited August 16, 2019 by dire

[Snark]

23 minutes ago, dire said:

What I've found is that even if you're using an identical launch vehicle to launch identical payload masses into identical orbits, you still have some differences in launch profile based on the size of the fairing, how many draggy bits are sticking out

Well, certainly one's design philosophy will enter into it.  For me, neither the size of the fairing nor draggy-bits-sticking-out is an issue.  The fairing's not an issue because if I need a very different fairing size, I don't use the same size launch vehicle.  I size the diameter of the launch vehicle to be an approximate match for the fairing.  If I'm launching something that needs a fairing 3 meters wide, I'll use a 2.5m stack for that, not a 1.25m stack.  So my fairings are always a fairly consistent size and shape relative to the launch vehicle, and it's just not an issue.  I launch exactly the same way all the time, and it always works.

Likewise, "draggy bits sticking out" isn't a thing because I make a point of designing vehicles that are very streamlined.  They simply don't have significant "draggy bits".  If I have draggy bits, I put those in a fairing.

(Of course, there's the occasional oddball vehicle that has a really awkward payload that there's no good way to make aerodynamic-- e.g. big miner/refiners.  But those are the rare exception, for me.)

27 minutes ago, dire said:

how tall the payload mass is (which moves COM around)

How is that relevant?  I mean, sure, if the COM is so low that the vehicle is actually aerodynamically unstable, then the rocket's gonna flip.  Which is why one designs rockets not to do that.

But as long as the CoM is high enough that the rocket is stable-- which is a basic design requirement-- then the actual position of the CoM is irrelevant, at least for a ballistic vehicle that simply follows all the way to orbit.  (It would matter if one were building a spaceplane, but that's not what we're talking about here.)  CoM position's not going to affect the trajectory, because that's purely a function of speed, gravity, and acceleration, not mass distribution.

43 minutes ago, dire said:

The danger with immediately pitching east is that on a tall, draggy payload, you can flex, spin and crash.

Must be a difference of design technique, then?  That never happens to my vehicles, ever.

• I don't make them excessively tall, relative to their width, so the rockets are always stiff.
• I don't make excessively draggy payloads, at least not for 90%+ of my launches.  If I've got something that's draggy, I put it in a fairing, and the fairing is a pointy-nosed cylinder that's no more than slightly wider than the rocket body.
• When I do need to get fairly tall, I use construction techniques designed to help with stiffness, especially in the early stages of launch where stresses (both thrust and aero) are large.
• And of course it's important not to over-provision pitch and yaw authority.  I almost always reduce the gimbal authority on the engines to something like 30-40%, and do the same with control authority on steerable fins, if the rocket happens to have those.  The taller the rocket, the less gimbal it should have.  Having too much pitch/yaw authority isn't necessary (because there's practically no "steering" to do, it's just following all the way and is mainly using aerodynamic stability to maintain that), and it can be actively harmful (because SAS can over-correct and end up making the rocket flex too much).
• Also, by pitching immediately and then simply staying perfectly all the way, there's remarkably little flexing stress on the rocket.  It's compressed longitudinally (drag hitting it from the front, engine thrust hitting it from the back), but there's no torque or lateral force at any time, which is quite gentle on the rocket and doesn't cause problems.

49 minutes ago, dire said:

much stubbier and shorter, with fewer bits sticking out of the fairing and a single large "backbone" piece that can minimize flexure.

That's pretty much how my rockets look.  But "stubby" is a relative term, would have to see a screenshot of your vehicle to get an idea of whether it's more or less stubby than my typical ones.

 

[dire]

Check out the Doma Arigato, Duna mission report- It has tons of screenshots, at least one per mission. Here's the first one, as an example. Note that even though this is the prototypical payload that the standard launch vehicle was built to carry, it's still a pretty tall and bendy payload mass even though it fits under the fairing. Most later payloads have bits sticking out of the fairing, although I don't think I took pictures of most of those on the pad. Although, I have 318 screenshots in my folder right now  --- just numbers and dates, no descriptions and no thumbnail. I probably have something....somewhere...

Oh, I found a good one. So, one more. Notice the bits sticking out of the fairing.

Edited August 16, 2019 by dire

[Loskene]

Copy one of Tyler Raiz' kOS launch scripts and remove what you don't need. His are set up so you just have to edit the target orbital parameters and it'll take care of the variable details on the way up. There really is no one-size-fits-all gravity turn, even the GravityTurn mod uses a trial and error approach (from starting "best guess" parameters) to refine the optimal trajectory for each rocket you design, every time you launch it.