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

[Arrowstar]

5 minutes ago, WarriorSabe said:

I don't think it responds well to two consecutive assists of the same planet, but the maneuver you got was definitely better than any of the ones I got. What settings did you use?

When you have two consecutive assists of the same planet, make sure to set the "max number of revolutions" on the leg from the first pass of the body to the second pass of the body to an integer greater than zero.  (Highlight the first instance of the body in the waypoint list.)  Usually 1 is fine, and don't go more than 2 or 3. 

The only other thing I did was set the launch window close to 283824000 and multiplied the default maximum flight time for each leg of the journey by 10.  That was it!

[Arrowstar]

On 10/14/2019 at 5:52 PM, Drew Kerman said:

Minor cosmetic issue that's hopefully an easy fix - selecting "Show Child Bodies" in the Mission Animator changes the illumination slightly for some reason (not really in a bad way just noticeable) and only seems to show half the child body, at least in the case of Mun which is the only time I've used it so far

Got it, I'll take a look.

Are you aware of any other issues that need to be resolved before I could release v1.6.4?  Otherwise I'm thinking it's about time to get it out the door properly.

[Drew Kerman]

3 hours ago, Arrowstar said:

Are you aware of any other issues that need to be resolved before I could release v1.6.4?  Otherwise I'm thinking it's about time to get it out the door properly.

what was the deal with the rotational period? I don't recall that being resolved

 

[Arrowstar]

18 hours ago, Drew Kerman said:

what was the deal with the rotational period? I don't recall that being resolved

 

Okay, I think I see what's going on.  I think there is confusion between the Solar Day and the Sidereal Day shown in the KSP wiki for Kerbin.  The sidereal day is the amount of time that Kerbin takes to rotate with respect to the fixed stars.  The solar day is how long it takes the sun to show up in the same place in the sky.  These are not the same: remember that Kerbin is orbiting, so the sun takes a bit longer each day to show up in the same place because the planet has to rotate just a bit more than 360 degrees to get the same in the same spot again.

The sidereal time is the proper time to use for the surface velocity calculation because it is measured against the fixed reference frame.  If you do:

>> (2*pi/21549.425) * 600

ans =

         0.174942541822241

You get the answer you see on the wiki, but that speed corresponds to the sidereal period and not the solar period.  In the MM config you shared, you had the 21651 seconds time... I'm guessing this is a solar day period?  (I would think it should be the sidereal day period, but I've never played with MM configs myself so I don't know.)  In any event, the diference between the 21651 and the 21600 AND the 21600 and 21549 (shown on the wiki) is both ~51 seconds, so I'm wondering if that's where the confusion is coming from.

In any event, I think KSPTOT is computing it correctly, as is kOS.  Double check that you are using the correct values in both LVD and the MM config, and that you know which type of rotational period goes in each.  In KSPTOT's bodies.ini file, those are sidereal rotation periods.

[Arrowstar]

Hello everyone!

This evening I'm pleased to announce the release of the KSP Trajectory Optimization Tool v1.6.4.  This release is primarily a bug-fix and feature/performance enhancement release that has been in the work for a few months now.  Both Mission Architect and Launch Vehicle Designer has seen some work on them.  The single biggest change is an update to the internal atmospheric temperature model in order to include a number of mathematical terms which were previously left out and have now been included.  The method used to interpolate on atmospheric data has also been updated to a spline fit.  This should result in far more accurate atmospheric density calculations, and thus more accurate missions in both MA and LVD.

Please note that the KSPTOTConnect plugin has been updated to accommodate the new atmospheric temperature models.  You should update your existing plugin with the one in the new KSPTOT v1.6.4 download package.

Here's the complete change log:

