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

[Drew Kerman]

not unless you tell us precisely what you want to do. Gravity assist from where using what body to where? I'm not going to make up and work out a generic example scenario but I'm willing to help you through yours

[Arrowstar]

Arrowstar have you considered extending the comm analysis with dish & targeting support? Not sure if you already planned to eventually get around to this once the current basic functionality was fully tested or if I need to convince you. But if it's the latter here are my issues:

http://i.imgur.com/5zJW3sC.png

Black dot in the center of Kerbin is an inter-planetary comsat in a polar Molniya orbit high above Kerbin, using a 400M km dish to talk to craft at Duna (or beyond). It then uses a small 50,000 km dish to talk to a relay satellite (inner dot), which then uses a 2500 km omni antenna to talk to KSC or, when KSC is not visible it bounces signals off any of 7 other satellites with 2500 km omni antennas (only 3 of my dedicated comsats are shown here - see the whole picture here).

The reason I depict these three satellites is because they also contain 50,000 km dishes to talk to satellites around Mun and Minmus. However since MA treats everything as omni, it will think any of these three satellites can talk directly to my IP ComSat. So the red line is the path the comm route is supposed to take, blue is the path MA will analyze it taking.

Granted, at the speed of light across these distances near Kerbin we're talking a negligible difference in travel time - but it still largely affects 3 of the 4 graphs being output by the comm analysis window.

Another example is that I actually have two IP ComSats in Molniya orbits (so one is always visible) and a craft around Duna and Ike - both are only able to talk to one IP ComSat. So if the craft around Ike can't see its IP ComSat, it should try to route through the craft around Duna to the second one. However MA will just connect it straight to the second IP ComSat it's not supposed to be talking to if it can see it. (or it can actually talk directly to KSC from this distance - which again it's not supposed to do)

It's an interesting idea. I'll consider it for a future release. Definitely not impossible, but it would require a fairly significant overhaul of the comm networking data structures. I'll think about how it would work.

---

In other news, here is KSP TOT v1.5.0 pre-release 5. The major changes from last time include:

1) Some performance optimizations related to the redo/undo menu and its backend data.

2) Four new DV maneuver types, all of which use spherical coordinates. Spherical coordinates use an azimuth (angle in a plane) and elevation (angle out of the plane) and DV magnitude to define the maneuver. There are inertial and orbit impulse maneuver types as well as inertial and orbit finite burn duration maneuver types. The best use for these new types to allow you to specify the min and maximum delta-v magnitude for the optimizer.

3) I've disabled the launch trajectory tool for now. It requires more work than I give at the moment and it's just not ready to go in any usable form. Also, for some reason adding the new atmospheric curves removed the ability to use parallel processing for this code, which dramatically kills optimization performance. I may have to re-think how useful this tool is and if I want to include it in the future.

That's all I've got for now. Let me know if you have any questions.

(And sorry for the long delay here, sometimes I just need a creative break...)

[Drew Kerman]

It's an interesting idea. I'll consider it for a future release. Definitely not impossible, but it would require a fairly significant overhaul of the comm networking data structures. I'll think about how it would work.

the way things are right now are fine - I mean you should know your own comm system so you can select the route the signal should be taking, but it does only let you check one viable route at a time instead of just allowing you to canvas the network and see where the signal is going.

3) I've disabled the launch trajectory tool for now. It requires more work than I give at the moment and it's just not ready to go in any usable form. Also, for some reason adding the new atmospheric curves removed the ability to use parallel processing for this code, which dramatically kills optimization performance. I may have to re-think how useful this tool is and if I want to include it in the future

IMO it's probably not something you would want to focus heavily on until you find yourself out of cool things to do orbital-wise. Or as a break from orbital stuff. As much as it pains me to say all that cause it's something I've always wanted

Edited August 29, 2015 by Gaiiden

[Drew Kerman]

Arrowstar what's going on here (PR5):

I thought I told the optimizer to leave my Normal and Radial values alone, I left them at 0 and after I stopped the optimizer and checked they were now set to this. I also had an earlier run where the Prograde value was -80, well outside the bounds I set. In fact even if I check the Normal and Radial Opt boxes and set the upper/lower to 0 each they still get modified.

I do not have "No Optimization" selected for my objective function

Edited August 29, 2015 by Gaiiden

[thedanieldude]

I have just spent the last 6 hours reading all the pages in this thread and I love this tool! One complaint I have is when I uploaded a jool transfer node it gave me an orbit with a very low sun periapse. I dont know why this happens!

[thedanieldude]

