Jump to content

How do you do a gravity turn?


Nich

Recommended Posts

Or more precisely how do you correct a gravity turn mid flight?

So I have started playing with KOS and I am trying to figure out how to do a gravity turn.  I am attempting to write a generic script that can work with a range of vehicles.  I have written, what I feel, are a couple of really good predictive scripts that use TWR, Dynamic pressure, AP, Time to AP, vertical speed and Burn time.  But they keep getting messed up by the changing TWR and staging.  When TWR goes up the craft pitches down too early.  Then at staging when TWR drops it realizes it has to pitch up a lot.  I attempted using a TWR correction factor with little success as it appears the relationship is very non-linear.  So I think I need a way to minimize pitching adjustments as TWR departs from average.  Perhaps 1/((AverageTWR-TWR)^2+1/TWR).  Would average acceleration would be DV/BurnTime?  Thus making average TWR = Average Acceleration/9.8.

I am just about out of ideas and the last thing I want to do is build a lookup table and fly to that.

Link to comment
Share on other sites

Why are you pitching up and down?  Isn't the idea of a gravity turn to simply follow prograde?

Seems to me that you should instead consider throttle; if you messed up the start and are going to high, throttle back to increase the turn rate, and if you're going too low, throttle up or abandon the gravity turn for an emergency maneuver.

In terms of predicting where you should be, you could get fancy, but maybe try interpolating between the nearly-empty stage N and the full stage N+1.  As you start to run out of fuel for one stage, pretend its stats are gradually changing to the stats of the next stage and act accordingly so there is no sudden shock.  Keep the deviations gradual, and plan ahead.

Link to comment
Share on other sites

2 hours ago, Nich said:

So I have started playing with KOS and I am trying to figure out how to do a gravity turn.

I've had great results with a rather simple approach that would turn the rocket so that srfprograde would reach X pitch by the time I had an airspeed of Y (IIRC 80° @ 100m/s, but I'm not too sure). Then follow srfprograde until the first stage burned out, and only *then* would I start to seriously consider where I was and if any adjustments were necessary.

The X degree by Y airspeed scheme turned out to be surprisingly versatile: over a wide range of initial TWRs, it would place me on a reasonable trajectory the later parts of the script could work with, *without* requiring massive control inputs at any time of the flight. It looked a lot more planned than it really was.

ETA:

3 minutes ago, Nich said:

Sorry forgot to mention playing in RP-0 so most launch engines don't have throttle. 

Even better, because I did too. Above approach worked very well for Atlas, Titan, and all types of Saturn. Also Proton and R-7.

Edited by Laie
Link to comment
Share on other sites

@suicidejunkie

Sorry forgot to mention playing in RP-0 so most launch engines don't have throttle. 

You do make a good point as I was using current accelerations and rates to make my predictions but I could probably find a way to average the remaining stages together and then use that to make my predictions.  Challenging but feasible Thanks for the inspiration.

Link to comment
Share on other sites

@Laie

Sounds pretty similar to what I am doing.

Phase 1 launch Heading(90, 90)

Phase 2 Initiate turn based off Speed = f(TWR)

Phase 3 Follow surface prograde until 45 degrees or 10% peak dynamic pressure

Phase 4 (Killing me) Minor adjustments to Fix AP