• LVD: Added tooltip to edit constraints dialog box listbox.
• LVD: Added drag coefficient GA task
• LVD: Performance enhancements to cross product and the deep copy stage state functions
• LVD: Fix bug that was causing improper handling of non-sequential events in the sim driver
• LVD: Added radius beyond SoI radius validator.
• LVD: Option to set event specific initial step size for integrator, and then optimize that step size via context menu.
• LVD: When holddowns are enabled, integrate in the body-fixed frame with zeros for the pos/vel rates. (Performance enhancement)
• LVD: Added event termination condition direction option.
• Flyby Porckchop Plot: Resolved "not enough inputs" bug
• MA/LVD: All NEW MA and LVD cases will use spline interpolation for their atmospheric table interpolations.
• MA: Resolved an issue with atmo data being overwritten in MA when any undo/redo state is created.
• LVD: T2W is now computed at true altitude and not sea-level.
• MA/LVD: Update to temperature model.  All missing terms have been added now.
• MA: Updates to soi transition to eliminate a case where the soi max search UT was infinite when the go to tru DT was 0. Has been fixed to just assume that no time is passing.
• Resolved potential issue where atmo curves for bodies would not load correctly when loading a new bodies.ini file if the order of bodies in the old bodies.ini was different than in the new bodies.ini file. Clearing a persistent var in processINIBodyInfo does the trick.
• ...and other bug fixes and performance improvements.

As usual, the download is available in the first post of this thread. If you have any questions or discover any bugs, please drop me a line in some fashion to let me know and I'll do my best to address it! In particular, it would be great if those using the Linux version could provide any feedback on how it's working out. There are some known graphical issues, but those aside, if you discover any bugs that appear to be Linux-related, please let me know. Thanks!

Finally, if you enjoy using KSPTOT and its many applications (the Porkchop Plotter, Multi-Flyby Maneuver Sequencer, Mission Architect, Launch Vehicle Designer, and all the rest), please consider buying me a coffee via my Ko-Fi account to support KSPTOT's development. As I note in the first post of this thread, KSPTOT is a labor of love that I have put many, many hundreds of hours into for the benefit of the KSP community. The best part of it for me, aside from knowing that KSPTOT is the premier mission design tool for KSP, is all the thank you notes I've received over the years. I offer this as another way to say "Thank you!", if you so desire.

In any event, I hope you all enjoy! Happy orbiting!

Edited October 19, 2019 by Arrowstar

[Drew Kerman]

2 hours ago, Arrowstar said:

You should update your existing plugin with the one in the new KSPTOT v1.6.4 download package.

also don't forget to remind ppl they need to regenerate their Bodies.ini file if they are using a custom one

[Drew Kerman]

damn, I think I mentioned this before but it got lost in the shuffle - editing mission notes does not dirty the file and prompt a save request if you try to open or create a new file.

[Maravone]

Hi. I'm having an issue with KSP TOT. It simply refuses to open. After clicking the .exe, the cursor shows the loading circle and then...nothing. Task Manager shows that the program is running, but I've got nothing.
Using Windows 10, with Matlab compiler installed. Tried adding KSP TOT as a firewall exception but with no luck. Reinstalled the compiler, changed the program's directory... No luck.

I'm only posting here because I've checked the thread a few posts into the past and saw one instance of someone having the same problem as I, but no solution whatsoever.

If anyone had the same issue and has a solution or any idea where I should start troubleshooting, I would be really happy.
Its a shame I cant get this to work, as I'm playing RO/RSS, and I find KSP TOT a really useful tool to plan missions ahead, particularly complex mission profiles, which are almost impossible to get it right without something like this for me.

[Drew Kerman]

7 hours ago, Maravone said:

Hi. I'm having an issue with KSP TOT. It simply refuses to open. After clicking the .exe, the cursor shows the loading circle and then...nothing. Task Manager shows that the program is running, but I've got nothing.

How long have you waited for it to come up? I never really timed it but for me it sometimes seems to take a good minute or two to load

[Arrowstar]

2 minutes ago, Drew Kerman said:

How long have you waited for it to come up? I never really timed it but for me it sometimes seems to take a good minute or two to load

@Maravone: This is probably it.  The first run can take a few minutes because the whole program needs to unpack onto your hard drive.  Sadly I have no control over this, nor can I insert a progress bar or something to show that the program is working.  Restart your computer and then give the program a go again, and give it a few minutes to work. It should load.

