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

[Arrowstar]

The newest version of KSPTOTConnect doesn't appear to work with KSP 0.90. When trying to create a new bodies.ini, I get an error asking if KSP is running with the plugin activated and then KSP freezes.

Oh, I did forget about that. Yes, the plug-in will only work on ksp 1.0 due to changes in the ksp API. Sorry about that.

Edited May 14, 2015 by Arrowstar

[Arrowstar]

Hey everyone,

So a while back I promised to get code up on github or something like that for the purposes of letting folks offer suggestions and see how things work. For a variety of reasons, I never got around to it. That is, until today. I just finished setting up and playing around with the new KSPTOT github repo:

https://github.com/Arrowstar/ksptot

I would like to encourage people to use the Issue Tracker and contribute to the wiki as they see fit.

Please let me know if you have any questions.

[Arrowstar]

Hey everyone,

I wanted to let folks know where the next release of KSP TOT, v1.3.2, is headed. This will be a performance improvement release focused on reducing the run time of the script execution engine. I decided this was necessary Monday evening after discovering that trying to plan my trip to Eeloo was a royal pain in the neck with the optimizer taking so long to run. Not that I don't use KSP TOT regularly, but this mission was actually hard to execute because of the slow run times. I've been working on it since and here's what I've accomplished thus far:

• 10x decrease in run time on the Kepler solver. This is due to eliminating the use of fzero() for both elliptical and hyperbolic cases. Should reduce total run time by 15-20%.
  
• Eliminated a findObj() call that should reduce total runtime by 5%-10%.
  
• Enabled strict SoI search by default, which should reduce total run time by 10%-20%. (I've also seen it do nothing, though, so it's very situation dependent.)
  

The last item on the TO DO list is what I'm calling "selective SoI search." The idea here is that you may not want to consider every possible SoI transition while planning that mission to Eeloo. You may only want to consider Jool (for that flyby delta-v) and Eeloo, for example. In this case, you can eliminate all the calls to the SoI transition search code that would normally look for "downwards" SoI transitions to other bodies. (A downward transition is one that takes your spacecraft "down" the solar system hierarchy, so Sun -> Planet or Planet -> Moon.) Now, why does this help? The downwards SoI transition code accounts for about 50% of total mission script execution time due to the use of a bounded function optimizer that pinpoints the SoI transition time/place through the use of a "distance to body" function. That function has been heavily optimized, which is why the whole thing only accounts for 50% of the run time. Therefore, in order to improve the situation, I need to try to eliminate calls to the function optimizer in general. This "selective SoI search" method should help do that in many cases.

Please let me know what you think. By the way, I'm very open to performance optimization suggestions. Feel free to take a gander at the code and if anything stands out at you, let me know.

[Arrowstar]

Right, in an amusing twist, I was eager to implement the selective SoI search functionality I just described above and so... I did. Who wants to play with the first v1.3.2 pre-release?

Here's how to use the selective SoI search functions:

1. Script -> Execution Settings -> Use Selective SoI Transition Search should be checked.
   
2. Open or create a Coast event.
   
3. Find the "Selective SoI Search" button on the Create Coast GUI. Their should be green "Active" text underneath it, noting that the Selective SoI Search function is active.
   
4. Push the button.
   
5. Likely all of the bodies available will be highlighted in the resulting dialog box. Select those bodies that you want Mission Architect to consider when looking for downwards SoI transitions. If you want to select none, you can remove selections with control-click.
   
6. Push OK.
   
7. Push Save & Close on the Create Coast dialog box.
   
8. Viola! You're done.
   

Note that, for maximum flexibility, the bodies for each coast have to be selected individually. If you want to turn off selective SoI search, you can use the menu item in Step 1 and this will ignore any selective SoI transition options you've set for any coasts while the function is off.

Using this functionality with my upgraded Kepler Solvers on my Kerbin -> Jool -> Eeloo mission plan reduced the execution time of the script from ~1.2 seconds to ~0.17 seconds. That's a nice improvement!

Please tell me what you think of the pre-release.

Edited May 15, 2015 by Arrowstar

[Drew Kerman]

Please tell me what you think of the pre-release.

I think you should also make clear that this selective-SOI feature is only useful for bodies within the current coast SOI. I recall a while ago asking about and having you confirm the optimizer already dumps out bodies it knows you're not going to hit. So users shouldn't think that to help make optimizing their mission from Kerbin to Mun faster they need to go and disable selective SOI for Jool, Pol, Duna, etc etc. In fact it may just be more user-friendly to load up the list of bodies with only the ones the optimizer would consider anyways. So if you set the reference body to Kerbin, then the selective SOI box would only give you options for Mun & Minmus.

BTW have you looked into inverting the render colors for the Mission Architect figure window? Black background with white graph lines? I did a quick mockup:

[Arrowstar]

I think you should also make clear that this selective-SOI feature is only useful for bodies within the current coast SOI. I recall a while ago asking about and having you confirm the optimizer already dumps out bodies it knows you're not going to hit. So users shouldn't think that to help make optimizing their mission from Kerbin to Mun faster they need to go and disable selective SOI for Jool, Pol, Duna, etc etc. In fact it may just be more user-friendly to load up the list of bodies with only the ones the optimizer would consider anyways. So if you set the reference body to Kerbin, then the selective SOI box would only give you options for Mun & Minmus.