Phase 5 (have not started but doesn't seem too hard) accelerate to orbital velocity and circularize

 

For this particular rocket I have phase 2 nailed and if it would just follow prograde it would be perfect.  Currently the program can vary pitch infinitely but perhaps I should tie it into Prograde so that it cant run away.  This rocket suffers from lack of significant control authority the last 2 minutes of its flight (3-8 degrees max)

Edited by Nich
Link to comment
Share on other sites

5 hours ago, Rocket In My Pocket said:

How do I do a gravity turn?

With the "W" key mostly.

Like this: W........W...........W..W....W....W...W....W Then at some point I stop hitting W. Hope that helps you. :rolleyes:

I use "D" myself.  The best ones go .D....D..D................................................A...T and just kinda fall into a nice orbit on their own.  Unfortunately I can't seem to find a way to make that happen intentionally.

Worse, anything with a light payload in a big fairing goes more like:  .D...D...D......S....W....D..D.A..W...S...S.S.S.A..D..D.D.AA.D.DDDDDDDDD.........revert

 

Link to comment
Share on other sites

ROFL.

It is amazing how easily I can do it and how hard it is to tell a computer to do it.  I just tested it and sure enough my turn was perfect.  Following SRFPROGRADE the entire way up ended in a 800x150 orbit with 400 dv left.  I am still upset with the KOS PID.  It used 4000 helium, MJ used 400 and I can do it using 40 :/.  Now I just need to make correction logic that does nothing and circularization logic.

Just incase anyone want to use my turn logic I thought I would share.  It probably needs to be tested and tweeked for a starting SLT TWR of 1.1 but for 1.48 it is perfect

wait until airspeed > -300*maxthrust/mass/9.8+490.
set mypitch to 85.
set mysteer to heading(myheading,mypitch).

wait until arctan(verticalspeed/groundspeed)<85.
lock steering to srfprograde.

Edited by Nich
Link to comment
Share on other sites

24 minutes ago, Nich said:

It is amazing how easily I can do it and how hard it is to tell a computer to do it.  I just tested it and sure enough my turn was perfect.  Following SRFPROGRADE the entire way up ended in a 800x150 orbit with 400 dv left.  I am still upset with the KOS PID.  It used 4000 helium, MJ used 400 and I can do it using 40 :/.  Now I just need to make correction logic that does nothing and circularization logic.

You might look into the steering manager to tune the "cooked" control.

https://ksp-kos.github.io/KOS/structures/misc/steeringmanager.html

If I understand the explanations correctly, the easiest thing to do would be to increase PITCHTS, ROLLTS, and YAWTS, making it essentially lazier about applying corrections. I've yet to test it out myself: I looked it up yesterday after my Mercury capsule burned through every last drop of HTP overcorrecting on descent.

EDIT: My guess is that the default kOS PID for steering is tuned to stock, where most people use magic torque machines to maintain heading, not RP-0 where 99% of the time, there's not a single solitary reaction wheel onboard.

Edited by Starman4308
Link to comment
Share on other sites

It seems to me to get something that works with different designs you would have to monitor the center of lift, or drag as I think about it. I have never seriously thought about it, because I have a  bad habit of playing by the seat of my pants on launches. But, I think you would need to be able to limit the angle between the center of thrust and the center of lift to 'x' degrees. I am not sure what the optimal, or acceptable value for 'x' would be though...

Link to comment
Share on other sites

@Starman4308

Thanks, I adjusted the

STEERINGMANAGER:MAXSTOPPINGTIME to 10

STEERINGMANAGER:PITCHPID:KD to 2

STEERINGMANAGER:YAWPID:KD to 2

because originally it would just spammed all 4 RCS ports randomly until it ran out of fuel.  Now at least it spams them in a random fashion that tends towards the target.  Interestingly pitch worked pretty well with acceptable over corrections for a PID but yaw was spamming 50% left 50% right the entire time.

 

I will admit the controller does a great job when you have vectored thrust.  I will have to try a vehicle with more RCS and the default settings.  I suspect the KOS PID needs a larger dead zone and more dampening.  If I ever get this launch script working writing my own RCS controller not based off a PID.

Link to comment
Share on other sites

23 hours ago, Nich said:

the last thing I want to do is build a lookup table and fly to that.

Why not, if it works?

Seriously, gravity turns aren't a big deal.  Here's how to do a gravity turns:

  1. Turn slightly eastwards, right off the pad, by the correct amount.
  2. Set SAS to follow :prograde:.
  3. Max throttle, staging as necessary, until your Ap gets to where you want it.

That's it.  That's all there is.

23 hours ago, Nich said:

Or more precisely how do you correct a gravity turn mid flight?

You don't.  You get it right the first time.  If you find out it's wrong, revert and try again.  Do this a few times and pretty soon you develop a pretty good feel for how it should be.

 

...Of course, I'm being a bit glib in the above.  The crux of the matter is that little phrase "...by the correct amount" that I kinda slipped in there.  :wink:

How much is "the correct amount"?  Well, judging that is a matter of practice.  In general, the higher the TWR of your rocket-- particularly, the TWR in the early stage of acceleration, up to 500 m/s or so-- the more of a turn you'll need.

I gather that what you really want is "how do I program an automated thing to do this for me", and that's hard.  I mean, really hard.  Not just because it has to account for varying future TWR of your ship, depending on ship design and how you stage and so forth, but also because different ships have different capabilities.  For example, some ships are a lot more aerodynamically stable than others.  A ship that's aerodynamically stable, and has steerable fins on the back, can often "correct" a somewhat misaligned gravity turn by pitching slightly up or down (i.e. above or below :prograde:).  However, a ship that's not so stable doesn't have that option, because if it gets off :prograde: even a little, it's likely to start tumbling uncontrollably and then the launch is toast.

And so forth.

Since you're trying to address a really really hard problem (virtually impossible to solve perfectly), then as a practical matter, you should either focus on some way to make the problem simpler, or else come up with some reasonable approximation which, though not perfect, is "good enough" to get the job done.

For example, it would be a lot easier to write a program that will do a gravity turn for a particular ship than for all-ships-in-general, since it has a problem smaller space to work with.  So, if you make a habit of always building your ships to have about the same TWR, then they'll all have similarly-shaped gravity turns and your job gets easier.

In terms of practicality:  I suspect it will be easier to code an automated solution if you work backwards from successful human-controlled launches, than if you try to solve it analytically.  For example:  How does a human know whether things are going well or poorly, as the launch proceeds?  Dunno what you do, but I know what I do:  I look at my pitch angle as a function of my speed.  I've got a pretty good model in my head of "when I am going this many meters per second, I should be pitched at about this angle."  And I don't need to track that super precisely-- i.e. I don't have a big huge table in my head with many angle entries for many different speeds, because it's really not necessary.  The most important one is 45 degrees:  that is, I know that I need to be going around 400 m/s by the time I get to 45 degrees away from vertical.  As long as I hit that, I'm pretty much guaranteed a successful launch.

So if I were going to try to write some sort of script to do this (which I won't, because I enjoy flying manually too much) :wink: ... probably what I would do, as a simple poor-man's solution, is try a few launches and record a few data points.  e.g. What angle is the pitch when I'm at 200, 400, 600 m/s?  Maybe just those three.  Do a few launches, record those, average them.  With a bit of interpolation, just those three data points would be enough for a script to have an idea of "if I am going at this speed, then my pitch should be N degrees".  And then write the script so that it tries to torque the ship up or down a smidgeon if the pitch isn't following what it thinks is the right angle for the current speed.

I suspect that will be a whole lot easier to write than to solve the thing analytically... and I suspect it would work at least as well, too.

Whatever you end up doing:  I suggest that you control pitch as a function of speed, not pitch as a function of altitude.  Reason for that advice:  I think it's more applicable across different types of rockets with different TWR.  I've found, for example, that I want to be about 45 degrees of pitch when I'm going 300-400 m/s.  It doesn't matter much if I have a higher-TWR or lower-TWR rocket; they both want to be pitched at about 45 degrees when they're at about that speed.  Of course, the higher-TWR rocket will hit that speed at a lower altitude than the lower-TWR rocket will, but if I just (mostly) ignore altitude and look at the speed, I've found it to be a remarkably general rule.

Link to comment
Share on other sites

I wrote a kRPC script that does repeated runs to find the optimal initial angle for a given rocket.

One of the challenges of trying to use a predictive approach is aerodynamics. Like depending on the TWR, drag, CoM/CoL and moment of inertia of the rocket it can tip over faster or slower. That is darn challenging to capture in static analysis. (rather like a tail-heavy plane, a rocket can even be designed so it naturally wants to pitch up rather than pitch down, naturally this isn't desirable because it would cause an extremely unstable rocket, but it's just to make the point that the rate at which a rocket tips over is variable and non-trivial to predict).

As a result of this you either have to do an adaptive gravity turn which steers to stay on course (or at least, to avoid falling into dangerous flight zones - follow prograde unless you're tipping too fast in which case pitch up is a darn fine approach), or do repeated runs.

Edited by blakemw
Link to comment
Share on other sites

Along the lines of "do it right from T-0", another angle to consider is when to abort (not revert necessarily) the mission and update the initial launch parameters to more correct values?

If going too high, at what point will you not have enough dV to make orbit and allow a safe place to review the mission?

If going too low, at what point do you need to abort and slow down to avoid burning up and/or impacting the ground?

 

PS: Pun not intended

Link to comment
Share on other sites

@Snark

After thinking about it Pitch based off speed doesn't work.  If you start off too low on your turn will will gain speed faster which will cause you to pitch faster causing you to burn up in the atmosphere and fail to reach target AP.  If you start to high you will not gain speed fast enough and by the time you reach target AP you will have a ton on vertical speed left making circulatization impossible.

I did graph the data.  Target was 155x155 orbit.  If I manually cut the throttle I probably could have had a 150x400 orbit.  As you can see final circulization was at 186km with 159 m/s vertical speed.  I have also included the CSV data at the very end.

G4u9gGy.png

*Second Vertical speed is supposed to be Expected AP.

Expected AP is calculated off the following code.  It is not too bad but I think it can be better

   set AP0 to apoapsis. //Starting AP
   wait 2.
   set TWR to maxthrust/mass/9.8. //TWR is used to modulate rate TWR is growing
   //The next equation does a lot.
   //First we calculate the rate that AP is growing
   //(APCurrent-APTwoSecondsAgo)/2 Seconds gives the rate that AP is increasing at.
   //Next we divide this rate in half because we want to to reduce to 0 at the end of the burn.
   //This assumes linear rate of decay (think Triangle)
   //Normalize this by multiplying by AverageTWR/CurrentTWR.  I hard coded 2.38 for the moment.
   //I think this value is too high at the moment.  I calcualted dv/burntime/9.8 or 9300/398/9.8.
   //This inculded the first stage and 300 dv not needed from the final stage.
   //If I remove these I end up with more like 2.29

   set APdelta to (apoapsis-AP0)*2.38/4/TWR.
   //Take the rate that AP is growing and multiply it by the remaining burn time then add that
   //to the current AP to get estimated AP

   set APexp to apoapsis+(APdelta*(duration-time+time0):seconds).

altitude, airspeed, prograde, vertical speed, expected AP, Time

766, 83, 83.66, , 82, 35087, 376

2730, 193, 72.02, 184, 76994, 361

6413, 356, 59.48, 307, 133036, 346

11998, 580, 48.81, 437, 138720, 331

19480, 831, 40.51, 540, 168867, 316

28064, 1098, 33.4, 618, 172181, 301

37654, 1428, 28.51, 674, 179925, 286

48408, 1877, 23.87, 760, 195218, 271

60660, 2485, 20.68, 877, 226553, 256

74411, 2877, 18.24, 901, 236201, 241

87558, 3058, 16.14, 850, 239711, 226

100027, 3269, 14.33, 809, 234115, 211

111860, 3496, 12.55, 759, 241813, 195

122796, 3691, 10.88, 697, 212022, 180

132839, 3920, 9.39, 640, 207316, 165 

142062, 4187, 8.07, 588, 204923, 150

150406, 4355, 6.87, 521, 199519, 135

157742, 4528, 5.77, 455, 194893, 120

164105, 4722, 4.72, 392, 191664, 105

169548, 4952, 3.86, 333, 189799, 90

174144, 5217, 3.07, 279, 188904, 75

177973, 5524, 2.4, 231, 188864, 60

181230, 5914, 1.85, 191, 189841, 45

183893, 6409, 1.48, 166, 192853, 30

186306, 7059, 1.29, 159, 210205, 15

 

Edited by Nich
Link to comment
Share on other sites

Been busy with work so I have not had much time to work on this but I have been thinking about it.  Please leave any comments or suggestions

The area under the curve is the altitude (m/s * s)

Since this is roughly triangular I feel it is a good enough approximation to assume Final AP = 1/2*base*height.

Base is fixed and is the burn time (398s).

Final AP is 150,000m  (user specified).

Height is the maximum vertical speed. 150,000*2/398 = 754m/s

From here is gets a little tricky.  The shape of the triangle can anything from a right triangle to an equilateral and my previous assumption is still valid.  Now I think the best way to go is to assume Min and Max points I feel the triangle should be allowed to have.  The first makes sense to me and is the midpoint of the burn (398/2).  The other I will have to take from the empirical data. (398/1.65).

From this I can make 2 lines to use during phase 1 of launch

line 1 (0,0) to (199,754) and line 2 (0,0) to (241,754).  When line 1 is crossed the rocket will pitch up relative to prograde and line 2 will pitch down.

Phase 2 starts when a vertical speed of 754 is reached.  At this time we will construct a new line from (398,0) to (x,754) and use a PID to track this line to the end of the burn.

Phase 3 will track 0m/s vertical speed until circularized.

Edited by Nich
Link to comment
Share on other sites

What I did for my kOS guided space shuttle launch was create an off-horizon pitch angle as a (non-linear) function of altitude. I based it off of a generic gravity turn I do in KSP, generally trying to smoothly tilt over and have have my nose at 45 degrees at 10km altitude.

Granted, the result of my script wasn't technically a gravity turn, but it was reasonably close, and being a function of altitude, could correct for changes of TWR by keeping the nose up longer if the TWR is lower than expected (thus the shuttle is staying in the lower atmosphere longer), or nosing over faster if the TWR is higher than expected (thus the shuttle gets to the upper atmosphere quicker).

The caveat to this is that it likely only works well for stable rockets, which do not risk flipping and or breaking up if the nose is brought more than a couple degrees off prograde. This could perhaps be mitigated to some extent by averaging the prograde vector in with the function-generated steering vector, thus keeping closer to the line of travel.

All this being said, if you look up "PEGAS" (Powered Explicit Guidance Ascent System iirc) on the forums here, I think you will find a thread on a kOS script that uses real-world guidance algorithms to guide rockets to orbit. I have not tried using it myself, but it definitely warrants a look at least for the understanding of rocket guidance it gives.

I believe that any guidance script that follows a gravity turn will require inputs of the stats for each stage of a rocket before launch. It may be possible to make the script capable of crawling through the parts tree and determine what stages when and how the rocket will fly, but that's past my level at the moment.

 

Edit: this page, while from the orbiter wiki and not KSP, is still applicable and gives a good overlook of equations and such used in the Powered Explicit Guidance algorithms

Edited by EpicSpaceTroll139
Dang autocorrect
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...