If not, please follow the steps within this post and then try running it again (may take a few minutes to load after doing this):

 

[Drew Kerman]

I'm working through some propagation of captured asteroids around Kerbin ducking in and out of Mun's SOI and with the new SOI searching after 4-5 encounters it's taking up to 40-50s to rework things if I make a change. This is not bad except for when I decide I want to do something like alter the line thickness, state name, line color, etc. It would be preferable if changes that can't affect the trajectory don't cause the entire script to run again. I have a feeling though this may be just how things are pipelined, since it seems when you make a change later in the script it still wants to run everything from the beginning

[Maravone]

2 hours ago, Arrowstar said:

@Maravone: This is probably it.  The first run can take a few minutes because the whole program needs to unpack onto your hard drive.  Sadly I have no control over this, nor can I insert a progress bar or something to show that the program is working.  Restart your computer and then give the program a go again, and give it a few minutes to work. It should load.

I waited around 1 minute. Didnt knew it took that much time for first load. Makes sense though. I'll try that! Thank you for the response!

[Arrowstar]

2 hours ago, Drew Kerman said:

I'm working through some propagation of captured asteroids around Kerbin ducking in and out of Mun's SOI and with the new SOI searching after 4-5 encounters it's taking up to 40-50s to rework things if I make a change. This is not bad except for when I decide I want to do something like alter the line thickness, state name, line color, etc. It would be preferable if changes that can't affect the trajectory don't cause the entire script to run again. I have a feeling though this may be just how things are pipelined, since it seems when you make a change later in the script it still wants to run everything from the beginning

I could add a setting into MA and LVD that turns on or off the auto-propagation of the script, with a button on the main MA/LVD UIs that propagates the script on command and indicates in some way if the current script needs to be run.  Would this be helpful?

Edited October 21, 2019 by Arrowstar

[Drew Kerman]

6 hours ago, Arrowstar said:

I could add a setting into MA and LVD that turns on or off the auto-propagation of the script, with a button on the main MA/LVD UIs that propagates the script on command and indicates in some way if the current script needs to be run.  Would this be helpful?

That sounds like a much easier solution to implement and I wouldn't mind the extra "manual labor"

Also, my latest project has been to start analyzing the SOI propagation in depth because this could have a large impact on future flyby missions or missions exploring numerous moons of Jool or Sarnus, for example. I've mentioned before how it seems that MA loses accuracy fairly quickly when a captured asteroid makes multiple passes through Mun's SOI and I'm trying to understand why. Towards that end I have put together this analysis package.

There are 2 captured asteroids examined. One, Vieras, encountered Mun 7 times before being flung into Kerbin. It was discovered very shortly after being captured and so has a much larger change in eccentricity over time. The second, Alaba, was discovered well after it was captured in an orbit already with low eccentricity and largely changes its Arg Peri for radial movement. It's been through 27 encounter so far and remains in orbit. I only modeled out to 5 for starters.

Both asteroids have never been loaded into the flight scene. All SOI changes were done from the Tracking Station. Orbital data after each encounter was pulled directly from the game, not loaded from the SFS file however neither asteroid was the active vessel at the time.

Each MAT file starts from after a given encounter and propagates through as many additional encounters as it can before, at maximum zoom on the orbit plot, a deviation is noticeable. Orbital data from after each encounter is timestamped via the Epoch of the moment it entered Kerbin's SOI so I've used that as a measuring stick and compared the difference in when the asteroid exited in the game versus in MA. If the value is negative, then the asteroid exited that many seconds sooner in MA than it did in the game.

Turn on Show O. SC Orbits. Each MAT file also includes all the post-encounter orbits that were imported from the game, which are color & pattern coded to tell them apart. The solid lines that denote each post encounter trajectory calculated by MA are colored to match the actual post-encounter orbit they should line up with.