So I thought about this too. However, it occurred to me that I can't actually guarantee which bodies a Coast may or may not encounter because there isn't actually a single "current coast SoI" as you described it. For example, I've created coasts that go from Kerbin's SoI all the way to Laythe in a single bounce, that's four separate SoIs. Obviously I can't just restrict the options here to Jool's moons (the Coast ref body being Laythe), because that would miss out on Minmus, Mun, and all the planets around Kerbol. Since there's no good way of knowing which bodies you could encounter, I just list them all.

Now, I agree that not selecting Duna, Pol, etc will not help a Mun mission go faster. Maybe I should put a notice somewhere stating this as such? Any thoughts on what I might say if I did?

BTW have you looked into inverting the render colors for the Mission Architect figure window? Black background with white graph lines? I did a quick mockup:

http://i.imgur.com/2jd4quX.png

I did, but I didn't like it much to be honest. The black background seemed to clash with the rest of the application's look and feel. Maybe I just didn't spend enough time with it, but it seemed to "clash" to me. I guess I could make it an option lol.

[Drew Kerman]

Now, I agree that not selecting Duna, Pol, etc will not help a Mun mission go faster. Maybe I should put a notice somewhere stating this as such? Any thoughts on what I might say if I did?

Might be something to include in the wiki docs. Which reminds me I need to put some work in there as well.

I did, but I didn't like it much to be honest. The black background seemed to clash with the rest of the application's look and feel. Maybe I just didn't spend enough time with it, but it seemed to "clash" to me. I guess I could make it an option lol.

An option would be good, but I understand if you feel the aesthetic doesn't work. From a functional standpoint however it does do a great job lowering eye strain - some of the lighter colors you are using to render orbits (magenta, yellow) show up much better and much softer against a black background, as do the rest of the colors available to be selected for showing other orbital paths

[Arrowstar]

Might be something to include in the wiki docs. Which reminds me I need to put some work in there as well.

I would be thrilled if you wanted to put some things up on the wiki. That would be great!

An option would be good, but I understand if you feel the aesthetic doesn't work. From a functional standpoint however it does do a great job lowering eye strain - some of the lighter colors you are using to render orbits (magenta, yellow) show up much better and much softer against a black background, as do the rest of the colors available to be selected for showing other orbital paths

Okay, I'll keep this in mind. Thanks!

- - - Updated - - -

Great, thanks for the new release .

(I'm more or less following, don't have enough time yet to keep on par with you and Gaiiden, but sure want to try the new version).

Opps, completely missed this. Sounds good though! Let me know if you have any questions.

[Hididigeigei]

Hi, I started using this handy tool yesterday and got some nice transfers but now i ran into a problem.

Maybe you guys could help me understand whats wrong, if it's an error on my side...

I wanted to get a simple transfer from Kerbin to Eve searching from earliest Departure and Arrival Time: Year 2 Day 110 Kerbin Time System (6 Hours day)

The Porkchop says for optimized Departure+Arrival Delta-V 2.2285 km/s while the detailed window gives me 2.2279 km/s

After trying dozen of orbits to calculate the departure burn, even with the default 700km SMA, the departure maneuver now alone requires at least 2.8 km/s.

It requires always far more than the earlier calculations for Departure + Arrival together.

[Drew Kerman]

After trying dozen of orbits to calculate the departure burn, even with the default 700km SMA, the departure maneuver now alone requires at least 2.8 km/s.

It requires always far more than the earlier calculations for Departure + Arrival together.

I was able to recreate this, but take a look at your departure trajectory - it's on a pretty extreme inclination. Re-calculate your departure burn with a starting orbit at 50 degrees inclined, leave everything else alone and check the Dv requirements for that one

Always remember inclination changes are extremely expensive, especially deep in a gravity well, close to a planet. So you'll want to launch into an inclined orbit

[Hididigeigei]

With 50 degrees i get a really cheap transfer burn, thanks.

The thing is, i now managed a transfer burn myself to Eve on an equatorial orbit on said Date Y2D110 requiring only ~1200 m/s, burning only prograde and normal, and another 1600m/s for the insertion, which is still less than the tool tried to give me for the departure burn alone, so a cheaper solution ist definitely possible...

[Arrowstar]

With 50 degrees i get a really cheap transfer burn, thanks.

The thing is, i now managed a transfer burn myself to Eve on an equatorial orbit on said Date Y2D110 requiring only ~1200 m/s, burning only prograde and normal, and another 1600m/s for the insertion, which is still less than the tool tried to give me for the departure burn alone, so a cheaper solution ist definitely possible...

Could you take some screenshots to show me what you mean? Because the tool uses optimizers, you don't always get a good solution immediately. It usually takes some finesse to try and figure out solutions, and that requires time. Be patient, learn how KSP TOT works, and it will do great things for you.

[Hididigeigei]

I sure need to learn alot more about this thing

