[WIN/MAC/LINUX] KSP Trajectory Optimization Tool v1.6.10 [Major LVD Improvements!]

[Drew Kerman]

4 minutes ago, Arrowstar said:

just haven't gotten around to all the awful UI work that they'll require

?? You're talking about the pitch constraint? I'm not sure what you mean - and I'm only asking because I'd like to make sure we're conceptualizing the same thing here. There shouldn't need to be any UI change, just add pitch to the list of optimizer constraint options, I set the min/max and all that using the current constraint dialog and it's good to go? Like, the ascent profile I linked to earlier has 4 pitch events (Tower Clear, and then the obvious three marked by altitude) - to get the proper pitch rates to hit the angles I wanted I had to go back and forth several time between events tweaking the linear change. But with a pitch constraint the optimizer should be able to do that instead right?

[Arrowstar]

1 minute ago, Drew Kerman said:

?? You're talking about the pitch constraint? I'm not sure what you mean - and I'm only asking because I'd like to make sure we're conceptualizing the same thing here. There shouldn't need to be any UI change, just add pitch to the list of optimizer constraint options, I set the min/max and all that using the current constraint dialog and it's good to go? Like, the ascent profile I linked to earlier has 4 pitch events (Tower Clear, and then the obvious three marked by altitude) - to get the proper pitch rates to hit the angles I wanted I had to go back and forth several time between events tweaking the linear change. But with a pitch constraint the optimizer should be able to do that instead right?

Oh yeah, it's just that constraint UI.  Right now it's set up under the hood to handle only the constraints that are present in Mission Architect.  Those have a different data structure than the constraints in LVD, and there's a bridging data structure I use so that I can call MA constraints directly in LVD.  But when I create new constraints that are LVD-specific, I'll need to probably copy that UI and have it handle the new constraint data type.  It's probably not that awful, and I'm just being dramatic, but it's the one part of it that's really a hassle.  The rest of the work is very straight forward.

[Drew Kerman]

oh, ok - that makes sense. Not only is there the potential of extra work but... copy paste *shudders*

[Arrowstar]

Hey everyone,

I'm happy to share tonight the 3rd pre-release of KSPTOT v1.6.1.  The change log for this pre-release is fairly extensive!  All changes are within Launch Vehicle Designer.

• Added constraints for all steering angles and throttle.
• Added "non-sequential events", which are events which can execute at any point during the mission (between specified script events).  Useful for changing pitch profile rate at specified altitudes, jettisoning stages when tanks are empty, and the like.
• Added a throttle model which will hold the vehicle at a specified thrust to weight ratio.
• Added an option to set the output step size for each event.
• Some optimization performance enhancements.
• A few bug fixes here and there.

Happy orbiting.

[Drew Kerman]

launch has been flown. I will PM you an analysis hopefully this weekend. Then I will see if I can also play with LVD for my next launch

[Arrowstar]

14 minutes ago, Drew Kerman said:

launch has been flown. I will PM you an analysis hopefully this weekend. Then I will see if I can also play with LVD for my next launch

Sounds good.  By the way, if you have already downloaded the pre-release, please go ahead and redownload.  I found a bug that I needed to correct.

[IronDuke]

:O this looks amazing! I have a couple mod-support questions  Is this compatible with FAR, Realistic Rescale, kOS, and OPM? Also, I'm using Kerbalism for life support; is there a way to know how long supplies of food, water, oxygen, blah blah will last? (also things like radiation and energy)

Nice job on this!

[Arrowstar]

5 hours ago, IronDuke said:

:O this looks amazing! I have a couple mod-support questions  Is this compatible with FAR, Realistic Rescale, kOS, and OPM? Also, I'm using Kerbalism for life support; is there a way to know how long supplies of food, water, oxygen, blah blah will last? (also things like radiation and energy)

Nice job on this!

Thanks! I'm glad you like it.