Right now I've only compiled all this data, I haven't really looked at it that closely - I'm wondering first if there is anything you can intuit from it. If not, advice on how to proceed from here would be appreciated

[BossBobcat]

Hi Arrowstar, 

I wanted to thank you for making such a great app for KSP. I've just begun using it and I'm really impressed. I have some professional experience with Matlab, so I was excited to see you using it for this. 

I do have a feature request for you. I've been working on building efficient communications  satilite constellations, and I was wondering if KSPTOT could integrate a RemoteTech constellation planner. I'm imagining a user could define a body, an orbit, and a number of satilites in the orbit, their range, and cone of influence, and then get information about what bodies could be covered, and when blackouts would occur. 

 

Again, thanks for making such a great tool! 

[BossBobcat]

Hi Again, 

I also noticed you were looking at how to approximate drag effects for small angles of attack. I'm not sure how KSP calculates drag or lift, and I'm certainly not considering anything like the bernuli effect, turbulence or flow seperation, but if you do a simple force balance on a plate, then you'd get the following:

 

Front Face:

Drag = q*A_front*Cos^2(theta)

Lift = -q*A_front*Cos(theta)Sin(theta)

Side Face:

Drag = q*A_side*Sin(theta)Cos(theta)

Lift = q*A_side*Sin^2(theta)

 

where q is the dynamic pressure per square meter, A is the area of the front aspect or side aspect, and theta is the angle of attack. 

 

Hope that helps!

[Arrowstar]

21 hours ago, Drew Kerman said:

Also, my latest project has been to start analyzing the SOI propagation in depth because this could have a large impact on future flyby missions or missions exploring numerous moons of Jool or Sarnus, for example. I've mentioned before how it seems that MA loses accuracy fairly quickly when a captured asteroid makes multiple passes through Mun's SOI and I'm trying to understand why. Towards that end I have put together this analysis package.

There are 2 captured asteroids examined. One, Vieras, encountered Mun 7 times before being flung into Kerbin. It was discovered very shortly after being captured and so has a much larger change in eccentricity over time. The second, Alaba, was discovered well after it was captured in an orbit already with low eccentricity and largely changes its Arg Peri for radial movement. It's been through 27 encounter so far and remains in orbit. I only modeled out to 5 for starters.

Both asteroids have never been loaded into the flight scene. All SOI changes were done from the Tracking Station. Orbital data after each encounter was pulled directly from the game, not loaded from the SFS file however neither asteroid was the active vessel at the time.

Each MAT file starts from after a given encounter and propagates through as many additional encounters as it can before, at maximum zoom on the orbit plot, a deviation is noticeable. Orbital data from after each encounter is timestamped via the Epoch of the moment it entered Kerbin's SOI so I've used that as a measuring stick and compared the difference in when the asteroid exited in the game versus in MA. If the value is negative, then the asteroid exited that many seconds sooner in MA than it did in the game.

Turn on Show O. SC Orbits. Each MAT file also includes all the post-encounter orbits that were imported from the game, which are color & pattern coded to tell them apart. The solid lines that denote each post encounter trajectory calculated by MA are colored to match the actual post-encounter orbit they should line up with.

Right now I've only compiled all this data, I haven't really looked at it that closely - I'm wondering first if there is anything you can intuit from it. If not, advice on how to proceed from here would be appreciated

Thanks!  I haven't had a chance to fully dive into what you wrote but hopefully I'll have a chance this weekend.

Quote

That sounds like a much easier solution to implement and I wouldn't mind the extra "manual labor"

I'll see what I can do.

18 hours ago, BossBobcat said:

I do have a feature request for you. I've been working on building efficient communications  satilite constellations, and I was wondering if KSPTOT could integrate a RemoteTech constellation planner. I'm imagining a user could define a body, an orbit, and a number of satilites in the orbit, their range, and cone of influence, and then get information about what bodies could be covered, and when blackouts would occur.

You can already do this in Mission Architect (MA), actually!  You define your trajectory and then place a number of "other spacecraft" in orbit somewhere.  There is a communications network analysis tool in MA that will then figure out how to join your spacecraft with any other "node" (including KSC) via the network of satellites created.  Let me know if you need help figuring it out and I'll see what I can do.

