[1.4][1.7.7] GravityTurn continued - Automated Efficient Launches

[Beetlecat]

1 hour ago, 5thHorseman said:

No, you can't.

You can set up an Ap alarm during launch, but it sets the alarm to the current Ap which is changing. The alarm then goes off way early, frequently while still in atmosphere, and is totally counter to what I want to do which is start the launch and walk away.

If you know of another way, please document the click or two that is required to get it done.

Oh, I totally see that now. I wasn't meaning to be facetious.

Edit: --- but it sounds like you basically just want/need MechJeb...

Edited January 4, 2017 by Beetlecat

[Superfluous J]

1 minute ago, Beetlecat said:

Oh, I totally see that now. I wasn't meaning to be facetious.

Edit: --- but it sounds like you basically just want/need MechJeb...

I am NOT going down this road again, so I'll say it once and not respond again in this thread. I will not install a mod that does 500 things, 2 of which I want. I'd rather just not have those 2 things.

[AndyMt]

9 hours ago, 5thHorseman said:

One idea, assuming "Plop a maneuver node at Ap to circularize"* is still not an option: How about KAC integration to add a pause-the-game alarm at Ap, so I can hit launch and go make dinner without fear of coming back to my ship screaming back down through the atmosphere?

*I know circularization is possible if you have MechJeb installed but I don't want to install it just for that.

Separating the "optional maneuver node at Ap to circularize" is on my list actually. As for KAC integration: I just checked and @TriggerAu conveniently provides an interface for KAC: http://triggerau.github.io/KerbalAlarmClock/api.html

So - I'll add that to the list, too.

[damerell]

15 hours ago, 5thHorseman said:

I am NOT going down this road again, so I'll say it once and not respond again in this thread. I will not install a mod that does 500 things, 2 of which I want. I'd rather just not have those 2 things.

And this (still) makes no sense when the other 498 things aren't in any way something you're forced to use or significant consumers of resources or anything like that.

[razark]

Redacted.

Edited January 4, 2017 by razark

[AndyMt]

@razark,  @damerell and everyone else tempted: we've read all these arguments on the first few pages of this thread. Please don't start it again,  ok? Thx. 

Edited January 4, 2017 by AndyMt

[Jebs_SY]

Is anyone here who is familiar with the different kind of dV-losses?

The losses are different for mechjeb and GTC, right?

The MJ-losses are mostely clear for me:
M1) Drag loss - loss caused by aerodynamic pressure
M2) Gravitly loss - loss that is caused by preveting to fall back to earth while not in orbit
M3) Steering loss - loss caused by a engine not thrusting prograde (or retrograde, depending how one wants to define it)

Now in GT we have the following losses:
GT1) Air drag loss - same as MJ-Drag-loss
GT2) Gravity drag loss -  (=MJ-Gravity-loss?)(*)
GT3) Total vector loss -  (=MJ-Steering-loss?)(*)

And Total loss wich is the addition of all the losses. 

Now the point is, when launching a rocket that flies prograde straight up, M2 raises fast and M3 stays almost at 0 which makes sense for my understanding.

However at the same time GT3 is rising fast and GT2 is not rising as fast as M2. So the (*) assumptions are not met.

It seems like GTC is calculating the losses different. So I wonder if GT3 is the amount of loss cause by not burning in the horizontal direction. But that's just an idea. Maybe wrong.

Does anybody know how GT2 and GT3 are defined?

I made a video in which you can see an ascend with both losses displayed:

 

 

[Krombopulos Michael]

No matter how I set the star m\s, it seems to start turning immediately. Any way to fix this?

Nevermind. My game crashed and upon reloading it seems to be working

Edited January 12, 2017 by Krombopulos Michael

[AndyMt]

On 1/4/2017 at 10:42 PM, Jebs_SY said:

Is anyone here who is familiar with the different kind of dV-losses?

The losses are different for mechjeb and GTC, right?

The MJ-losses are mostely clear for me:
M1) Drag loss - loss caused by aerodynamic pressure
M2) Gravitly loss - loss that is caused by preveting to fall back to earth while not in orbit
M3) Steering loss - loss caused by a engine not thrusting prograde (or retrograde, depending how one wants to define it)

Now in GT we have the following losses:
GT1) Air drag loss - same as MJ-Drag-loss
GT2) Gravity drag loss -  (=MJ-Gravity-loss?)(*)
GT3) Total vector loss -  (=MJ-Steering-loss?)(*)

