[1.0.5] GravityTurn version 1.3.1 - Automated Efficient Launches (1.1 pre-release available)

[Cloakedwand72]

On 1/10/2016 at 4:33 PM, Overengineer1 said:

Launch a craft into a low orbit with a few customizable settings.

Performing a Gravity Turn is arguably the most efficient launch procedure.  The plugin will take care of the entire ascent for you by maintaining a strict hold to prograde (as much as possible) and varying the throttle to keep the desired ascent curvature. The circularization burn will be up to you, but it's normally less than 50 m/s.

The "Best Guess" button tries to find the best settings for a particular rocket. Here's the best I've seen it do so far, 80km orbit in 2987m/s: http://gfycat.com/WellmadeDefiantBlueshark

Download the mod Here

View the source Here

License: GPL V3

Requirements:  None.  (Optional: MechJeb for circularization burn)

Features of this version:

• MechJeb Integration: If a MechJeb module is on board, order it to do a circularization burn after ascent (by popular demand)
• Auto-detect launch TWR and guess best ascent settings.
• More aggressive ascent guess for SRB rockets based on max TWR.
• Better tracking of initial turn heading.
• Pitch adjustment in upper atmosphere for very low TWR upper stages.
• More intelligent triggering of procedural fairing stages based on dynamic pressure.
• Maintain control through to atmosphere exit

Neat.Please add to Kerbalstuff so we can find out when up dates come out.And dos it work with 1.0.5+.Ps is it still worth learning how to dock and rendezvous?

[Overengineer1]

It's only worth learning to dock and rendezvous if you plan to meet up with some other ship and/or join two ships together.

GravityTurn is now available on Kerbalstuff.

[maculator]

This! 

I'll give it a shot tomorrow, looks interresting.

 

[mcirish3]

21 hours ago, Overengineer1 said:

The stage calculations are done many times per second, but they're just some basic arithmetic.  The total CPU load for the entire mod is vanishingly small next to the overall load for the game.  If you're asking about how I calculate the TWR, then it is only the launch stage that is taken into account here.  For now.

Actually I was hoping for something along the lines of how your equations differ from THIS:

I have been playing KSP for 4 years but have yet to come across the necessary information to derive a proper Idea gravity turn formula (i.e. most energy efficient>>least dv) for any rocket build at any desired orbit at any assent angle with any initial velocity vector and any atmo density and height..  I probably missed it somewhere or maybe I am just not smart enough to understand it when I saw it.  In any case it is mostly out of curiosity and maybe the possibility of providing a mod maker with the formula to finally create an ideal assent controler for all cases.

Edited January 13, 2016 by mcirish3

[Overengineer1]

GravityTurn works by maintaining a particular time to AP.  This is purely based on experimentation by me, but it also happens to be a nice way to describe a trajectory that ascends in an asymptotic curve.  It's also nicely translatable to something that a human can do, just watch the TimeToAP and adjust the throttle.

The two other factors that influence the path are when to start the turn, and how hard to turn when you do.  The answer to those would ideally be "immediately" and "very hard", but in reality if a vessel is not able to get the TimeToAP high enough fast enough, the curve will top out too low in the atmosphere.  This will usually result in the vessel overheating.  It seems like we are balancing between maximum efficiency and overheating, rather than just finding the ideal efficiency point.

I think the only way to find the ideal point programmatically would be to actually simulate the launch a bunch of times with different parameters and find the best one that doesn't overheat any parts.  But this is a pretty intense set of computations, to compute the drag coefficient on each part at a rotation that we'll have to determine and figure out the fuel consumption and staging how it will evolve throughout the launch, which all gets more complicated because we're thrusting the entire time...  All of that would have to be included in any equation to try to describe an ideal launch.

I think the experimental results are pretty good, and I can say for everything I've tested there isn't much room to improve.

[mcirish3]

Hmm... Seems to me the Atmo density is constant for any given height (no wind or turbulence in KSP)  and given all initial and final conditions ( they only need be identified beforehand) can be set before launch.  As such then you are correct in saying we can not just use the absolute optimal path due to the disintegration of the rocket before reaching orbit, but for any given rocket there is a "Do NOT OVERHEAT" upper limit curve that is also determined by the parameters of the rocket before launch and this in reality would be the most optimal and energy efficient curve that does not result in the destruction of the rocket or parts of the rocket.  As such then it would seem to me that it would be possible to derive from the available set of data and input parameters a general formula (probably a rather complex one I grant you) that could give an ideal assent curve under nearly any condition.  Such a formula should in reality be extremely elementary for a computer to handle since it only needs to run the calculation once. 