Quote

Again, thanks for making such a great tool! 

You're welcome!

[Arrowstar]

On 10/20/2019 at 8:42 PM, Drew Kerman said:

damn, I think I mentioned this before but it got lost in the shuffle - editing mission notes does not dirty the file and prompt a save request if you try to open or create a new file.

Resolved for next release.

[Drew Kerman]

got a new issue: MAT file. Repro:

1. add Coast to Pe
2. note it coasts to atmo Pe
3. edit Coast and change it to UT
4. set it back 5 min and save
5. add Coast to Function Value. Set to 70km and Max Propogation Time to 500 and save
6. add Coast to Pe
7. note it coasts past atmo Pe and out into sun-orbit Pe

Actually I think this may have been something I've seen & maybe reported before. I dunno it's ringing a dim bell can't say for sure

oh Darn it of course right after I post this I realize what the problem is. What I'm trying to do in the above steps is backing up the Coast to Pe by 5min takes me out of the atmosphere and then I try to coast down to 70km. However MA instead coasts past the 70km on the way down and instead terminates on the way up. That's not what I want.

If you follow the steps above to repro the upwards 70km coast, then adjust the Coast to Function State to a Max Propagation Time of 250 it catches the downward 70km. This I definitely remember reporting before

Edited October 31, 2019 by Drew Kerman
lol I can say "damn" (quoted in post above) but the forum censors "F.F.S." to "Darn it" :P

[Arrowstar]

16 hours ago, Drew Kerman said:

got a new issue: MAT file. Repro:

1. add Coast to Pe
2. note it coasts to atmo Pe
3. edit Coast and change it to UT
4. set it back 5 min and save
5. add Coast to Function Value. Set to 70km and Max Propogation Time to 500 and save
6. add Coast to Pe
7. note it coasts past atmo Pe and out into sun-orbit Pe

Actually I think this may have been something I've seen & maybe reported before. I dunno it's ringing a dim bell can't say for sure

oh Darn it of course right after I post this I realize what the problem is. What I'm trying to do in the above steps is backing up the Coast to Pe by 5min takes me out of the atmosphere and then I try to coast down to 70km. However MA instead coasts past the 70km on the way down and instead terminates on the way up. That's not what I want.

If you follow the steps above to repro the upwards 70km coast, then adjust the Coast to Function State to a Max Propagation Time of 250 it catches the downward 70km. This I definitely remember reporting before

Alright, I've got something whipped up that will be in the next pre-release.  Note that there's a non-trivial performance cost to finding the first root of the coast function, but there's not much that can be done to avoid that.

Note that this isn't going to be a perfect solution.  Here the two solutions (alt = 70 km) are pretty close together.  Before the root finder was just falling in towards one of them and finding that one.  Now I'm using a slightly more robust algorithm that should find the first one, but there are definitely cases where it may not find any of them if they are too close together.  For example of the time in the atmosphere was only a few seconds, this algorithm will probably just skip both of them entirely.  This is where you as the analyst might need to come up with a better way to formulate the problem.  The tool can do a lot but it can't do everything.

[Arrowstar]

On 10/21/2019 at 2:24 PM, Arrowstar said:

I could add a setting into MA and LVD that turns on or off the auto-propagation of the script, with a button on the main MA/LVD UIs that propagates the script on command and indicates in some way if the current script needs to be run.  Would this be helpful?

@Drew Kerman: Added for next release (for both LVD and MA).

[Arrowstar]

Hi everyone,

I wanted to take a moment to talk about what's coming in v1.6.5.  I've been doing a bunch of work on improving the optimization experience in Launch Vehicle Designer (LVD).  Right now there are two different algorithms (FMINCON and Pattern Search) but PS was sort of hacked in there and almost none of the available options for either are exposed.  In general, optimization in LVD can feel a bit rough and unproductive to me.  I want to change this with v1.6.5.