And Total loss wich is the addition of all the losses. 

Now the point is, when launching a rocket that flies prograde straight up, M2 raises fast and M3 stays almost at 0 which makes sense for my understanding.

However at the same time GT3 is rising fast and GT2 is not rising as fast as M2. So the (*) assumptions are not met.

It seems like GTC is calculating the losses different. So I wonder if GT3 is the amount of loss cause by not burning in the horizontal direction. But that's just an idea. Maybe wrong.

Does anybody know how GT2 and GT3 are defined?

I made a video in which you can see an ascend with both losses displayed:

I must admit: I don't have an explanation for the differences right away. Since I looked into this (existing) mod I haven't reverse-engineered all of the calculations in it... I'm currently refactoring the whole code to separate data/logic/UI - so I will get to the losses in general at some point.

I'll then try to figure out what the difference between MJ and GT actually is. Probably both mod's loss calculations are correct, just they don't mean the same. But I can't tell at the moment.

[delta wee]

I'm using RSS + RealFuels to do realistic launches to Earth orbit. One problem I've run into is that the automated ascent program turns off the engine to coast to AP, but then it can't restart the engine because the propellants need to be settled first.

It would also be useful if we could specify the number of times an engine can be ignited during the ascent. In my case the second stage engine is a J2 with only two ignitions, so I want to get to orbit using only one ignition, and save the second ignition for a TLI burn.

[thunder175]

I noticed that the plugin generates files for each uniquely named launcher. However, if I have sequence numbers for my launches then each individual launch gets an individual named file with a single success or fail entry. Does that matter to the mod when it comes to refining launch setting estimates? If it does, would it be possible to add the ability to log an entire class of launchers instead? For example Sarnus *, instead of individual entries for Sarnus 1,2,3,4...

[AndyMt]

15 hours ago, thunder175 said:

I noticed that the plugin generates files for each uniquely named launcher. However, if I have sequence numbers for my launches then each individual launch gets an individual named file with a single success or fail entry. Does that matter to the mod when it comes to refining launch setting estimates? If it does, would it be possible to add the ability to log an entire class of launchers instead? For example Sarnus *, instead of individual entries for Sarnus 1,2,3,4...

Each craft has to go through it's own improvements in efficiency.

I actually plan something similar to what you suggest, have a look at the issue tracker, including the basic requirements:

https://github.com/AndyMt/GravityTurn/issues/17

I think that should allow you to select the proper launch settings for a class of crafts. I'm thinking about allowing to put the name of the launch configuration into the "description" field for a craft with some given syntax like "This craft uses launch configuration <<NameOfConfigFile>>" etc.

But I'm still reworking the entire source code, so don't expect anything to happen soon.

[JAFO]

16 hours ago, thunder175 said:

I noticed that the plugin generates files for each uniquely named launcher. However, if I have sequence numbers for my launches then each individual launch gets an individual named file with a single success or fail entry. Does that matter to the mod when it comes to refining launch setting estimates? If it does, would it be possible to add the ability to log an entire class of launchers instead? For example Sarnus *, instead of individual entries for Sarnus 1,2,3,4...

 

1 hour ago, AndyMt said:

Each craft has to go through it's own improvements in efficiency.

Absolutely each craft needs its own settings.. even apparently minor changes to a design can make a difference to what is the most efficient launch profile for that craft. Every time I make changes to a craft that I suspect will impact the launch profile, I add a character to the end of the name, to force GT to begin the calibration process again.. for instance, as a design progresses, there will be versions such as Mun Lander 2, Mun Lander 2A, Mun Lander 2B, and so forth.

[dbandy13]

I'm haven't seen that this has yet been suggested so sorry if someone already has, but is it possible to code this, perhaps as an option, to vary pitch rather than throttle late in the ascent? This would allow single burn to orbit launches and be more useable in RO/RealFuels. Would make it the ultimate in launch control mods if it was done

[AndyMt]

23 hours ago, dbandy13 said:

I'm haven't seen that this has yet been suggested so sorry if someone already has, but is it possible to code this, perhaps as an option, to vary pitch rather than throttle late in the ascent? This would allow single burn to orbit launches and be more useable in RO/RealFuels. Would make it the ultimate in launch control mods if it was done

Yes, RO/RSS compatibility has been suggested before and it is on my list of future features. But I have no idea when I have time for it.

[Jebs_SY]

@AndyMt
Thx for the mod!
I get some NRE's when pressing the button the first time. Any ideas on that? However, it's a highly modded install, tho.

