Gravity Turn Optimization Problem

[Lynch]

Hi all, I am developing a mathematical model for gravity turn.  Basically, I tried to get the Free Body Diagram of the rocket.  There are 4 forces acting on the object, these are;

• Fdrag;
• FhorizontalThrust;
• FverticalThrust;
• Fgravity;

By simplistic approaches, I chose my TWR value to be 2.00 and my mass to be 50 tonnes since all my vehicles tend to be between 0-100 tonnes and 1.5 - 2.5 TWR.  After playing with the values, I constructed these forces in terms of height and mass.

So thrust = 2mg = 1000 kN when we take a mass around 50 tonnes.

• Fdrag = 3.92 * Exp(-0.0001*h) kN
• FhorizontalThrust = 1000 * sin(x) kN
• FverticalThrust = 1000 * cos(x) kN
• Fgravity = 490.5 * (600000/(600000+h)) k

In all these calculations h is calculated in terms of "meters" and x is calculated in terms of "degrees".

The question is;

After the launch of this vehicle, it is planned to go Vertical until it reaches h=1000m, as soon as it reaches h=1000m, it is planned to do a gravity turn to an angle of "x" degrees. What is the optimum angle so that the rocket continues its path and when it becomes parallel to the ground, it reaches V=2250m/s.

My tests that involve try and error shows that in the latest version of the KSP we can orbit with around 2600 dV.  The sooner the gravity turn, the better it is.  Yet your rocket has to be designed fit for it.

 

Here is my work on the paper;

 

Fdrag was calculated simply by using excel trend line through datas taken from the terminal velocity.

Fd = 0.5 * p * v² * d * A

p = e^{(-0.0002 * h)}

v = 98*e^{(0.0000973 * h)}

Coefficient of Drag * Area = 0.2 * 0.008 * mass         (I know this value is for the old KSP, I would appreciate any further updates on this value).

Fd = 3.92*e^(-0.0001h)kN

Fgravity = mg

g = g₀*(r₀/(r₀+h))²

^{mass = 50000 kg}

r₀=600000m for kerbin

g₀=9.81 m/s² for kerbin

Fgravity = 490.5*(600000/(600000+h))² kN

[Nicias]

Remember that drag goes against the current direction of velocity, also, you will probably want to use radians for your angles.

Finally, this looks like you are about to apply a standard calculus  based approach. The problem with that is that you are not just optimizing over a single parameter. You are actually optimizing over the functions of time, pitch and thrust level. 

You will have to use a calculus of variations approach to get a full solution.

[Snark]

You also need to review your assumptions.  If you're waiting until 1000m to start a gravity turn, that is way too late-- especially if you're launching with a really high TWR, like 2.  You should be starting your gravity turn practically right off the pad.

Of course, you can do the calculations based on "what if I climb to 1000m first?"... i.e. "what's the most efficient path, if I start off that way"... but it's kind of moot.  You'd be optimizing a non-optimal situation.

[RX2000]

Too much math. Isnt this what Mechjeb is for?

[Lynch]

17 minutes ago, Snark said:

You also need to review your assumptions.  If you're waiting until 1000m to start a gravity turn, that is way too late-- especially if you're launching with a really high TWR, like 2.  You should be starting your gravity turn practically right off the pad.

Of course, you can do the calculations based on "what if I climb to 1000m first?"... i.e. "what's the most efficient path, if I start off that way"... but it's kind of moot.  You'd be optimizing a non-optimal situation.

Well my launch is basically vertical for a distance to let the rocket balance itself. Then I want a gravity turn as low as possible. You are right though.

 

you seem to be knowing this math, do you think length of the rocket affects the turn?

also I dont want to just do the gravity turn I dont care about the time it take but as soon as I am on 70km I want to be in the orbit, I dont want to do a circularisation is this possible?

taking these into consideration say I turn at X but is there such a theta angle that allows with correct thrusting to provide me such an ascent? Are there non kerbal free programs to simulate this?