Also, when I upload a node and it works, the trajectory is not what it looks like in the planner. I did the laythe tutorial and my final orbit wasn't within Laythes SOI. (Yes I had enough conics) I had to edit the node manually. This isn't really a glitch but more of a request to know what could've caused this inaccuracy, because it could be mission destroying for more advanced maneuvers.

[Drew Kerman]

I have just spent the last 6 hours reading all the pages in this thread and I love this tool! One complaint I have is when I uploaded a jool transfer node it gave me an orbit with a very low sun periapse. I dont know why this happens!

Give specific steps to consistently reproduce this issue

Also, when I upload a node and it works, the trajectory is not what it looks like in the planner. I did the laythe tutorial and my final orbit wasn't within Laythes SOI. (Yes I had enough conics) I had to edit the node manually. This isn't really a glitch but more of a request to know what could've caused this inaccuracy, because it could be mission destroying for more advanced maneuvers.

This is common. Floating point errors in KSP means you're never going to get exactly the orbit that you plot. Personally I try to mitigate this by keeping vessels on rails as much as possible but there's only so much you can do, and the further you travel the larger the errors get, so be ready for small adjustment maneuvers along the way

[Drew Kerman]

also Arrowstar I've noticed that it sometimes takes me two tries to open the Optimizer, and there are times after running the Optimizer that the Final Spacecraft State does not update to match what you get when you select the last state and select View State After Selected Event

[taio]

Is there any ability to plan a mission in reverse? Either having time run in reverse, or by starting from a final state instead of an initial state? I want to explore a complicated series of gravity assists, and I don’t particularly have any idea when I should leave Kerbin  my boundary condition is a transfer window that comes late in the picture.

If nothing else, it should work to reverse the correct orbital elements of everything in bodies.ini, right? I expect there would be multiple ways to do this, but I’m not sure what the most straightforward time-reversal mapping of the elements is (or any time-reversal mapping of them). Then I’d set all the epochs to X, and then my new timeline would effectively run in reverse from X to 0.

Or maybe I can add a "* -1" somewhere in the source, and recompile?

Edited September 7, 2015 by taio

[Drew Kerman]

Is there any ability to plan a mission in reverse?

Short answer: no

Long answer: nope

[taio]

Is there something wrong with time-reversing bodies.ini?

[Drew Kerman]

there's something wrong with the whole concept. I don't see how you can know your final state any better than your initial state for the program to run things backwards - assuming it could, Arrowstar would have to answer that one.

- - - Updated - - -

Latest Release Candidate may have an issue with the MCC Real Time System - I can connect but no matter what craft I choose it only shows me the data from the craft at the top of the list. Can anyone else confirm?

[Arrowstar]

Arrowstar what's going on here (PR5):

http://i.imgur.com/Qbpw6TZ.png

I thought I told the optimizer to leave my Normal and Radial values alone, I left them at 0 and after I stopped the optimizer and checked they were now set to this. I also had an earlier run where the Prograde value was -80, well outside the bounds I set. In fact even if I check the Normal and Radial Opt boxes and set the upper/lower to 0 each they still get modified.

I do not have "No Optimization" selected for my objective function

Yeah, it's a product of the way I set up the optimization problems. I've been looking at ways to eliminate it for some time now, but I haven't gone about implementing anything. It's definitely on the short term agenda though, it's very annoying.

also Arrowstar I've noticed that it sometimes takes me two tries to open the Optimizer, and there are times after running the Optimizer that the Final Spacecraft State does not update to match what you get when you select the last state and select View State After Selected Event

Resolved in up-coming release.

Latest Release Candidate may have an issue with the MCC Real Time System - I can connect but no matter what craft I choose it only shows me the data from the craft at the top of the list. Can anyone else confirm?

I'll take a look into it! Thanks for letting me know.

[Arrowstar]

Latest Release Candidate may have an issue with the MCC Real Time System - I can connect but no matter what craft I choose it only shows me the data from the craft at the top of the list. Can anyone else confirm?

Could not reproduce, sorry. Can I get more specific steps or a (stock) save file?

[Arrowstar]

Hi everyone,

I have KSP TOT v1.5.0 pre-release 6 ready to go. Here's the changes (as I remember them):

1) Resolved an issue where the GUI would rapidly slow down after running the optimizer multiple times. This issue was around since v1.0.0 but was exasperated by v1.4.0. The actual root cause of the issue is probably a bug in MATLAB's memory management, but I actually like the fix better than the old way I was doing things, so I'm going to keep it permanent.