Spoiler

170214T003221.583 [ERROR] [FXCurve.Load] FloatCurve: Invalid line. Requires two values, 'time' and 'value'
170214T003221.597 [ERROR] [FXCurve.Load] FloatCurve: Invalid line. Requires two values, 'time' and 'value'
170214T003234.032 [EXCEPTION] [GravityTurn.Window.GuiUtils.CopyCompactSkin] NullReferenceException: Object reference not set to an instance of an object
   at GravityTurn.Window.GuiUtils.CopyCompactSkin ()
   at GravityTurn.Window.GuiUtils.LoadSkin (SkinType skinType)
   at GravityTurn.Window.BaseWindow.drawGUI ()
   at GravityTurn.Window.WindowManager.DrawGuis ()
   at GravityTurn.GravityTurner.OnGUI ()
170214T003234.036 [EXCEPTION] [UnityEngine.GUILayoutGroup.GetNext] ArgumentException: Getting control 0's position in a group with only 0 controls when doing Repaint
Aborting
   at UnityEngine.GUILayoutGroup.GetNext ()
   at UnityEngine.GUILayoutUtility.BeginLayoutGroup (UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options, System.Type layoutType)
   at UnityEngine.GUILayout.BeginVertical (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options)
   at UnityEngine.GUILayout.BeginVertical (UnityEngine.GUILayoutOption[] options)
   at GravityTurn.Window.MainWindow.WindowGUI (Int32 windowID)
   at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID)
   at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)
170214T003234.090 [EXCEPTION] [UnityEngine.GUILayoutGroup.GetNext] ArgumentException: Getting control 0's position in a group with only 0 controls when doing Repaint
Aborting
   at UnityEngine.GUILayoutGroup.GetNext ()
   at UnityEngine.GUILayoutUtility.BeginLayoutGroup (UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options, System.Type layoutType)
   at UnityEngine.GUILayout.BeginVertical (UnityEngine.GUIContent content, UnityEngine.GUIStyle style, UnityEngine.GUILayoutOption[] options)
   at UnityEngine.GUILayout.BeginVertical (UnityEngine.GUILayoutOption[] options)
   at GravityTurn.Window.StatsWindow.WindowGUI (Int32 windowID)
   at UnityEngine.GUILayout+LayoutedWindow.DoWindow (Int32 windowID)
   at UnityEngine.GUI.CallWindowDelegate (UnityEngine.WindowFunction func, Int32 id, UnityEngine.GUISkin _skin, Int32 forceRect, Single width, Single height, UnityEngine.GUIStyle style)
170214T004207.968 [ERROR] [Experience.ExperienceTrait.AddEffect] ExperienceTrait: Cannot add effect 'ExConstructionSkill' as it does not exist.

BTW, would love to have a "first guess" button even if there's already a "improve guess" button. To get back to the first initial values.
I need to check how the save button works, too.

[ColKlonk2]

Admittedly I haven't done a comprehensive trial but wondered if you have facility to place a degree rotation/height rate.

With RSS where one has no re-ignitons and little throttling, a method by forced 1 degree per 1000m rotation, leveling off a 90Km and then pumping for orbit works pretty efficiently.

The method follows 'gravity turn' fairly closely but after 50km altitude the atmospheric parameters change somewhat and air resistance is negligible, so further rotation to 90 degrees incurs little gravity and drag losses with big gains in orbital speed. This naturally depends on payloads and orbits but the ballpark is close enough.

Here's a manual test flight .. I have a KOS program to do this automatically

Recorded at 6 fps, accelerated to 24fps.

https://youtu.be/nKQJ7YumqDM

 

Edited February 14, 2017 by ColKlonk2

[StahnAileron]

