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

[genericeventhandler]

7 hours ago, FirroSeranel said:

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.

Use smartparts and ditch them at a set altitude. Is the way I do it. I love smartparts my current goal is a completely automated duna rover that only turns on its radio once it is on the ground. Jettisons fairings, heat shields, retro rockets all at height settings. The only manual part of the mission is setting manoeuvre nodes.

[PanzerAce]

Question for those that use this: How well does it deal with Solid rocket only designs? I tend to use them for a long time because of the cheapness....

[FirroSeranel]

1 hour ago, PanzerAce said:

Question for those that use this: How well does it deal with Solid rocket only designs? I tend to use them for a long time because of the cheapness....

It can fly designs with solid rockets just fine (provided adequate control authority; most solid rockets don't gimbal). It gets a lot of its launch efficiency, however, using throttle, so it won't be nearly as efficient with pure solid rocket designs. I -think- it might still beat MechJeb's ascent guidance, but that's just a guess based on how the two tend to fly, I can't back it up with any evidence.

[PanzerAce]

Hmmmm. Not well is the answer actually for how well it does pure-solid setups. Lack of thrust gimbaling and lack of throttle hurts it. Might be worth still looking at for hybrid setups with short duration, lofting only solid stages, but for pure solid setups, a simple ballistic/aerodynamic approach is still the best.

 

I will say it's impressive how well it optimizes, to the point that I might start building more pure liquid fuel setups with minimal boosters, rather than my old, sold booster heavy setups.. Tried it with just loading up the stock Kerbal X ship, and without tweaking anything It resulted in an extra ~130 units of oxidizer in the tank on the 2nd, and then an additional ~100 on the 3rd go around. 2nd and 3rd launches would have used ~55m/s to circularize. First would have used ~70. I did notice that on the 4th try it actually stayed in the atmosphere too long, resulting in worse efficiency to orbit. For those that use it a ton, is that something where it'll start zeroing in on the most optimal, or does it tend to get worse overall after the 3rd/4th depending on rocket design?

[kendov]

For reasons unknown, the rocket simply goes prograde, attempts a tiny bit of gravity turn until it reaches target altitude for apoapsis while the periapsis is still at ~ -600km. help? 

[DStaal]

On 3/12/2017 at 5:58 AM, PanzerAce said:

I will say it's impressive how well it optimizes, to the point that I might start building more pure liquid fuel setups with minimal boosters, rather than my old, sold booster heavy setups.. Tried it with just loading up the stock Kerbal X ship, and without tweaking anything It resulted in an extra ~130 units of oxidizer in the tank on the 2nd, and then an additional ~100 on the 3rd go around. 2nd and 3rd launches would have used ~55m/s to circularize. First would have used ~70. I did notice that on the 4th try it actually stayed in the atmosphere too long, resulting in worse efficiency to orbit. For those that use it a ton, is that something where it'll start zeroing in on the most optimal, or does it tend to get worse overall after the 3rd/4th depending on rocket design?

It tries to zero in - but it's making guesses, so it has to get it wrong a few times along the way.

33 minutes ago, kendov said:

For reasons unknown, the rocket simply goes prograde, attempts a tiny bit of gravity turn until it reaches target altitude for apoapsis while the periapsis is still at ~ -600km. help? 

Can you show a pic of the rocket on the launchpad?  Preferably with KER or something showing TWR - my guess is that you've got either a lot of solid rockets and a high TWP (no throttle control, so it reaches the set apoapsis very early) or an extremely low TWR.  (Not enough thrust to actually preform a gravity turn.)

[kendov]

No SRB's, Plenty of TWR, steering goes quite well, but it doesn't even attempt a proper turn (I kept an eye on the pitch/yaw). I seriously have no idea what's the problem

[DStaal]

9 minutes ago, kendov said:

No SRB's, Plenty of TWR, steering goes quite well, but it doesn't even attempt a proper turn (I kept an eye on the pitch/yaw). I seriously have no idea what's the problem

I'd be interested in knowing what the TWR is after the first ~40s of flight, when you drop those four booster engines...

Anyway, try setting the start m/s to 100 and seeing if that helps.  (I'm thinking you actually have a very low TWR, once you get to just your main stage.)

[kendov]

20 minutes ago, DStaal said:

I'd be interested in knowing what the TWR is after the first ~40s of flight, when you drop those four booster engines...

Anyway, try setting the start m/s to 100 and seeing if that helps.  (I'm thinking you actually have a very low TWR, once you get to just your main stage.)

even after leaving behind the boosters it's at 1.27, rising up to over 2 before passing 40k alt. it can do it, tried it manually, but I just wonder why the program doesn't do it the way it should.

this time, it went into horizontal flight at 46km with 2382m/s-> apo 100k. what the hell?

Edited March 29, 2017 by kendov

[DStaal]

16 minutes ago, kendov said:

even after leaving behind the boosters it's at 1.27, rising up to over 2 before passing 40k alt. it can do it, tried it manually, but I just wonder why the program doesn't do it the way it should.

this time, it went into horizontal flight at 46km with 2382m/s-> apo 100k. what the hell?

1.27 isn't a very high TWR for a gravity turn.  It's enough, but just barely.  And you did tell it to go to an apo of 100k - that's not the default destination height.   Also, you've played with the Hold AP Time values - sorry I didn't notice that in the previous screenshot.  That alone can be causing your issues.  (You're telling it to climb *steeper* as you climb higher.)

[genericeventhandler]

17 hours ago, DStaal said:

1.27 isn't a very high TWR for a gravity turn.  It's enough, but just barely.  And you did tell it to go to an apo of 100k - that's not the default destination height.   Also, you've played with the Hold AP Time values - sorry I didn't notice that in the previous screenshot.  That alone can be causing your issues.  (You're telling it to climb *steeper* as you climb higher.)

In the first image, the turn angle is 42! Could that be your problem?

[danielboro]

@kendov

as far as i can see in the pics and description you gave, GT is doing wat you are telling him to do.

the numbers i use for most of my lunches are

100
10
60
30 (or 20 if has more TWR)
0.1
80

[cakepie]

Getting back into the saddle after a very long time away from KSP and just picked this mod up. Very impressed with what it can do after trying it out with just one craft. I'm huge on Kessler prevention, so I like to design my craft to discard booster stages while suborbital, leaving the payload to make the last push into orbit by itself. On the fourth attempt, GT took the penultimate stage into orbit! I was ultimately able to offload 3.6lf/4.4ox, very pleased with the final result after resetting and redoing the optimization. Going to be tricky to hand-fly this thing now, though.

Having rooted around in the plugin data folder, I'd like to make the following observations/suggestions:

In launch DB files gt_launchdb_<craftname>_<body>.cfg, { APTimeStart, APTimeFinish, Sensitivity, Roll, PressureCutoff } params are present but GT doesn't actually record them -- always show as zero. Would be great if GT could properly log these params for human inspection even if not used for subsequent optimization. Target Inclination param is absent entirely, should also be included. Autostaging/fairing settings are also absent, but these are less important. In any case, these params are logged in the gt_vessel_<GUID>.cfg files that are created for each launch attempt, but the GUIDs are basically indistinguishable, so it'd be better if we could have the information consolidated all in one place.

Speaking of those per-launch gt_vessel_<GUID>.cfg files, are they used subsequently at all? If not, a bit of housekeeping to reduce file clutter would be nice.

Another minor annoyance is that the stats window fails to close using "x" button in top right corner -- the toggle in the main window stays checked, which opens it back up right away (at a quick glance, lines 157-167 of MainWindow.cs, I think). Compare to flight map window, which has the "normal" expected behavior. Is there any particular reason for this? Not a huge deal, just a bit weird to have to remember to use the toggle since the "x" doesn't work.

In any case, thanks for your work continuing with this mod! Filed under "must-have".

[AndyMt]

19 hours ago, cake>pie said:

Getting back into the saddle after a very long time away from KSP and just picked this mod up. Very impressed with what it can do after trying it out with just one craft. I'm huge on Kessler prevention, so I like to design my craft to discard booster stages while suborbital, leaving the payload to make the last push into orbit by itself. On the fourth attempt, GT took the penultimate stage into orbit! I was ultimately able to offload 3.6lf/4.4ox, very pleased with the final result after resetting and redoing the optimization. Going to be tricky to hand-fly this thing now, though.

Having rooted around in the plugin data folder, I'd like to make the following observations/suggestions:

In launch DB files gt_launchdb_<craftname>_<body>.cfg, { APTimeStart, APTimeFinish, Sensitivity, Roll, PressureCutoff } params are present but GT doesn't actually record them -- always show as zero. Would be great if GT could properly log these params for human inspection even if not used for subsequent optimization. Target Inclination param is absent entirely, should also be included. Autostaging/fairing settings are also absent, but these are less important. In any case, these params are logged in the gt_vessel_<GUID>.cfg files that are created for each launch attempt, but the GUIDs are basically indistinguishable, so it'd be better if we could have the information consolidated all in one place.

Speaking of those per-launch gt_vessel_<GUID>.cfg files, are they used subsequently at all? If not, a bit of housekeeping to reduce file clutter would be nice.

Another minor annoyance is that the stats window fails to close using "x" button in top right corner -- the toggle in the main window stays checked, which opens it back up right away (at a quick glance, lines 157-167 of MainWindow.cs, I think). Compare to flight map window, which has the "normal" expected behavior. Is there any particular reason for this? Not a huge deal, just a bit weird to have to remember to use the toggle since the "x" doesn't work.

In any case, thanks for your work continuing with this mod! Filed under "must-have".

The launch DB files actually only serve the purpose to find the best launch parameters for "start turn" and "angle". Some more fields might be saved because of shared code with the vessel files. I intended to clean this up with the next big release - which hasn't come far, unfortunately... I want to refactor the mod to separate data, logic and UI better than it is now.

The gt_vessel files are used - they contain the "locked" default values for a specific vessel. I also want to introduce a "named save.Cfg" feature, so you can save a set of parameters you can use for launching similar vessels.

The "x" on the stats window was actually a requested feature, so you can keep it open while the main GT window is closed. For that to work the hack was to fiddle with the close buttons. I don't recall exactly, but that's of course something I'd like to fix, too. Anyway as described a few pages further up I want to change the UI completely.

When I branched this mod I was very happy with what it did and just wanted it to work on the latest KSP release. But I also saw some things I'd like to improve and change, but that requires some major refactoring. Unfortunately I don't have the time for this right now (looking for a new job).

[thunder175]

A feature enhancement I'd like to see if possible would be an option to disable the circularization burn after reaching the programmed Ap. Alternatively, how about at least be able to set the coasting time before executing the next node? Very annoying that the craft immediately turns to the circularization burn node and burns up monopropellant if I am not quick enough to shut down the RCS or puts solar panels out of position or optimal charging.

Even more elegant solution and feature enhancement I'd like to see for RT users would be to automatically add the circularization burn node to the RemoteTech Flight Computer.

[Gordon Dry]

Could you please put a little bit more information into the help windows?

For example pressure cutoff ... 1200 what? What is the unit? I'm used to kPa ...
With that settings the drastic turn (no respect of AoA) happened at 34 km altitude.

And I guess the default settings are for stock KSP, not for RSS ...

I never never start a gravity turn at 100 m/s, I start at 300 m/s and at least at 5 km altitude.

 

Edit:

So it seems that the unit is Pa ! But I had to confirm it last session.

btw I had some NREs while using RCS as "Fore on throttle" for fine adjusting:

NullReferenceException: Object reference not set to an instance of an object
  at GravityTurn.VesselState.ToggleRCSThrust (.Vessel vessel) [0x00000] in <filename unknown>:0 
  at GravityTurn.VesselState.Update (.Vessel vessel) [0x00000] in <filename unknown>:0 
  at GravityTurn.GravityTurner.FixedUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Full log:
https://www.dropbox.com/s/t8k97ccicduc1fw/2017-05-22-1 KSP.log.zip?dl=1

Edited May 22, 2017 by Gordon Dry

[AndyMt]

15 hours ago, Gordon Dry said:

Could you please put a little bit more information into the help windows?

For example pressure cutoff ... 1200 what? What is the unit? I'm used to kPa ...
With that settings the drastic turn (no respect of AoA) happened at 34 km altitude.

And I guess the default settings are for stock KSP, not for RSS ...

I never never start a gravity turn at 100 m/s, I start at 300 m/s and at least at 5 km altitude.

 

Edit:

So it seems that the unit is Pa ! But I had to confirm it last session.

btw I had some NREs while using RCS as "Fore on throttle" for fine adjusting:

NullReferenceException: Object reference not set to an instance of an object
  at GravityTurn.VesselState.ToggleRCSThrust (.Vessel vessel) [0x00000] in <filename unknown>:0 
  at GravityTurn.VesselState.Update (.Vessel vessel) [0x00000] in <filename unknown>:0 
  at GravityTurn.GravityTurner.FixedUpdate () [0x00000] in <filename unknown>:0 
 
(Filename:  Line: -1)

Full log:
https://www.dropbox.com/s/t8k97ccicduc1fw/2017-05-22-1 KSP.log.zip?dl=1

Interesting exception... I have to check that.

Regarding default values: yes they are for stock, RSS you have to guestimate something yourself.

[AndyMt]

I've done a few tests with the new KSP version 1.3 - it seems GT still works properly, so no changes needed. Or has anyone experienced something different?

[razark]

8 minutes ago, AndyMt said:

I've done a few tests with the new KSP version 1.3 - it seems GT still works properly, so no changes needed. Or has anyone experienced something different?

I've been using it, and it seems fine.

[FrontLineFodder]

16 hours ago, AndyMt said:

I've done a few tests with the new KSP version 1.3 - it seems GT still works properly, so no changes needed. Or has anyone experienced something different?

Excellent,

 

I was giving it a week before I download 1.3, but it looks like most of the mods have updated.

Say YES to not having to manually do a gravity turn !

[AndyMt]

I still have to update the release files so CKAN will show it properly. But right now I down't have the time for it. So sorry, until then => install manually.

[todi]

On 30.5.2017 at 10:07 PM, AndyMt said:

I still have to update the release files so CKAN will show it properly. But right now I down't have the time for it. So sorry, until then => install manually.

I have taken the liberty to update the netkan file for you. I hope that was presumptuous of me.

[AndyMt]

11 hours ago, todi said:

I have taken the liberty to update the netkan file for you. I hope that was presumptuous of me.

Excellent! Thanks a lot!

[linuxgurugamer]

@todi

The CKAN update failed, can you please take a look at it

it was an error in a different netkan

@AndyMt

I'd suggest recompiling it for 1.3 anyway.  I've seen a few mod which work 98%, until a specific function is hit, and then it bombs.

At least do the compile and see if it compiles cleanly, if it does, then it's not too bad to leave.

Edited June 9, 2017 by linuxgurugamer

[AndyMt]

12 hours ago, linuxgurugamer said:

@todi

The CKAN update failed, can you please take a look at it

it was an error in a different netkan

@AndyMt

I'd suggest recompiling it for 1.3 anyway.  I've seen a few mod which work 98%, until a specific function is hit, and then it bombs.

At least do the compile and see if it compiles cleanly, if it does, then it's not too bad to leave.

I did a quick compile and no errors so far. It's just that the air drag values look a bit low now - or maybe I just don't remember what they usually look like...