2) Resolved an issue where variables not marked for optimization in a burn (or any multi-variable event) would get changed by the optimizer. Thanks for pointing this out, Gaiiden. Turns out it was very easy to fix...

3) "Re-optimize Mission" in the Mission Architect Optimization menu now actually serves a purpose and is useful. Before it would just run the exact same case again, providing the same answer you already got. Now it runs the current script with the same optimization settings/constraints/objective/etc, which was its original purpose.

4) Some other minor speed improvements here and there.

Another note: I'm currently evaluating MATLAB R2015b, just released a few days ago, for use with KSP TOT. KSP TOT v1.5.0 will still be released on R2014b, but future versions (v1.5.1+) may be on R2015b. The reason for this has to do with some serious improvements The MathWorks made to the MATLAB execution engine. Some benchmarks I've seen suggest that runtime could be halved in some cases (meaning code executes about twice as quickly). There are also optimizations to the back-end graphics engine with means that plots get drawn faster. Since Mission Architect relies on quick draw times to produce trajectory plots and all that, this is a welcome improvement. If there are any objections to me moving to R2015b, please let me know. The only action end-users would need to take is to download the R2015b MATLAB Compiler Runtime (MCR) and install it. Everything else would work the same.

Please let me know if you have any questions.

EDIT: I've just updated the pre-release 6 package with a new executable that includes two more things I've been wanting to add for some time:

1) The Other Spacecraft, Thrusters, and Ground Target GUIs no longer have that annoying "update" button. Now whenever you hit enter or the input field loses focus, the update function is called automatically behind the scenes. This is more consistent with the way the rest of Mission Architect works.

2) I added a "Show Event" checkbox to Mission Animator that shows the currently executing event name in the upper right text box.

Edited September 11, 2015 by Arrowstar

[Arrowstar]

Hi everyone!

I'm happy to announce the release of KSP Trajectory Optimization Tool v1.5.0!Here's the change log:

• Added a Mission Notes section under the Edit menu, let's you record text or whatever you want and store it for later.
  
• Added a Staging event to the Events menu. This is basically a Mass-only Set State: you tell it what your post staging dry mass, fuel/ox mass, etc masses are and it sets them for you. Useful for when you're dropping partially used stages, and very complementary to the existing MASS_DUMP event.
  
• Added commentary to the bodies.ini file.
  
• Added the KSP v1.0 atmospheric model to KSP TOT Mission Architect.
  
• Some performance optimizations related to the redo/undo menu and its backend data.
  
• Four new DV maneuver types, all of which use spherical coordinates. Spherical coordinates use an azimuth (angle in a plane) and elevation (angle out of the plane) and DV magnitude to define the maneuver. There are inertial and orbit impulse maneuver types as well as inertial and orbit finite burn duration maneuver types. The best use for these new types to allow you to specify the min and maximum delta-v magnitude for the optimizer.
  
• Resolved an issue where the GUI would rapidly slow down after running the optimizer multiple times. This issue was around since v1.0.0 but was exasperated by v1.4.0. The actual root cause of the issue is probably a bug in MATLAB's memory management, but I actually like the fix better than the old way I was doing things, so I'm going to keep it permanent.
  
• Resolved an issue where variables not marked for optimization in a burn (or any multi-variable event) would get changed by the optimizer.
  
• "Re-optimize Mission" in the Mission Architect Optimization menu now actually serves a purpose and is useful. Before it would just run the exact same case again, providing the same answer you already got. Now it runs the current script with the same optimization settings/constraints/objective/etc, which was its original purpose.
  
• Some other minor speed improvements here and there.
  
• Other minor fixes and optimizations.
  

As always, please let me know if you have any questions. Thanks!

- - - Updated - - -

Oh, just a note. So I'm trialing MATLAB R2015b right now and it's incredible. One of my KSPtoMars Mission Architect mission plans has 18 events and takes ~0.280 seconds in R2014b. The same plan takes ~0.10 seconds in R2015b! That's an incredible speed up.

I haven't fully decided yet if I'll do this, but I really like the performance improvements. Assuming I go with this, it'll be v1.5.1 mostly likely.

[immelman]

Hi everyone!

I'm happy to announce the release of KSP Trajectory Optimization Tool v1.5.0!Here's the change log:

• Added the KSP v1.0 atmospheric model to KSP TOT Mission Architect.

This is awesome, thank you!

Would you be able to go into more detail about the atmospheric modelling? Would this be anything that could be applied to FAR as well?

[Arrowstar]

This is awesome, thank you!