Attention, screenshots incoming!

So my search for the porkchop gives me this:

As said earlier, starting from an 50 degree inclined orbit would give me a good resolution, but my ship already is on an equatorial orbit so i enter it for the calculation and get this result:

This burn slings me below Kerbin and actually gets me to Eve, but requires 2500 m/s for the departure only:

I didn't pack enough fuel so i searched another, cheaper, burn and found it for 1160 m/s:

So now i am wondering why the tool gave me this weird burn in the first place, and how i can avoid it in the future.

Many thanks.

[Arrowstar]

Hididigeigei: I will get back to you tomorrow.

---

In other news, I'm pleased to announce the release of KSP TOT v1.3.2. Here's the change log:

• 10x decrease in run time on the Kepler solver. This is due to eliminating the use of fzero() for both elliptical and hyperbolic cases. Should reduce total run time by 15-20%.
  
• Eliminated a findObj() call that should reduce total runtime by 5%-10%.
  
• Enabled strict SoI search by default, which should reduce total run time by 10%-20%. (I've also seen it do nothing, though, so it's very situation dependent.)
  
• Added a selective SoI search feature which can be used to further reduce run time as requested by the user.
  
• A few other bug fixes and tweaks.
  

As usual, let me know if you have any questions.

[rasta013]

Great update Arrowstar! I've become a full convert to KSPTOT - one tool to rule them all! The use of MATLAB for this was ingenious and has given me better control over every porkchop transfer I make. Thanks for the great work and the new update looks tasty - can't wait to pound on it with a nice complicated gravity assist.

[Hididigeigei]

Hididigeigei: I will get back to you tomorrow.

Well I think i found part of the problem, and i might be entirely my fault... I did not adjust the arrival date from the initial porkchop calculation.

For my equatorial orbit and the ~202 days flight time the given burn could be the most efficient.

So this leads me to a couple of questions:

*)Is the initial porkchop Delta-V always for all possible starting orbits/inclinations?

*)If so, is there a way to display the most efficent Inclination?

*)When entering Transfer&Initial Orbit Information, i can automatically adjust the arrival date through the right-click context menu, maybe it would be nice if this also took your entered Orbit information into account?

And now to some other questions i have regarding the general use of this tool, please bear with me

*)I have not found any information regarding this: Is there a way to set the default Time System to Kerbin Time, i have to change it every time i start KSPTOT

*)Last time i tried to use "Get Orbit from KSP" it entered -69,7° for RAAN and then i got an error message, stating i could not use this value?

Thanks so far, now i have to go learn everything about the mission architect

[Drew Kerman]

Last time i tried to use "Get Orbit from KSP" it entered -69,7° for RAAN and then i got an error message, stating i could not use this value?

This is a rare occurrence, but I've seen it happen to me too. I've pointed it out to Arrowstar before but I haven't remembered to remind him about it anytime he asked for things that needed fixing. Until he puts in some code to handle this special case, you can fix it yourself by just adding 360 to the value to get the proper amount of degrees.

[Arrowstar]

It's a problem on the KSPTOTConnect side, it's easy to fix but I just need to do it.

Gaiiden, sorry for the slow response time in getting back to you, I've been busy planning some things for this weekend. I'll respond soon as I can. In the mean time, keep troubleshooting.

[Drew Kerman]

Gaiiden, sorry for the slow response time in getting back to you, I've been busy planning some things for this weekend. I'll respond soon as I can. In the mean time, keep troubleshooting.

No worries, plenty of things on my plate. Actually heard back from the ISSTracker guy, just a quick email letting me know he'll work up a proper response this week hopefully, in the meantime I sent him the latest JS code

[Drew Kerman]

New feature request! Extra option for importing orbital data - "Get Orbit for Active Vessel". This would greatly simplify things when you have a lot of craft in a save file. IMO the majority of the time when importing data from KSP you are doing it for the active vessel. Even if you don't need it for the current active vessel, switching vessels in KSP and then using the "Get Orbit for Active Vessel" option might still be preferable to scrolling through a long list of craft names using the generic import method

[Drew Kerman]

Bug report - I'm getting an error in the Mission Architect log window when I load this mission file in the latest release version. Not sure if something got corrupted or if it's a compatibility issue with slightly older mission files

[Arrowstar]

Thanks for the bug report. Can you try out this pre-release and see if it solves your problem? It works for me now.

https://dl.dropboxusercontent.com/u/29126891/KSPTOT_v133_prerelease1.zip

[Drew Kerman]

confirmed fixed. Thanks!

How about the feature? Doable?

[Arrowstar]

I saw it. It's do-able but will require some work (I need to update context menus in every application, lol). I'll try to get a v1.3.3 out this weekend with the fix I just gave you and your feature request, plus a fix for the annoying negative RAAN/Argument numbers that occasionally show up out of KSPTOTConnect.

[Drew Kerman]

(I need to update context menus in every application, lol)

Ugh, that is a pain alright. Matlab doesn't have any kind of UI control interface huh? As in you create the right-click menu as its own control that gets attached to whatever, so you only have to update the control not a dozen or so instances