In addition to the items I've already posted about above, here's what I see coming for this release:

1. New optimizer interface
   1. Right now the current optimizer interface is menu driven, exposes only a very small number of options for each algorithm, and is not the easiest to make sense of.  That's all going to change.  A new "Optimizer Algorithm Selection" user interface is coming that will allow users to cleanly select the algorithm they want.  In addition, each optimizer will have its own options user interface that will allow users to set many more options than a few that are currently available now.
2. New optimizer(s)
   1. As I mentioned before, there are two optimizer available in LVD right now.  FMINCON works pretty well for what it does, and Pattern Search has its strengths, but it tends to work poorly on problems where feasibility is hard to find. 
   2. Enter NOMAD, or "Non-smooth Optimization by Mesh Adaptive Direct search."  NOMAD works astoundingly well at taking a trajectory with many constraint violations and reducing those violations to a place where something like FMINCON can pick it up and solve it.  (It also does pretty well at finding feasible solutions in general if you give it enough time.)  Right now NOMAD's biggest draw back is that it can't be run in parallel, but I've contacted the developers to see what I can do.  (The software itself supports parallelization but something funny happens when you try to use it in MATLAB.)
   3. I may also include "IPOPT", where is pretty similar to FMINCON's "interior point" algorithm, but seems to work better in some cases.
   4. Both NOMAD and IPOPT are part of the OPTI Toolbox, and if I do end up including them, will (sadly) only be available on the Windows build because OPTI is only built for Windows.
3. Constraint Jacobian visualization
   1. The constraint Jacobian is a matrix where each row represents a constraint and each column is a particular variable.  Each element of the matrix is the sensitivity of that constraint to that variable.  In general, you want each element to be roughly about 1.0, and you achieve this by scaling your constraints using the scale input in the Edit Constraint dialog box.  A new feature to LVD is the ability to compute and visualize this matrix in a heat map so that you set those scale factors accordingly.

That's all I've got for now.  The dialog boxes for FMINCON and Pattern Search are done, the selection dialog box is basically done, and I'm actually running NOMAD right now to solve a full Kerbin - Mun - Kerbin mission in LVD, and it's doing pretty well.  Just need to get an options dialog box together for that, check on the possibility of parallelization, and decide on IPOPT (which might just come in a later release if I decide I want to include it after all).

Thoughts?

[Drew Kerman]

I've never had to even think about what optimizer I've been using. I've always just run it. This is mainly due to the fact that it's never really had too much trouble getting a solution for me. So while I don't consider any of the above immediately useful it does sound like in the future as my mission complexity grows and I throw tougher problems at MA/LVD there will be more options to help find me a solution so, good stuff!

[Arrowstar]

Hi everyone,

Tonight I've compiled KSPTOT v1.6.5 pre-release 1.  Here's the change log:

• MA/LVD: Added option to auto-propagate (or not) the mission script when changes are made to it.  Useful when your script takes forever to propagate and you have lots of changes to make.
• Improved robustness of "coast to function value" in MA.
• MA/LVD: Editing mission notes prompts user to save file (asterisk in window title).
• LVD: Overhaul of optimization:
  • Added new optimizer: NOMAD
  • Added new option for computing gradients of objective function (a custom finite difference scheme)
  • Added a new UI for selecting optimization algorithm.
  • Added many new options for FMINCON and Pattern Search algorithms (including two new UIs for them).
  • Removed all the old optimization options (they are incorporated to the new options now).

Caveats:

1. The custom finite difference scheme still needs a UI for its options.
2. NOMAD is not yet available on Linux.  I can't get the code to compile properly yet and both the developer and I are perplexed to say the least.  Still working on this.

Please let me know if you find any bugs or issues with this build.  A lot of the optimization changes are experimental at this point so the more testing the better.  Thanks!

[Drew Kerman]

thx for the latest release! also have you had a chance to read over my post, if not checked out the analysis package? Just want to make sure I was clear in what I was working on. Haven't really touched it myself since I posted it