Would you be able to go into more detail about the atmospheric modelling? Would this be anything that could be applied to FAR as well?

There's not too much detail to be honest. I talked to farram (who has done a lot of digging into the KSP source code with Squad's permission) and he walked me through the atmospheric model. I then copied the same math into KSP TOT Mission Architect.

I'm not actually sure what FAR's atmospheric model is like at this point. I suspect that the stock model is sufficient for most things you'd want to do, though, so just stick with that for now and if it proves insufficient then we can talk about a FAR implementation. Or it could just be that he uses the same math and changes the numbers, in which case all that would be needed would be a new bodies.ini file for FAR, which you could generate on your own with KSPTOTConnect.

[immelman]

There's not too much detail to be honest. I talked to farram (who has done a lot of digging into the KSP source code with Squad's permission) and he walked me through the atmospheric model. I then copied the same math into KSP TOT Mission Architect.

Now I'm even more interested

Applying kOS automation has changed how I approach mission planning, especially since it encourages you to dive deeper into the math involved. I'd like to work out a model for the in game aerodynamic forces. Could you able to describe anything about these?

Edited September 12, 2015 by immelman

[Drew Kerman]

Added a Mission Notes section under the Edit menu, let's you record text or whatever you want and store it for later.

is it possible to have the window close automatically if you left it open but behind MA out of sight and forgot about it when you create a New project or Load an existing one?

Four new DV maneuver types, all of which use spherical coordinates. Spherical coordinates use an azimuth (angle in a plane) and elevation (angle out of the plane) and DV magnitude to define the maneuver. There are inertial and orbit impulse maneuver types as well as inertial and orbit finite burn duration maneuver types. The best use for these new types to allow you to specify the min and maximum delta-v magnitude for the optimizer.

If you have a basic use-case example you could include as a MAT with future releases, that would probably help a lot of people understand how to properly use these new maneuver types (including me haha)

Resolved an issue where variables not marked for optimization in a burn (or any multi-variable event) would get changed by the optimizer.

Awwssss yeaaaa

"Re-optimize Mission" in the Mission Architect Optimization menu now actually serves a purpose and is useful.

AWWWWSSS YEEEAAAAAAAA

---

Also Arrowstar I remembered I hadn't heard your thoughts on this post from a while ago. Did you see it?

---

Not a fan of the modified Other Spacecraft window. I like the new auto-update because yea there were times I would make changes and forget to tell it to update before moving on to another vessel or closing the window - but the Add functionality is now rather awkward. I really think it should just be a modal dialog you enter information into then click OK to close and add. Or, another option if you don't like the additional dialog, is to just keep a (New) list entry at the top that the user can select when they want to add a vessel, so that it resets all the fields when it is selected then when the user hits Add the new vessel is appended to the bottom of the list but (New) remains on top to be selected again if another vessel is to be added. I actually like the second idea better I just happened to come up with them in that order while I was typing this