Regarding mods (and assuming you're just referring to Launch Vehicle Designer):

FAR: Yes, essentially. You'll just need to update your drag coefficient at regular intervals during ascent.

Realistic Rescale and OPM: yes, just create a new bodies.ini file using the KSPTOTconnect plugin.  See the OP for instructions. 

KOS: not directly, but there are ways to get the attitude out of LVD using the Graphical Analysis tool, so you can pull those profiles and then make kOS execute them.

Regarding the consumption of consumables other than propellant: yes but not directly.  You can create a tank for say oxygen, and then create an engine (call it oxygen consumer) connected to that tank.  Set the thrust very very low (1E-20) and then determine the mass flow rate out of the tank you want.  Then solve for Isp:

T=mdot*g0*Isp

Isp=T/(mdot*g0)

Plug in the very low thrust and this Isp into the engine profile (both sea level and vacuum spots) and make sure the engine state is active. This will model mass flow from the oxygen tank like in KSP.  

Late know if you need help with this.

[IronDuke]

Oh wow, that's a clever method to model consumables.

Thank you for the reply  I shall be trying out this mod soon(tm). This is finals week so I am very much of a busy boy at the moment XD but being able to fully plan out a launch ahead of time, enter the parameters into kOS, and sit back and watch a perfectly executed, maximally efficient launch? *drools*

[Drew Kerman]

10 hours ago, IronDuke said:

:O this looks amazing! I have a couple mod-support questions  Is this compatible with FAR, Realistic Rescale, kOS, and OPM? Also, I'm using Kerbalism for life support; is there a way to know how long supplies of food, water, oxygen, blah blah will last? (also things like radiation and energy)

Nice job on this!

Read the docs for Kerbalism. It has all the tools you need to plan out life support properly in the vab/sph

[Drew Kerman]

On 12/7/2018 at 8:03 PM, Arrowstar said:

Added an option to set the output step size for each event.

So this is an interesting implementation, allowing for fine control over how you can output data - I was just expecting this to be an option added to the GA window itself. The only downside is that this doesn't also allow me to control step size in Mission Architect? Well, I guess there is still the indirect method of properly dividing up the script log entries per coast but to be honest that always seemed a bit hackish to me

[Drew Kerman]

also I just tried setting all the events in my LVD plan to 1s and ran the GA for a UT period of 74604180.0 to 74604284.54761, which is 104.5s and it said - Okay! Outputting 0-123 values. Wait what? I ran Excel's Remove Dupes tool and it still left me with 112 entries. Hmmmmmmmmm

[Arrowstar]

24 minutes ago, Drew Kerman said:

So this is an interesting implementation, allowing for fine control over how you can output data - I was just expecting this to be an option added to the GA window itself. The only downside is that this doesn't also allow me to control step size in Mission Architect? Well, I guess there is still the indirect method of properly dividing up the script log entries per coast but to be honest that always seemed a bit hackish to me

Regarding LVD: it's set up this way because the integrator function is far, far better at interpolating between data points to get the user set output than any interpolation scheme I could come up with after the fact in Graphical Analysis.  The data output is just better from the integrator, which is why I'm having it do the interpolation.

Regarding MA: Yeah, the whole "number of data points per coast" thing is a bit hack-ish, I'll agree.  The reason it's set up like that is because of the way the two body orbit propagation math is set up.  It was the most straight forward way to do it at the time, but if there's interest, I could always look at trying to change that to a "number of data points per second" sort of thing.

2 minutes ago, Drew Kerman said:

also I just tried setting all the events in my LVD plan to 1s and ran the GA for a UT period of 74604180.0 to 74604284.54761, which is 104.5s and it said - Okay! Outputting 0-123 values. Wait what? I ran Excel's Remove Dupes tool and it still left me with 112 entries. Hmmmmmmmmm

Can I see the MAT file?  Most likely there are some event action-generated state log entries in there.  Also, the final event of one event becomes the initial event of the next event (with a different event label internally) so that you and the software can see where the event transition took place.  That's probably the rest of them.

[Drew Kerman]

2 minutes ago, Arrowstar said:

but if there's interest, I could always look at trying to change that to a "number of data points per second" sort of thing

yea I would agree only worth doing if more people ask for it - because they probably won't figure out the coast event steps thing on their own and having it in the GA like that is just more intuitive from a UX standpoint. The current way does work, just is a bit of a hidden feature

[Drew Kerman]

19 minutes ago, Drew Kerman said:

also I just tried setting all the events in my LVD plan to 1s and ran the GA for a UT period of 74604180.0 to 74604284.54761, which is 104.5s and it said - Okay! Outputting 0-123 values. Wait what? I ran Excel's Remove Dupes tool and it still left me with 112 entries. Hmmmmmmmmm

Oh, I see what is happening. These "blips" of extra data are at the boundary between events. Side-effect of the per-event step size I guess. Some of these skips are larger than a second so I'm just interpolating some of my own data to fill in the gap

[Arrowstar]

Just now, Drew Kerman said:

Oh, I see what is happening. These "blips" of extra data are at the boundary between events. Side-effect of the per-event step size I guess. Some of these skips are larger than a second so I'm just interpolating some of my own data to fill in the gap

Not so much a side effect of the per event step size as it is the way I have to do things.  Each event has to start from the place where the previous event ended, regardless of how many data points are included between events.

[Drew Kerman]

Got a few UX tweak suggestions for LVD:

• Ship overview box in the Edit Launch Vehicle doesn't scroll with the mouse wheel
• Can double-clicking on a selection in the Initial Launch Vehicle Stage States toggle the check box?

Also, found a bug. LVD file, log file & rocket image. Just try to add a new sequential event for 3 seconds duration, no actions needed.

And just to make sure I'm going about this right - I have the SRBs set to various max throttles. The radial boosters are capped at 83.5% and the core booster is 46%. So if I set the throttle model to 100% this means the four lower boosters will fire at their max 83.5% and 46% correct? And the large lower booster set to 46% has a thrust curve, so I can use the Tank Mass event termination to say when it's down to 75.4% of capacity I would change the throttle model to back off to match this curve:

    thrustCurve {
      key = 1 0.46
      key = 0.754 0.46
      key = 0 0.1
    }

I have telemetry data from a previous launch I can use to set the linear throttle decay

[Arrowstar]

12 hours ago, Drew Kerman said:

Got a few UX tweak suggestions for LVD:

• Ship overview box in the Edit Launch Vehicle doesn't scroll with the mouse wheel
• Can double-clicking on a selection in the Initial Launch Vehicle Stage States toggle the check box?

Also, found a bug. LVD file, log file & rocket image. Just try to add a new sequential event for 3 seconds duration, no actions needed.

And just to make sure I'm going about this right - I have the SRBs set to various max throttles. The radial boosters are capped at 83.5% and the core booster is 46%. So if I set the throttle model to 100% this means the four lower boosters will fire at their max 83.5% and 46% correct? And the large lower booster set to 46% has a thrust curve, so I can use the Tank Mass event termination to say when it's down to 75.4% of capacity I would change the throttle model to back off to match this curve:

    thrustCurve {
      key = 1 0.46
      key = 0.754 0.46
      key = 0 0.1
    }

I have telemetry data from a previous launch I can use to set the linear throttle decay

1. UI Tweaks: noted for next release.  Thanks!
2. Bug: In my 10+ years of using MATLAB I have literally never encountered this error.  Luckily fixing it was easy after some Googling, but even in my own MAT files I've never seen it before now.  Good find I guess lol!
3. SRBs and thrust curve: yes, that sounds right about the behavior of the throttle for the SRBs with the max throttle setting.  However, note that the max throttle setting is universal (no way to change it at the moment, though I could add that), so if you adjust the throttle model, you still won't be adjusting the max throttle setting.  If that's okay, then you're all set.

[Drew Kerman]

14 minutes ago, Arrowstar said:

Bug: In my 10+ years of using MATLAB I have literally never encountered this error.  Luckily fixing it was easy after some Googling, but even in my own MAT files I've never seen it before now.  Good find I guess lol! 

as usual, I excel at breaking things But everything I was doing was correct right?

14 minutes ago, Arrowstar said:

However, note that the max throttle setting is universal (no way to change it at the moment, though I could add that), so if you adjust the throttle model, you still won't be adjusting the max throttle setting.  If that's okay, then you're all set. 

All set then! Look forward to the next release so I can continue the ascent design. In the meantime I have enough to keep me busy on the kOS side as I rework my flight computer to handle persistent state between the kOS power being turned off then on or the craft being reloaded after switching to another vessel or coming from the tracking station while in flight

Edited December 14, 2018 by Drew Kerman

[Arrowstar]

5 hours ago, Drew Kerman said:

as usual, I excel at breaking things

All set then! Look forward to the next release so I can continue the ascent design. In the meantime I have enough to keep me busy on the kOS side as I rework my flight computer to handle persistent state between the kOS power being turned off then on or the craft being reloaded after switching to another vessel or coming from the tracking station while in flight

Is there anything you're needing in the next release to continue working?

[Drew Kerman]

10 minutes ago, Arrowstar said:

Is there anything you're needing in the next release to continue working?

well that bug seemed like a showstopper to me. The whole simulation just locked up and never resolved to the state I was trying to progress towards. Did you see something different? Crap I just realized I never described the actual problem I was seeing

Edited December 15, 2018 by Drew Kerman

[Drew Kerman]

also while this issue has kept me from playing around further with LVD for my next launch, I also don't need LVD to actually plan the launch - it's a ballistic sounding rocket and I'm just going to be firing it off and seeing where it goes. But I will also want to model it in LVD for comparison sake.

[KonohanaSakuya]

Hi, so, I'm getting used to this tool still, and while I'm excited to see what kind of whacked out trajectories I can put together for efficient OPM transfers, I'm kind of banging my head against the wall here planning my basic self-tutorial mission that involves a Kerbin-centric Mun-Minmus transfer. The issue specifically is with the Mun ejection burn that would set my trajectory to intersect Minmus's SOI. I really hope I'm not cluttering up this thread too much by my probable PEBKAC here.

Other than importing an existing LKO satellite's orbit as a representative parking orbit, and giving it dummy dry mass/fuel values for the purposes of purely focusing on mission architecture (to be later replaced with actual values of the resultant spacecraft design) I proceeded to calculate the intercept burn from my initial orbit to the Mun, and using the optimizer and setting some constraints I arrived at a position to circularize at a good low orbit. Some more constraints were added to make the orbit more ejection-friendly, after that. I added a 24h coast around the mun to account for the lander's descent, surface ops, and ascent/rendezvous.

I then take the UT after this 24h coast (to rule out any windows opening during surface operations) as the earliest possible departure time, and then I plug in the same number for the earliest possible arrival time. I then compute the porkchop plot. The resulting graph looked reasonable, and I first tried the lowest ΔV, but then also tried a longer and shorter transit time, just in case. The maneuver looked good on the departure info window, but things fell apart when I tried to enter the departure burn into MA. My steps were as such:

1. Note the departure UT from the info window, under the Kerbin-Centric Transfer Orbit pane. On top of the 24h coast (using coast to delta time), I added another coast to go to this departure UT. I convert it to true anomaly after that, and already the angle is wrong. This angle is wrong both using and not using the Munar orbit's mean anomaly and epoch.
2. Copy the departure's burn params individually, prograde to prograde, normal to normal, radial to radial.
3. I then add another coast to the specified arrival UT. I find out this ejection burn has put me on an escape trajectory to heliocentric orbit at worst, and a useless elliptical orbit at best.

Even when I manually adjust the settings, setting the ejection anomaly angle manually via the coast to ejection and fiddling with the revolutions, I still end up with useless trajectories. The only way that I had any success with was to just copy the total ΔV from the porkchop plot and make a purely prograde burn at the specified true anomaly.

What am I missing here? Any help would be infinitely appreciated!

Edited December 18, 2018 by KonohanaSakuya
typo, d'oh.

[Arrowstar]

Hi everyone,

Tonight I have prepared the 4th pre-release of KSPTOT v1.6.1.  This release is LVD-focused and addresses a few bugs and adds a few neat features I have been spinning around in my head for a bit now.

• Adds "stopwatches" to LVD.  These are timing devices that can be turned on and off.  They will tick upwards when on and not tick when off.  Useful for measuring the duration between two non-consecutive events.
• Added ability to add/subtract mass to a tank as an event action.
• The LVD Graphical Analysis tool now has the ability to show the mass of an individual tank, the status of stages and engines, and stage dry mass.
• Fixed the "UI" tweaks that @Drew Kerman mentioned a few days ago.
• Some other bug fixes, including everything that's been reported to date.

The next thing I'm working on is attempting to incorporate a new, potentially faster integrator into LVD for the purposes of speeding up the simulation.  In any event, at this rate, v1.6.1 will not drop until after the New Year, so I'm happy to get out this pre-release before then.

 

Please let me know what bugs you find or issues you uncover.  Happy orbiting.

1 hour ago, KonohanaSakuya said:

Hi, so, I'm getting used to this tool still, and while I'm excited to see what kind of whacked out trajectories I can put together for efficient OPM transfers, I'm kind of banging my head against the wall here planning my basic self-tutorial mission that involves a Kerbin-centric Mun-Minmus transfer. The issue specifically is with the Mun ejection burn that would set my trajectory to intersect Minmus's SOI. I really hope I'm not cluttering up this thread too much by my probable PEBKAC here.

Other than importing an existing LKO satellite's orbit as a representative parking orbit, and giving it dummy dry mass/fuel values for the purposes of purely focusing on mission architecture (to be later replaced with actual values of the resultant spacecraft design) I proceeded to calculate the intercept burn from my initial orbit to the Mun, and using the optimizer and setting some constraints I arrived at a position to circularize at a good low orbit. Some more constraints were added to make the orbit more ejection-friendly, after that. I added a 24h coast around the mun to account for the lander's descent, surface ops, and ascent/rendezvous.

I then take the UT after this 24h coast (to rule out any windows opening during surface operations) as the earliest possible departure time, and then I plug in the same number for the earliest possible arrival time. I then compute the porkchop plot. The resulting graph looked reasonable, and I first tried the lowest ΔV, but then also tried a longer and shorter transit time, just in case. The maneuver looked good on the departure info window, but things fell apart when I tried to enter the departure burn into MA. My steps were as such:

1. Note the departure UT from the info window, under the Kerbin-Centric Transfer Orbit pane. On top of the 24h coast (using coast to delta time), I added another coast to go to this departure UT. I convert it to true anomaly after that, and already the angle is wrong. This angle is wrong both using and not using the Munar orbit's mean anomaly and epoch.
2. Copy the departure's burn params individually, prograde to prograde, normal to normal, radial to radial.
3. I then add another coast to the specified arrival UT. I find out this ejection burn has put me on an escape trajectory to heliocentric orbit at worst, and a useless elliptical orbit at best.

Even when I manually adjust the settings, setting the ejection anomaly angle manually via the coast to ejection and fiddling with the revolutions, I still end up with useless trajectories. The only way that I had any success with was to just copy the total ΔV from the porkchop plot and make a purely prograde burn at the specified true anomaly.

What am I missing here? Any help would be infinitely appreciated!

Can I see you MA .mat file?  That would help me address your issue.  Btw, keep working at it: I will be pretty busy today and tomorrow but hopefully I can take a look Thursday.

[KonohanaSakuya]

Sure thing, thank you! Sorry for taking a bit to get back. I'll include the bodies.ini file too, in case you don't have a copy for OPM, for the sake of reproducing it if somehow not just a run-of-the-mill ID-10 T error. My intuition is telling me that there's some operator error going with the translation from the burn params in the departure planner to inserting it into MA, or something like that.

.mat file:  Mun-Minus_Test.mat

OPM bodies file: bodies.ini