In the case of sequential launches of the same launcher, would it plausible/possible to have an auto-rename function of the vessel once GTC turns itself off? It already keeps a history of launches, so I would think it could just append a number (or maybe whatever text the user types into a text field?) to the vessel name once the launch is "successful" (defined as reaching space, which is about when GTC turns itself off, IIRC). The numbering sequence would increment based on "successful" launches. (So if you revert often before hitting space, like during testing, you won't hit huge numbers later on.)

Stock "renames"/appends discarded/decoupled parts already. I wonder if that could be used to rename an existing vessel. (Granted, I'm sure that's different since decoupling is generating another vessel and undocking is just restoring a saved vessel name.)

This would make profiling a little more hands-off if the player wants AND it helps make "unique" names for vessels of the same class if a player forgets to rename a vessel in the editor/right before launch.

Again, dunno if any of this is possible since I'm not sure how KSP handles vessel renaming and if mods have access to functionality.

Also, for saving/loading custom launch profiles, would it be possible to add an option of NOT saving a launch to history for future tweaking and/or an option to save to a different (new) profile than the one that was loaded? Reasons:

1. Do Not Save: I could be using a known profile that works well enough for a one-off launch, but that launch could adversely affect future launches using that profile. (Think using a launcher out of spec for just one thing because you don't feel like making a dedicated launcher for it.)
2. Save to New: I have a new line of dedicated launchers and want to use another profile as a starting point because the design is similar (or an improved version.)

Edited February 15, 2017 by StahnAileron
Another request/suggestion.

[StahnAileron]

@AndyMt Any chance of adding a throttle control option to this mod that a player can use after a manual launch? I have a shuttle design and notice GravityTurn's autopilot didn't handle it all that well on initial launch. (I'm guessing the offset thrust was throwing the autopilot for a loop.) I can manually launch the shuttle fine using GravityTurn-like procedures (i.e. a gravity turn via throttle control rather than direct heading changes and maintaining a particular Time-to-Apoapsis.) GTc as it is now is all or nothing at launch and can't be engaged mid-flight.

I just want something to control the throttle for me during ascent that I can toggle. It could be as simple as "maintain current time to apoapsis". No regard for target Apoapsis, auto-circularization, piloting, etc. I just want something to control the throttle so I don't need to tap the throttle controls all the time. If not, I can live with it. I don't use GTc as much as I thought I would since I know the basic procedure it uses. (I prefer the throttle-control method over MJ's brute-force method, though you do need something like KER's Time-to-Apo read out unless one is comfortable playing in map mode and chasing the Apo point around with the mouse...)

[FirroSeranel]

On 1/4/2017 at 3:42 PM, Jebs_SY said:

Is anyone here who is familiar with the different kind of dV-losses?

The losses are different for mechjeb and GTC, right?

The MJ-losses are mostely clear for me:
M1) Drag loss - loss caused by aerodynamic pressure
M2) Gravitly loss - loss that is caused by preveting to fall back to earth while not in orbit
M3) Steering loss - loss caused by a engine not thrusting prograde (or retrograde, depending how one wants to define it)

Now in GT we have the following losses:
GT1) Air drag loss - same as MJ-Drag-loss
GT2) Gravity drag loss -  (=MJ-Gravity-loss?)(*)
GT3) Total vector loss -  (=MJ-Steering-loss?)(*)

And Total loss wich is the addition of all the losses. 

Now the point is, when launching a rocket that flies prograde straight up, M2 raises fast and M3 stays almost at 0 which makes sense for my understanding.

However at the same time GT3 is rising fast and GT2 is not rising as fast as M2. So the (*) assumptions are not met.

It seems like GTC is calculating the losses different. So I wonder if GT3 is the amount of loss cause by not burning in the horizontal direction. But that's just an idea. Maybe wrong.

Does anybody know how GT2 and GT3 are defined?

I made a video in which you can see an ascend with both losses displayed:

 

 

 

 

I know this is pretty late, but my educated guess is this...

M1 = GT1

M2 = GT2 + GT3 - M3

M3 has no equivalent in GTC.

If I'm correct, the way Gravity Turn is calculating it works like this:

Gravity Drag is the extent to which you're fighting directly against gravity. In other words, it's the component of the unit vector of gravity (9.81 m/s/s) transformed along the actual vector of flight. Hence it never goes above 1G on Kerbin.

Vector Drag is the additional extent to which your engines' thrust is misaligned with an ideal vacuum launch profile (a small hop upward to avoid terrain, and then thrusting parallel to the planet's idealized surface all the way up to the desired orbit).

MechJeb's Steering Losses is, in contrary, the component of your engine's thrust lost to gimballing your engines to do something other than thrust along its velocity vector.

So basically... MechJeb tracks the total wasted energy spent doing something other than an idealized vacuum launch, and then separates out the gimballing losses (which if they get too high would tell you that you need more control authority, whether aerodynamic for atmospheric launches, or RCS for vacuum launches), which is... not really all that useful to know.