OF course I could be missing something @NathanKell  or @eggrobin Please correct me if I am wrong.

[Overengineer1]

You need to factor in the acceleration of the engines, that's the part that's missing.  You need to figure out how fast you're going, then you can figure out what the drag is, then you need to decide what your thrust should be (because it won't be a constant), and then you can know what your net acceleration is going to be.  And then you can move to the next step, some fraction of a second later and start again.  While you're doing this you have to track the heating of every part vs. its maximum temperature, which by the way you have to calculate separately from drag, including heat convection to other neighboring parts...  

Calculating the simple zero thrust trajectory is simple enough, there's plenty of existing code out there I could just use..  Doing it under continual yet varying thrust and figuring out if you're going to melt your parachute is I think way beyond the value of what it would gain us.

[NathanKell]

density is a function of pressure (in KSP that is constant for a given height and latitude and time of day) and temperature (in KSP that is constant for height but varies by latitude and time of day). So no, you can't trust that at x km the density is y kg/m^3.

[Superfluous J]

15 minutes ago, NathanKell said:

density is a function of pressure (in KSP that is constant for a given height and latitude and time of day) and temperature (in KSP that is constant for height but varies by latitude and time of day). So no, you can't trust that at x km the density is y kg/m^3.

TIL that temperature and density in KSP vary by time of day. I assumed this wasn't the case. Nice to know!

[mcirish3]

35 minutes ago, Overengineer1 said:

You need to factor in the acceleration of the engines, that's the part that's missing.