[DoctorDavinci]

9 minutes ago, RX2000 said:

Too much math. Isnt this what Mechjeb is for?

There are those who enjoy solving a problem themselves and then there are those who couldn't be bothered and use other peoples creations to achieve their goals

If you use mechjeb, technically you didn't have a successful launch as it was mechjeb that had the success

[Leafbaron]

17 minutes ago, DoctorDavinci said:

There are those who enjoy solving a problem themselves and then there are those who couldn't be bothered and use other peoples creations to achieve their goals

If you use mechjeb, technically you didn't have a successful launch as it was mechjeb that had the success

"If I have seen further it is by standing on the sholders of Giants."- Isaac Newton

[Freshmeat]

As far as I know, the problem of efficient gravity turns is only solvable by numerical methods, and the ascent profile varies with each craft.

[storm6436]

I've been looking at attempting to create a mod that does just this for arbitrary rockets and initial orbitd for a while.    I keep getting distracted by the math and physics classes I'm taking for the degrees I'm pursuing. 

 

 

Edited November 16, 2016 by storm6436

[diomedea]

@Lynch: can see a few simplifications in your model, let me try to tell a bit (I'm also developing something similar, though with different purpose).

Any flying body is affected by 4 forces:

- Thrust (always directed in the engine's gimbal direction, therefore not always aligned with the vessel longitudinal axis), it's scalar being ISP*g*dMf/dT. ISP changes with atmospheric pressure, therefore altitude; g is the value of gravity at that altitude (also changing), dMf is the amount of fuel burned in dT time (that depends on the throttle setting and engine specification).

- Weight (always directed towards the mainbody center) is variable with altitude, W = m * g where g = GM / (R+h)^2 (g = gravity, G = gravitational constant, M = mass of mainbody, R = radius of mainbody, h = altitude); m is the vessel mass that is also variable (at least because of dMf/dT, the fuel burned).

- Drag is a vector always opposite the direction of travel (therefore, retrograde). Fd = 1/2 * v^2 * ρ * Cd * A, v being the vessel instantaneous speed, ρ the air density (changes with atmosphere pressure and temperature, both change with altitude, temperature also with Sun position and latitude), A the cross-sectional area of the vessel (so, if the vessel isn't aligned with the prograde vector, A increases), Cd is the drag coefficient that depends mainly from shape and speed v (against the mach speed, that also changes with air density). Computing Cd is actually the main issue here, KSP has different coefficients for speed with nose, surface or tail relative direction of each part, and A is computed for each part given direction of travel and occlusion from other parts.

- Lift, a vector going perpendicular to the direction of travel, Fl = 1/2 * ρ * v^2 * Cl * A (quite similar to drag, isn't it?), where Cl (lift coefficient) depends sharply from angle of attack (AoA), that is the angular difference of the longitudinal axis from prograde direction.

Sorry it the above appears intimidating. It's rocket science actually....

Edited November 16, 2016 by diomedea
weight instead of gravity...

[Lynch]

1 hour ago, DoctorDavinci said:

There are those who enjoy solving a problem themselves and then there are those who couldn't be bothered and use other peoples creations to achieve their goals

If you use mechjeb, technically you didn't have a successful launch as it was mechjeb that had the success

aye aye

46 minutes ago, storm6436 said:

I've been looking at attempting to create a mod that does just this for arbitrary rockets and initial orbitd for a while.    I keep getting distracted by the math and physics classes I'm taking for the degrees I'm pursuing. 

 

 

ive been trying to solve this for 1 year, always got distracted by classes and other games

41 minutes ago, diomedea said:

@Lynch: can see a few simplifications in your model, let me try to tell a bit (I'm also developing something similar, though with different purpose).

Any flying body is affected by 4 forces:

- Thrust (always directed in the engine's gimbal direction, therefore not always aligned with the vessel longitudinal axis), it's scalar being ISP*g*dMf/dT. ISP changes with atmospheric pressure, therefore altitude; g is the value of gravity at that altitude (also changing), dMf is the amount of fuel burned in dT time (that depends on the throttle setting and engine specification).

- Weight (always directed towards the mainbody center) is variable with altitude, W = m * g where g = GM / (R+h)^2 (g = gravity, G = gravitational constant, M = mass of mainbody, R = radius of mainbody, h = altitude); m is the vessel mass that is also variable (at least because of dMf/dT, the fuel burned).

- Drag is a vector always opposite the direction of travel (therefore, retrograde). Fd = 1/2 * v^2 * ρ * Cd * A, v being the vessel instantaneous speed, ρ the air density (changes with atmosphere pressure and temperature, both change with altitude, temperature also with Sun position and latitude), A the cross-sectional area of the vessel (so, if the vessel isn't aligned with the prograde vector, A increases), Cd is the drag coefficient that depends mainly from shape and speed v (against the mach speed, that also changes with air density). Computing Cd is actually the main issue here, KSP has different coefficients for speed with nose, surface or tail relative direction of each part, and A is computed for each part given direction of travel and occlusion from other parts.

- Lift, a vector going perpendicular to the direction of travel, Fl = 1/2 * ρ * v^2 * Cl * A (quite similar to drag, isn't it?), where Cl (lift coefficient) depends sharply from angle of attack (AoA), that is the angular difference of the longitudinal axis from prograde direction.

Sorry it the above appears intimidating. It's rocket science actually....

actually

 

My simplifications come from exactly those formulas.

I have formulated

effective gravity and the air density depending on the altitude and modeled an average temperature, I now need approximation of the Cd value for rockets with 1,25 2,5 and 3,25 parts

[diomedea]

2 minutes ago, Lynch said:

... I now need approximation of the Cd value for rockets with 1,25 2,5 and 3,25 parts

Ok, let's go a bit deeper about Cd.  Size of parts has no meaning with Cd (it affects A, the cross-sectional area, and that is computed out of the dragcube for each part, known the aspect of the part against the flow direction). Cd instead is computed out of curves ("lerping" values where curves are described as collection of points in Unity). Look at the physics.cfg in the KSP root folder, you'll find those curves (e.g. DRAG_TIP, DRAG_SURFACE, DRAG_TAIL), those are for the direction the part presents to the flow, at different mach speed (first value with each point is mach speed, then is the drag coefficient, then the in and out tangents of the curve).

[wumpus]

2 hours ago, RX2000 said:

Too much math. Isnt this what Mechjeb is for?

I don't really think mechjeb does this.  And once you are done you will still need mechjeb to follow the gravity turn (personally, I'd just want to optimize for the initial angle (and feed that into mechjeb) and let the thing do a gravity turn, but there's no reason to believe that the moment of inertia of the rocket will give your gravity turn an optimal flight.

It also looks like the original assumptions don't employ a "gravity turn" (i.e. allowing the rocket to alter the angle of attack due to the rocket "falling over").  Expect a set of nasty differential equations that have to be approximated numerically and fed into an optimizer.

[Lynch]

When doing gravity turns, do we have to use the Orbit prograde? Because im doing my calculations for the angles with the surface.  What is the correct way of using those?

 

 

I really need someone to tell me exact way of calculating Fdrag in kerbal space program.

Edited November 16, 2016 by Lynch

[NSEP]

4 hours ago, Snark said:

You also need to review your assumptions.  If you're waiting until 1000m to start a gravity turn, that is way too late-

I always do my turn at 10KM, but i also do it manualy.

[SchweinAero]

34 minutes ago, Lynch said:

When doing gravity turns, do we have to use the Orbit prograde? Because im doing my calculations for the angles with the surface.  What is the correct way of using those?

The ideal gravity turn is just what it says on the tin: a turn made by gravity only. In that case, the rocket would smoothly fall over by itself as it ascends, requiring just a slight sideways nudge at the start and some throttle control throughout.

[diomedea]

49 minutes ago, Lynch said:

I really need someone to tell me exact way of calculating Fdrag in kerbal space program.

Something you're not going to catch unless you start listening.

Here are a few lines to compute drag in KSP (not from KSP itself, that wouldn't be allowed, but a tool doing the same). Now tell me if that's helping more than providing the rationale of how those work.

Spoiler

/*by NathanKell
 * License: MIT
 */

...

vDrag += -p.dragVectorDir * p.dragScalar;

vLift += bodyLift;

....

Vector3d force = vLift + vDrag; // sum of all forces on the craft   

Vector3d nVel = v.srf_velocity.normalized;         

drag = Vector3d.Dot(force, -nVel); // drag force, = pDrag + lift-induced drag

Computing drag is a very complex thing, both in reality and KSP. The tool I showed a bit about, strictly interfaces with KSP itself to receive data about each part of a vessel, the air density, the speed vector, and else. All things you will need to compute yourself first, and the only way is to understand how KSP does. The whole procedure is far too complex to give in a post. I can only hope you may work through it a bit at a time. And however your stance is disheartening.

[Leafbaron]

I usually start my gravity turn at  specific speed not an altitude. Usually around 85-100m/s, if my TWR is high then the turn start earlier, if my TWR is low the turn starts later. I have found it to be quite effective. Usually aiming to be at 45 degrees by 400-500 m/s. 

[Snark]

3 hours ago, NSEP said:

I always do my turn at 10KM, but i also do it manualy.

Fair 'nuff, if you like flying that way, more power to you! 

Just be aware that you're wasting hundreds of meters per second of dV.  Flying straight up to 10 km is really inefficient.  Of course, it's up to you how much (or whether) that's an issue for you.

[septemberWaves]

7 hours ago, DoctorDavinci said:

If you use mechjeb, technically you didn't have a successful launch as it was mechjeb that had the success

It depends on how you define a successful launch. For you, a successful launch is presumably a launch in which your manual flying goes according to plan. For others (such as myself) a successful launch is one in which, under near-optimum parameters (such as a MechJeb autonomous ascent), the vehicle design works as intended. A lot of people who use MechJeb's autopilot are people who, like me, spend a huge amount of time and effort designing spacecraft and optimizing them so that they work perfectly under ideal conditions*, but who do not get as much enjoyment from the (frankly rather tedious) process of a manual launch. It's a single-player game, it's really up to the individual to decide what they consider to be a success for them.

*I am aware that MechJeb's autopilot is not perfect - in fact, the thrust vectors on just about all of my asymmetrical rocket designs end up forcing MechJeb to use a more efficient trajectory than its standard ascent - but it's good enough for testing purposes, and good enough to simulate a manual gravity turn conducted by an experienced player.

Edit: that does bring up another good point in favor of MechJeb's autopilot. I am a huge fan of rockets with asymmetrical SRB patterns (which has been the case since I made some stock-optimized Atlas V rockets a while ago), but attempting to fly them manually almost always ends in disaster, and is really a lot more effort than the design is worth. However, if using MechJeb to automate the ascent, and assuming that the launch vehicle is correctly aligned relative to the launch azimuth (which is not difficult to achieve), the slightly-off thrust vector tends to cause the rocket to tilt into a very efficient trajectory. And any launch which saves upwards of 200m/s of delta-v is a launch that I'd consider a success.

Edited November 16, 2016 by eloquentJane

[Jonfliesgoats]

First, I think you are really cool and am very impressed you took the time to draw out your notes and post them here.  It's always refreshing to see people who aren't shy around numbers and are willing to expose their ideas and work to the scrutiny of others.  You rule.  

When it comes to designing an efficient maneuver, you can really go a long way down a particular rabbit hole.  Also, pilots, engineers and  especially pilots who are engineers all have HUGE egos, so we all like to get our two cents in.  

1.) Higher TWR is better, within limits.

2.) Earlier turn is better, within limits.

3.) Drag is significant.  Gravity is an order of magnitude more costly than Drag.  Of course, this is only true within certain limits.

4.) Practicality is important.  Controllability can be a problem at high TWR.  Any alpha, sideslip or even roll on your craft starts creating asymmetric aerodynamic forces.  This meanspossible  static and dynamic instability.  If your craft is well balanced and designed, these forces should be within the control authority of your craft.  This also means that some mass in control surfaces, monompropellent or fuel to Vernor engines is spent on controllability.  My thumbs in KSP are pretty clumsy, so I actually get more efficiently out of less control intensive profile.  If I am always a degree or so off from what what I want and trying to correct, I effectively double my DV losses to atmospheric drag.

5.) Running the numbers in a vacuum is not too tough.  Integrating those numbers over an atmospheric ascent, using the scale height to calculate the aerodynamic effects at different speeds altitudes and angles gets a little more daunting.

6.) Good engineering requires good approximations.  At the end of the day, though, you will be using a lot of approximations.

[Lynch]

First of all Id like to thank everybody above,

2 hours ago, diomedea said:

Something you're not going to catch unless you start listening.

Here are a few lines to compute drag in KSP (not from KSP itself, that wouldn't be allowed, but a tool doing the same). Now tell me if that's helping more than providing the rationale of how those work.

  Reveal hidden contents

/*by NathanKell
 * License: MIT
 */

...

vDrag += -p.dragVectorDir * p.dragScalar;

vLift += bodyLift;

....

Vector3d force = vLift + vDrag; // sum of all forces on the craft   

Vector3d nVel = v.srf_velocity.normalized;         

drag = Vector3d.Dot(force, -nVel); // drag force, = pDrag + lift-induced drag

Computing drag is a very complex thing, both in reality and KSP. The tool I showed a bit about, strictly interfaces with KSP itself to receive data about each part of a vessel, the air density, the speed vector, and else. All things you will need to compute yourself first, and the only way is to understand how KSP does. The whole procedure is far too complex to give in a post. I can only hope you may work through it a bit at a time. And however your stance is disheartening.

I'd like to thank you for your answers, yet I know i might be running around the bushes; I am sick of this drag  , I ll be going over those tools you showed but you are completely right.  Im just trying to do right assumptions so that I get a good average of it rather than exact calculation.  Yet, since I ll be excelling this I may go for exact numbers as you provided the tools

[DoctorDavinci]

48 minutes ago, eloquentJane said:

It depends on how you define a successful launch. For you, a successful launch is presumably a launch in which your manual flying goes according to plan. For others (such as myself) a successful launch is one in which, under near-optimum parameters (such as a MechJeb autonomous ascent), the vehicle design works as intended. A lot of people who use MechJeb's autopilot are people who, like me, spend a huge amount of time and effort designing spacecraft and optimizing them so that they work perfectly under ideal conditions*, but who do not get as much enjoyment from the (frankly rather tedious) process of a manual launch. It's a single-player game, it's really up to the individual to decide what they consider to be a success for them.

See the prior statement above the part of my comment that you quoted as it says exactly what you are saying in not so many words

As for using mechjeb for launching, by all means do it as that is the best part of KSP ... People can play the way they want and use whatever mods they want

[Jonfliesgoats]

HEY GUYS!!!

This old paper from Ames Research Center has actually been pretty useful in my KSP game.  Lots of handy derivations.

https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19880010028.pdf

Trajectory Characteristics and Heating of Hypervelocity Projectiles Having Large Ballis tic Coefficients 

Michael E. Tauber Ames Research Center Mofett Field, Calfornia 

Edited November 17, 2016 by Jonfliesgoats

[Draco T stand-up guy]

10 hours ago, Lynch said:

Well my launch is basically vertical for a distance to let the rocket balance itself.

Gravity Turn lets you set m/s for when the turn starts.

It's also OpenSource so having a look at how they do it may help with your own.