Gravity Turn's method (If I'm correct about what it's doing, at any rate) is actually more useful, IMO. Basically if your gravity drag loss is proportionally higher than expected, your craft is underpowered, and spending too much time "hovering" and very slowly accelerating upward off the launch pad. If aerodynamic drag losses are too high, you need more streamlining. If Vector losses are high, you have an inefficient launch trajectory and need to let Gravity Turn iterate a couple of times to get it more efficient, if it's a big deal to you. (Moar Fuel and Moar Boosters makes that degree of efficiency fairly negligible in the stock scale system, but would matter a -lot- in RSS) Another possible cause of a very high vector loss, I suspect, would be having your CoL too far behind CoM, which would mean the rocket is more prone to pitching over and crashing back down to the ground, thus GTC must take a higher launch trajectory (which is less efficient).

It's also essential to do it that way, because Vector Drag is the exact variable Gravity Turn is primarily trying to minimize.

Just my theory anyway, based on what I see with the numbers, some educated intuition, and never having looked at the code at all.

 

Edited March 11, 2017 by FirroSeranel

[FirroSeranel]

Anyway, the real reason I came here is to ask about how GTC deals with Procedural Fairings. It doesn't seem to recognize them as fairings (not its fault probably; they use normal decoupler icons and code as far as I can tell, rather than "deploy fairing" logic). So it either gets rid of them immediately, or else waits until it needs the next engine stage, and stages several times in a row. I'd love to be able to have it stage them when the dynamic pressure reaches a certain point, like normal fairings, but I'm not sure how doable that is.

[DStaal]

Another source of vector and aerodynamic losses are underpowered upper stages: The rocket will have to pitch up to maintain it's climb rate, resulting in a less efficient profile.

[FirroSeranel]

12 minutes ago, DStaal said:

Another source of vector and aerodynamic losses are underpowered upper stages: The rocket will have to pitch up to maintain it's climb rate, resulting in a less efficient profile.

Good point, DStaal. However, if the upper stage is efficient enough in terms of Isp (nuclear engines, for example), I find it's often worth a little vector loss compared to the extra weight of an intermediate stage (or larger launch stage). You do need your insertion stage to be capable of around 5 m/s/s though, or it may fail to make orbit unless you go for a very high Ap. If it isn't, like if you're using electric engines, you'll need a separate insertion stage that you'll just sacrifice as orbital debris (or include a control core and a little extra fuel to fly it back down with, assuming you're using StageRecovery).

Again, though, in the stock system I find if you design a reasonably optimized rocket, and let GravityTurn do its first guess, it's good enough. Yes, if you spent another hour or so optimizing and iterating, you could get more efficient, but you're probably only talking saving a couple of dozen m/s of dV in most cases. GravityTurn is much, much more efficient than MechJeb, and more consistently efficient than a skilled manual launch, in my experience.

[DStaal]

I tend to do a three-stage to orbit, with the last stage emptying out just at insertion, so I notice it more.    I find you want at the very minimum a TWR of ~1.2 through around 40k off of Kerbin.  Past that you can often get by with less, depending on the exact launch profile you've achieved.  But underpowering the third stage is my biggest cause of launch failures: Just a bit to low, and GT can't keep the apoapsis up, and I burn through all the fuel that was supposed to get me to orbit, leaving me with only my vacuum engines trying to get through the last 15k of atmosphere.

This can even be triggered by an extreme differences between the TWR of the lower launch stages and the upper launch stages: GT will aim a more shallow trajectory if it notices you have the power to do so, and if you then shed that engine for something with a significantly lower TWR, that shallow trajectory may no longer be workable.

[FirroSeranel]

For Kerbin-system operations, I tend to do an overpowered (2-3 TWR for manned, or as much as I can get with an egg-shaped fairing for unmanned, usually around 4-6 TWR) first stage with about 2800 m/s (so it releases just slow enough not to burn up with just parachutes and no probe core, but does get my Ap up above 70k before I stage), then an insertion/mission burn stage combined with around .8 to 1.5 TWR, that gets me to the Mun or Minmus, and usually has just enough fuel to circularlize (or sometimes I need a few dozen m/s from my lander stage for circularization. Then I do a separate lander with an Apollo-style return craft that leaves landing legs and some fuel tanks behind, and/or the hangar I used to bring a rover.

Of course that's for small payloads... scanning or communication sats, small landing parties or rovers, etc. For big stuff like space stations of course I do more stages, and just eat some of the cost. By the time I'm going interplanetary, I have enough money not to mind the extra cost of multi-stage craft. For me though, a 3-stage launch vehicle is a lot of wasted money and weight on extra engines, when one more versatile engine will do most of the time.

Edited March 11, 2017 by FirroSeranel