I did not forget i expected that that is a given.  a= Vt^2 (my goodness why can't we have Latex on a forum for a rocket sim game...sorry that has bugged me for years)
also I get that it is not constant acceleration do to dm/dt  but this should be solvable with differential equation calculus.
I was pouring through my classical mechanics book on this but I seem to have forgotten where to find the full rocket equation that included the drag equation .  In any case if I could figure out how to set up the problem I think it should be solvable.  Just maybe no one has tried.

 

I guess I thought maybe you would have some insight for me, this problem has puzzled me for a long time but I never really have been able to figure out where to start. ( was around back in 2012 when they were discussing this topic for mechjeb's auto assent.)
 

Edited January 13, 2016 by mcirish3

[mcirish3]

1 hour ago, NathanKell said:

density is a function of pressure (in KSP that is constant for a given height and latitude and time of day) and temperature (in KSP that is constant for height but varies by latitude and time of day). So no, you can't trust that at x km the density is y kg/m^3.

In deed I did not know that either.  Thank You.  But still this is a computer simulation so these this are governed by algorithms.  which is to say we should be able to say exactly what these values will be before we ever get there since Squad knows exactly everything there is to know about these parameters both what they have been, and what they will be, for any height, latitude and time of day.

 

50 minutes ago, 5thHorseman said:

TIL that temperature and density in KSP vary by time of day. I assumed this wasn't the case. Nice to know!

 But that just adds one level of complexity.  Time of day is an initial condition and the rest would be determined by the calculated flight path.

Edited January 13, 2016 by mcirish3

[mcirish3]

Oh does that mean that most of this is outdated?

http://wiki.kerbalspaceprogram.com/wiki/Atmosphere

 

[Superfluous J]

1 hour ago, mcirish3 said:

Oh does that mean that most of this is outdated?

http://wiki.kerbalspaceprogram.com/wiki/Atmosphere

 

Actually, most of THIS is outdated

http://wiki.kerbalspaceprogram.com/wiki

[Boris-Barboris]

4 hours ago, mcirish3 said:

Such a formula should in reality be extremely elementary for a computer to handle since it only needs to run the calculation once. 

No, it's not simple. It's not even a formula, it's a trajectory itself, derived from optimality problem by calculus of variation methods. There's no need for this in KSP.

Edited January 13, 2016 by Boris-Barboris

[Snarfster]

1 hour ago, 5thHorseman said:

Actually, most of THIS is outdated

http://wiki.kerbalspaceprogram.com/wiki

Time to send up a drone with KOS and a barometer?

 

[mcirish3]

 

5 hours ago, Boris-Barboris said:

It's not even a formula, it's a trajectory itself, derived from optimality problem by calculus of variation methods.

Thank You for pointing at a solution.

5 hours ago, Boris-Barboris said:

There's no need for this in KSP.

Need??  It is a game there is no "need" for any of this, but it is still fun to try. 

[Joco223]

Does this mod work in FAR? I tried it bit when it starts the gravity turn, the rocket just flips out of control. I tried lowering the turn angle but it still flips. Is this mods problem or is it me not knowing how to build rockets in FAR?

[Overengineer1]

The guesses are not optimized for FAR (as far as I know), but it definitely works.  I've had other users report that it performs better in FAR than they can by hand.

[Boris-Barboris]

11 minutes ago, mcirish3 said:

Need??  It is a game there is no "need" for any of this, but it is still fun to try. 

Of course, fun is above all. It's just that getting what you want is far beyond "fun" zone. Simple googling in western literature gives stuff like this http://cas.ensmp.fr/~petit/papers/ifac2008/0637.pdf , you may find it useful. I keep my posture though - we don't need this problem to be solved, and everyone, who tries, will only suffer.

Edited January 13, 2016 by Boris-Barboris

[Joco223]

@Overengineer1 Ok. I guess i just need to fix my rockets then to not flip out

[Miravlix]

Tried it for a short while and it does seem like, it gets my rockets into space in a fairly fuel efficient manner.

Unfortunately that's not the same as it being a good launch, had one rocket end up coasting for 10m+ before it reached the edge of space, so I could finally do the worthwhile warp and generally it seems like this solution tend to keep the rocket at sub 70K.

 

The heat model allows it with no problem, I think maybe because the current system at higher altitudes end up cooling the ship faster than it can be heated and I wonder if it wouldn't result in explosions and inefficiency in the real world.

 

[mcirish3]

9 hours ago, Boris-Barboris said:

Of course, fun is above all. It's just that getting what you want is far beyond "fun" zone. Simple googling in western literature gives stuff like this http://cas.ensmp.fr/~petit/papers/ifac2008/0637.pdf , you may find it useful. I keep my posture though - we don't need this problem to be solved, and everyone, who tries, will only suffer.

Thank You for even more info.  As for suffer. It is only suffering if you don't enjoy it and I do enjoy a challenge.  I may not succeed in solving this but I will try and I will enjoy every minute of it.

Edited January 13, 2016 by mcirish3

[Sandworm]

I tried this a few times with 64k but couldn't get a consistent assent profile.  The options are nice, but every time I revert to launch it forgets the setting and resets to 'best guess'.  That makes fine tuning difficult.  Also..

(1) Some averaging is needed when it comes to the time to apa.  On most of my launches the second stage initially has a rather low t/w ratio.  GravityTurn reacts to this by increasing the AoA to push the ApA further away.  That's ok, but as the t/w ratio rise GravityTurn returns to prograge and stars feathering the throttle.  The combination of off-angle and then feathered throttle is not the ideal solution.  The math answer imho is to take the rate at which the time to ApA is reducing and look at the rate of change.  If it is slowing, if the time to ApA will never get 0, then offset thrust isn't needed and GravityTurn should continue on prograde.  Is it possible to disable the offset feature?

 

(2) Another nice option might be high/low acceleration limits.  On long 64k or RSS burns one way to smooth out the turn is to maintain a consistent G on assent, then go full throttle once nearly horizontal.   

Edited January 13, 2016 by Sandworm

[mcirish3]

On 1/13/2016 at 9:31 PM, Overengineer1 said:

Calculating the simple zero thrust trajectory is simple enough, there's plenty of existing code out there I could just use..  Doing it under continual yet varying thrust and figuring out if you're going to melt your parachute is I think way beyond the value of what it would gain us.

OK so after some heavy digging it turn out you are right and there is no known analytical solution to the goddard problem and to do what I was talking about would be very CPU intensive..so... sorry about all the fus I have made.  Unless this is true-http://arc.aiaa.org/doi/pdf/10.2514/6.IAC-06-E4.3.05

But I do have one thing.  In digging around I found out that there is almost 0 info about the pst 1.0 ksp atmo.  This is something I can may be do something about.  It would be nice if I had some kind of guidance from squad but well the creators of mecheb did not have so I guess I can figure it out.

[Jso]

Very nice!

Please, have it remember the last used settings.