(aaaand a bit later with some more mucking about I realized my second idea is sort of what you're already doing, but in the current form I was initially totally confused as to which entry in the list I just created. My tweaks should make it more user-friendly I feel)

---

yes, more! Check this mission file out. Load it up and set your SOI revs to 100 and it'll properly coast through all transitions until it no longer detects any at event 22. Now open up the Initial State and then Save & Close without touching anything. Events 18-21 will all lose their SOI hits. Ctrl+Z Undo fixes whatever the hell I didn't do

Edited September 12, 2015 by Gaiiden

[Arrowstar]

is it possible to have the window close automatically if you left it open but behind MA out of sight and forgot about it when you create a New project or Load an existing one?

It should have been modal, this was an oversight on my part. Issue will be corrected for next release.

If you have a basic use-case example you could include as a MAT with future releases, that would probably help a lot of people understand how to properly use these new maneuver types (including me haha)

I can put something together.

Also Arrowstar I remembered I hadn't heard your thoughts on this post from a while ago. Did you see it?

I saw it, but it'll take a fair bit to implement. Still debating if the effort is worth the value.

Not a fan of the modified Other Spacecraft window. I like the new auto-update because yea there were times I would make changes and forget to tell it to update before moving on to another vessel or closing the window - but the Add functionality is now rather awkward. I really think it should just be a modal dialog you enter information into then click OK to close and add. Or, another option if you don't like the additional dialog, is to just keep a (New) list entry at the top that the user can select when they want to add a vessel, so that it resets all the fields when it is selected then when the user hits Add the new vessel is appended to the bottom of the list but (New) remains on top to be selected again if another vessel is to be added. I actually like the second idea better I just happened to come up with them in that order while I was typing this

(aaaand a bit later with some more mucking about I realized my second idea is sort of what you're already doing, but in the current form I was initially totally confused as to which entry in the list I just created. My tweaks should make it more user-friendly I feel)

I think what I'm actually going to do is set things up so when you push "add" you get a generic spacecraft/ground site/thruster. That will probably be less confusing than the "copy" mechanic that I use now.

yes, more! Check this mission file out. Load it up and set your SOI revs to 100 and it'll properly coast through all transitions until it no longer detects any at event 22. Now open up the Initial State and then Save & Close without touching anything. Events 18-21 will all lose their SOI hits. Ctrl+Z Undo fixes whatever the hell I didn't do

So the issue here is one of numerical precision. When you load up the mission plan and put numbers into the initial state, you get an orbit. When you re-open up the initial state, the closest string representation of the double you entered is what shows up in the box (which is VERY VERY SLIGHTLY) different than what you entered. 16 events later, this results in an orbit which doesn't find an SoI transition.

You can try it yourself. Move the orbit plot to event 16, then open and save the initial state as you describe. You'll see the orbit move radically. Let me know if that answers your questions.

[Drew Kerman]

I think what I'm actually going to do is set things up so when you push "add" you get a generic spacecraft/ground site/thruster. That will probably be less confusing than the "copy" mechanic that I use now.

So click Add, then modify the values of the default object that gets created. Yea that would work. I didn't test this but I just thought of it now - are text fields also saved on window close? So like if I click a spacecraft, change its name and then close the window, will that take?

Let me know if that answers your questions

Yes, thanks

- - - Updated - - -

Issue I noticed: when loading a mission file the Number of Revs SOI search setting is not applied. In that MAT I linked to earlier when I open it up and don't get any SOI hits I go to set the SOI Revs and I see it is already set to 100, but I have to close and save that value for the limit to be applied

- - - Updated - - -

I just added a tip to the Tips & Tricks wiki entry about modifying the orbital line colors, but really now that I think about it I would rather be able to manually set the line color in the Event box itself. I know I know - you'd have to add a color dropdown to each Event type dialog. Sorry But think about the benefits! Like being able to create something like this:

Which could be done by being able to set plot lines the same color for a series of event states. It could also be done by using Other Spacecraft orbits (<-- KSA spoiler alert! Image not posted yet!), but that's rather redundant when the plot data is already there in MA. Plus this method is only good if there are no trajectory changes done during the orbit (applicable in this example because orbit changes are being done via Mun gravity assist so no need to show them)

(That's all of Cassini's orbits, BTW, showing various missions in different colors. I made a similar overview of my Ike mission so far a while ago, but without color control it looks rather messy and they don't mean anything other than separate event states)

And I still wish we could have a black background option for the Pop-Out figure window

Edited September 12, 2015 by Gaiiden

[Arrowstar]

So click Add, then modify the values of the default object that gets created. Yea that would work. I didn't test this but I just thought of it now - are text fields also saved on window close? So like if I click a spacecraft, change its name and then close the window, will that take?

So it took all of 5 minutes to implement the new "Add" behavior for those three dialog boxes, so that will come in the next release. As far as fields saving on window close, a preliminary test suggests "yes."

Issue I noticed: when loading a mission file the Number of Revs SOI search setting is not applied. In that MAT I linked to earlier when I open it up and don't get any SOI hits I go to set the SOI Revs and I see it is already set to 100, but I have to close and save that value for the limit to be applied

Yeah, minor oversight on my part. Issue has been corrected for next release. Thanks for finding this!

I just added a tip to the Tips & Tricks wiki entry about modifying the orbital line colors, but really now that I think about it I would rather be able to manually set the line color in the Event box itself. I know I know - you'd have to add a color dropdown to each Event type dialog. Sorry But think about the benefits! Like being able to create something like this:

It wouldn't actually be that bad, to be honest. Maybe I'll look into doing it.

And I still wish we could have a black background option for the Pop-Out figure window

Lol, I'll think about the best way to go about that, if it's feasible.

[Arrowstar]

So... something like this, then?

[Drew Kerman]

That looks great. Although that also reminds me - can you actually tell the difference between pink and magenta? It's kind of hard I think. See how these colors work:

Magenta: 178,0,255

Pink: 255,0,220

Yellow: 255,216,0

Orange: 255,106,0

I pulled those from my Paint.NET color palette and they look pretty distinct over a white background when I draw them. The yellow especially needs to be darker because the contrast of the current yellow is just painful