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

[joshblake]

Loving KSP TOT. Thanks for making it. Tried out 0.12.2 last night, now downloading 0.12.3 --> v100 prerelease.

One thing I noticed is that the UI is very messed up when your Windows DPI setting is anything other than 100%. I'm running on a MacBook Pro with Retina Display with Win 8.1 Update, and usually have DPI set to 125%. The TOT UI had boxes in the wrong places, things not visible. At 100% it was fine though, but the setting is for the whole OS and requires a logout and login.

I like the flow of solving the optimization problems. My background as a user experience developer is nagging me to make improvements to the UI. Don't have specific suggestions yet, want to explore more.

Is the calculation engine in matlab able to be called from C++ or C#?

Edited June 2, 2014 by joshblake

[Arrowstar]

That inclusion of v-infinity in the objective function has to be considered a key improvement, I couldn't think the difference being so marked. Definitely, yes, another impressive improvement with MFMS. Another thing to thank you about for having implemented (and thanks to others for their suggestions).

Definitely yes, I like this KSP TOT version a lot. But certainly pressing you about making the MFMS isn't worth a mention, not more than the many others who contributed with their ideas.

Excellent! Well, keep playing with the MFMS as you have time. I'd like to get the v1.0.0 release out this week if there aren't any constraints or serious bugs to fix. I think I'm almost there, I just need sufficient feedback to verify that that is the case.

Loving KSP TOT. Thanks for making it. Tried out 0.12.2 last night, now downloading 0.12.3 --> v100 prerelease.

One thing I noticed is that the UI is very messed up when your Windows DPI setting is anything other than 100%. I'm running on a MacBook Pro with Retina Display with Win 8.1 Update, and usually have DPI set to 125%. The TOT UI had boxes in the wrong places, things not visible. At 100% it was fine though, but the setting is for the whole OS and requires a logout and login.

I like the flow of solving the optimization problems. My background as a user experience developer is nagging me to make improvements to the UI. Don't have specific suggestions yet, want to explore more.

Is the calculation engine in matlab able to be called from C++ or C#?

Display issues are a nagging source of problems that I don't have much control over, sadly. Can you try this suggestions below? Let me know if it helps.

Right click on your KSPTOT.exe icon, and go to Properties and then to compatibility tab, and select Disable display scaling on high DPI settings.

To answer your question: no, the MA script execution engine is not callable from outside of Mission Architect. This is also true of every other KSPTOT component: the innards aren't accessible from outside. If you have MATLAB, you can play with the source code I provide, though. That's as close as anyone can probably get.

As far as UI improvements go, I would love to hear any comments you have. I'm an aerospace engineer by trade and training, so the finer points of application development (such as making the GUI look good ) aren't normally in my toolbox. Mission Architect is, I would say, the best I've done with GUI design, but there is certainly room for improvement somewhere, I'm sure. Keep in mind that KSPTOT was a learning process for me, too, so as time went on the GUIs and code gets better (or stops sucking so much, depending on your PoV ).

Btw, does your background include graphics design? I've been looking for someone to put together a logo for KSP TOT for a long time, but I've never been able to find someone and I more or less lack the skills and the time to learn to the point that I could produce something worthwhile. If you're interested, let me know, otherwise no worries.

---

Right, I want to talk about two new features that have hit Mission Architect in the past two days while I've waited for feedback on MFMS. They are:

1. The ability to add optimizer constraints based on the state of the spacecraft immediately after an event. This should eliminate a bunch of tedious adding constraints that match the current orbit and make advancing to the next phase of the mission faster.
   
   1. 
      
   2. The menu to do this is located in either A) the Script menu up top or in the context menu when you right-click the Mission Script listbox with all the events.
      
   3. The code will ask which constraints from a list you which to add.
      
   4. Constraints are added as equality constraints with the upper and lower bounds equal to the value of that particular quantity or quantities immediately after the execution of the selected event in the Mission Script.
      
      
   5. A new "strict SoI search" setting. This setting has, at the moment, only one effect: it forces the code to check to see if the orbit of the spacecraft and the orbit of the body currently being checked for SoI crossings actually intersect (within 2 SoI radii). If the check fails, the iterative algorithm that searches for SoI crossings is skipped for that body, thus speeding up the SoI crossing check.
      
      1. A quick test seemed to show that the possible speed improvement when executing the mission script with this setting on could be upwards of 2x faster. Of course, it could also not help at all, depending on your trajectory.
         
      2. Initial tests suggest it helps much more when flying about the outer solar system. The inner solar system is too dense for this to be helpful much, it appears.
         
      3. The setting can be toggled on and off in the new Script -> Execution Settings menu. If you're having trouble getting SoI transitions, try turning this off.
         

And that's it! I've been busy this weekend. I'll put out another v1.0.0 pre-release tomorrow unless something comes up that would prevent that. Keep an eye out!

Edited June 2, 2014 by Arrowstar

[Galane]

Display issues are a nagging source of problems that I don't have much control over, sadly. Can you try this suggestions below? Let me know if it helps.

Much of good GUI application design is making sure that if the user chooses any font size other than the OS's default (especially larger) the windows don't have text becoming partialy hidden. Buttons, lists, everything should expand to fit while also not being shrinkable too much.

I've seen plenty of apps where all the elements were fixed in size so if the font size was made larger the text ran off into nowhere, and the window could be expanded or maximized while the window content stayed all piled up in one corner - and that often combined with no minimum window size so it could be shrunk to a postage stamp.

A website gone but mirrored many places (and often added to) was the "iarchitect interface hall of shame", a collection of some of the worst things ever inflicted on users in the name of "productivity" or simply just attempting to look neat.

I am not a programmer, but I do have over 30 years experience using and fixing computers and have encountered much of the good and bad and plenty of flat out "WTF is this supposed to do?" in software, and I do try to keep up with at least the basics of the how/why of software design.

Software design is related to but very different from software programming. Many of the pioneering programmers in the 70's and 80's were only actively *programming* for a short time then moved to *designing* software. They plotted out what they wanted software to *do* then handed to project over to a programming team to actually write the code to do the task per the designer's plan. Thus beginning in the mid to late 80's, the top people in big software companies were no longer directly involved in the bits and bytes of their own products. If they looked at the source code they might have an overall concept of it but they wouldn't be able to find and fix a bug or add something without going to a lot of time and effort.

It's a looooong way from when one person often wrote all or most of a whole operating system (Gary Kildall - CP/M) or a word processor (Rob Barnaby - WordStar prior to 4.0 all by himself, the first version in a few months in 8080 assembly language).

[Arrowstar]

Thanks for the notes, Galane. I'll be sure to keep them in mind.

---

Alright, folks, it's time for another pre-release! Download link is here.

This pre-release includes the following changes:

1. Optimization constraints from the current script / state log.
   
2. Strict SoI search (faster SoI search, may miss some SoI transitions)
   
3. Celestial Body Data is now stored in each Mission Architect mission plan and loaded into memory upon each mission plan
   
4. MFMS now has planetary locations for each departure/flyby located on the flyby map.
   

As usual, your comments and suggestions are most welcome. If nothing goes wrong, I'm to get the full release out Wednesday or Thursday.

Thanks!

[diomedea]

Now, please don't change your release plans for the next version, but I have another suggestion .

In case it was possible, the porkchop plot with KSP TOT main window (or another window built on purpose) could be modified so to show Delta-Vs with a selected flyby?

From a GUI perspective, it would only require to add the list of flyby bodies, between the departure and the arrival parameters. Certainly it would be a lot more difficult functionally, but I suspect some of the code already solving the MFMS algorithm could also be of use here.

[Arrowstar]

So way back in the day, immediately after I finished my first graduate level course in orbital mechanics, I wrote something called "Trajectory Optimization Tool" version 1.0 for Orbiter Space Flight Simulator. It did something very similar to what you're asking now: it basically presented a series of porkchop plots for each leg of the journey. However, what I found was this wasn't actually as useful as it first sounds. The number of calculations required with three bodies (departure, flyby, arrival) to get a decent looking grid and useful information for planning was huge. With two bodies, it already takes a few seconds (~10 s, say) to compute the porkchop plot grid. Now imagine doing that 500 times over. This is basically what TOT v1 for Orbiter did. Also, I found that looking at porkchop-type plots just wasn't that useful, because the local minima between the departure DV plot and the flyby DV plot rarely aligned, meaning you more or less had to guess about when you wanted to do things.

In short, not a bad idea as far as ideas go, but experience tells me it's not actually all that useful. (Unless you had something else in mind?)

Any thoughts on the pre-release? Anything break yet?

[PLAD]

Hello Arrowstar,

I've been using TOT for several months, it is an impressive piece of work. Flybys are my pet project these days, and I'm writing a flyby finder to plot flyby possibilities in a sort of porkchop-plot style. I use TOT to check the results my Flyby Finder (FF) kicks out and am curious as to how TOT selects the particular flight it proposes for a given flyby sequence and window. Does it search for the lowest total delta-V, that is, the boost to leave the start planet + any boosting done during a flyby + the deboost to get into orbit at the target planet, or the quickest flight within reasonable delta-V constraints? I get the impression it's a combo of delta-V and flight time.

I sometimes find cases where TOT has a problem finding a flyby, Most of the time it finds a good solution. Here are examples of each:

Javascript is disabled. View full album

I was using the version you released a few days ago, looks like you released one last night, I'll upgrade.

I'm getting a feel for just how complicated it is to catch all the things that can go wrong with a multiple-flyby search algorithm. There are too many possibilities for one person to check them all.

[Hannu]

Interesting. Which version of KSP TOT are you using?

Version was 0.12.3. I used default name and overwrote mission, but I can try to repeat it.

This is already possible. Consider that 350 degrees is also -10 degrees. So to go from -10 +/- 100, your bounds would be -110 to 90.

OK, I will try that.

[diomedea]

...

In short, not a bad idea as far as ideas go, but experience tells me it's not actually all that useful. (Unless you had something else in mind?)

Any thoughts on the pre-release? Anything break yet?

Indeed it is the minimum total DV what I like to have shown. I can easily concur minima with each body involved rarely align (or we would be able to launch Voyager-type missions quite often), but the above tells me instead of a few very good solutions, a plot would show very rare optimal ones, and large areas of suboptimal ones.

Am I correct to think that, with just one single flyby, the optimal alignment occurs only once (unless of resonances) in a time equal to the product of the synodic periods of each couple of bodies? So, in the case of a Kerbin-Eve-Duna flyby, that time would be 169 x 228 = 38532 Earth days, or more than 105 Earth years? (BTW, just the worse of all the flybys, involving the two planets with the highest synodic period in the Kerbol system). Well, I certainly don't want to wait 105 Earth years just to have that perfect flyby, so I am happy enough with some suboptimal solutions. This is what I expect to find form the kind of porkchop plot I was suggesting, showing some perfect solutions, but enough acceptable ones so to allow a choice without waiting for Jeb's grand-grand-children to follow his steps.

KSP TOT has one very good point (among many others) that wasn't told enough till now. It is a very solid program, able to keep running in the background for hours, if needed. So, yes, I believe you are right it would take a long time to draw the kind of plot I was suggesting. But if I am serious enough in planning a mission using all the tools KSP TOT provides, I should also be allowing the time to make those computations. It won't take longer than the people at JPL did in reality.

Anyway, it was and remains a suggestion. Before being the author (and therefore the only person able to make that in reality, if you like) you are also an expert in the subject. If your experience is such a feature isn't useful, that's enough: I can't pretend to know why until after I take the time to develop better knowledge on this.

Nothing broken till now with the pre-release, however I haven't tried about the new constraints yet. For me, it works nicely as expected.

[PLAD]

Diomedea,

Within a fraction of a day, 4 Kerbin/Eve synodic periods = 680 days

3 Kerbin/Duna synodic periods = 682 days

and 7 Eve/Duna synodic periods = 681 days

so Kerbin/Eve/Duna situations repeat every 681 days or so for many years. Eve's high inclination makes some worse than others, and Duna's high eccentricity makes the optimal date move forward or back from the average. The thing that makes it work is that a transfer window can be 10 or 20 days wide so some error can be tolerated. It turns out there are a lot of these coincidences in KSP, for instance Kerbin/Eve/Jool repeats every 345 days and Kerbin/Duna/Jool every 234 (though that one is rough and doesn't repeat too many times).

I wonder how often the position of all 7 planets repeats to within, say, 5 degrees...

[Arrowstar]

Hello Arrowstar,

I've been using TOT for several months, it is an impressive piece of work. Flybys are my pet project these days, and I'm writing a flyby finder to plot flyby possibilities in a sort of porkchop-plot style. I use TOT to check the results my Flyby Finder (FF) kicks out and am curious as to how TOT selects the particular flight it proposes for a given flyby sequence and window. Does it search for the lowest total delta-V, that is, the boost to leave the start planet + any boosting done during a flyby + the deboost to get into orbit at the target planet, or the quickest flight within reasonable delta-V constraints? I get the impression it's a combo of delta-V and flight time.

I sometimes find cases where TOT has a problem finding a flyby, Most of the time it finds a good solution. Here are examples of each:

http://imgur.com/a/EJmKu

I was using the version you released a few days ago, looks like you released one last night, I'll upgrade.

I'm getting a feel for just how complicated it is to catch all the things that can go wrong with a multiple-flyby search algorithm. There are too many possibilities for one person to check them all.

The flyby objective function is actually a sum of the following three components: total powered flyby delta-v + depart V_Inf + arrival V_Inf

I don't use a minimum time solution because it tends to drive the solutions into all sorts of funny geometries that don't make any sense when you actually go to execute the mission. And frankly, if you're just out to get there quickly, fly-by is not the way to go anyway. Gravity assist maneuvers trade required delta-v (lower) for flight time (higher). Well, properly planned maneuvers anyways.

I agree, there are many possibilities for each flyby, particularly when you start getting up into two, three, and four gravity assists! It explains why I feel the best approach to finding flyby maneuvers is to use a global optimization technique. It's easier to traverse the possibilities!

Version was 0.12.3. I used default name and overwrote mission, but I can try to repeat it.

Please do. Once you have recreated the problem, please post the *.mat file here for me to analyze. Thanks!

Indeed it is the minimum total DV what I like to have shown. I can easily concur minima with each body involved rarely align (or we would be able to launch Voyager-type missions quite often), but the above tells me instead of a few very good solutions, a plot would show very rare optimal ones, and large areas of suboptimal ones.

Am I correct to think that, with just one single flyby, the optimal alignment occurs only once (unless of resonances) in a time equal to the product of the synodic periods of each couple of bodies? So, in the case of a Kerbin-Eve-Duna flyby, that time would be 169 x 228 = 38532 Earth days, or more than 105 Earth years? (BTW, just the worse of all the flybys, involving the two planets with the highest synodic period in the Kerbol system). Well, I certainly don't want to wait 105 Earth years just to have that perfect flyby, so I am happy enough with some suboptimal solutions. This is what I expect to find form the kind of porkchop plot I was suggesting, showing some perfect solutions, but enough acceptable ones so to allow a choice without waiting for Jeb's grand-grand-children to follow his steps.

KSP TOT has one very good point (among many others) that wasn't told enough till now. It is a very solid program, able to keep running in the background for hours, if needed. So, yes, I believe you are right it would take a long time to draw the kind of plot I was suggesting. But if I am serious enough in planning a mission using all the tools KSP TOT provides, I should also be allowing the time to make those computations. It won't take longer than the people at JPL did in reality.

Anyway, it was and remains a suggestion. Before being the author (and therefore the only person able to make that in reality, if you like) you are also an expert in the subject. If your experience is such a feature isn't useful, that's enough: I can't pretend to know why until after I take the time to develop better knowledge on this.

Nothing broken till now with the pre-release, however I haven't tried about the new constraints yet. For me, it works nicely as expected.

So two funny things happened today:

1. I realized I had a vectorized flyby objective function which was capable of computing flyby delta-v, depart V_inf, and arrival V_inf; and
   
2. I wrote a simple function in MATLAB that can generate all possible combinations of elements from multiple sets, assuming the order of the sets remains fixed. (Namely, if set 1 is the departure times, set 2 is the delta-t to flyby 1, set 3 is the delta-t to flyby 2, etc...)
   

So basically this is all I need to have to write the code you requested. It's basically a brute-force technique to look at a bunch of flybys all at once.

Now, there are some problems here. Well, three problems namely. First, memory usage is going to get wildly out of control here. I tried generating an array of solutions with one flyby and it sucked up 300 MB (there were 1 million solutions). This was before I ran it through the vectorized objective function code. The results are going to need more memory, though I should be able to get it down to delta-v magnitudes at flyby, depart v_Inf, and arrive v_Inf.

In short, unless you're willing to rerun things a few times to segment up the memory usage into digestible chunks, you're going to need a bloody mainframe. (Mind you, this is what JPL has, so... )

Second, I'm worried about execution time. The objective function has no way of communicating its progress, it simply chugs away and is done with it. There's not really any good way to let the user know what it's doing or that it's still doing something. A million solutions might not take more than 10 seconds, but 10 million? 100 million? A billion solutions? We could be looking at minutes or hours of run time.

Third, how do I display the information I compute? If I have three waypoints (departure, flyby, arrival bodies), that's basically three dimensional data. What about four waypoints? Now I have 4D data. And so forth. I'd definitely appreciate feedback on how to display the information (sketches or whatnot would be helpful if it's complicated).

Here's my plan. I'm going to move ahead with the release of v1.0.0 as planned. However, if I/we can come up with a definitive plan to deal with these issues, or at least are willing to say that we're willing to deal with their downsides (in the case of execution time), then I'll look into writing your "porkchop plot for multi-flybys" application afterwards.

[Hannu]

This is one example. I took orbit data from KSP 0.23.5's quicksave. KSP shows that orbit goes through Jool's SOI. Periapsis is about 60000 km (above surface), orbit is prograde to Jool and inclination is few degrees. KSPTOT can not detect Jool encounter. However, when I added correction, limited dv components to +-30 m/s and made optimization for Tylo encounter, KSPTOT find solution, 4.7 m/s burn immediately after initial time. When I enter burn values in KSP it shows nearly the same orbit than KSPTOT. Also when I load new orbit from KSP as an initial state in KSPTOT, KSPTOT shows Jool and Tylo encounters correctly.

I suspect that this may have relation to large value of UT. Previous occasion happened also when UT value was larger than 300 Ms (about 12 Earth years). I could not detect problem when initial times was less than 50 Ms.

http://www.fileconvoy.com/dfl.php?id=gd28450b6171da3579995118601d8824c17b96a326

PS. Do you already have some option box or is it possible to program option to convert times to current KSP format (6h day and 426 d/year)?

[diomedea]

...

so Kerbin/Eve/Duna situations repeat every 681 days or so for many years.

.... It turns out there are a lot of these coincidences in KSP, for instance Kerbin/Eve/Jool repeats every 345 days and Kerbin/Duna/Jool every 234 (though that one is rough and doesn't repeat too many times).

...

Many thanks. I had a suspect the coincidences had to be numerous (and I hinted before at the resonance being a cause) from the findings with your tool, but certainly didn't run any analysis with the relative frequencies. You're totally right, it works because of the amplitude of each transfer window. Fields where I have more knowledge are telecommunications and cryptology, where the "amplitude" (the acceptable phase-shift) is small or null thence solutions are highly selective (or just one). Interesting, the first thought I had after reading of those coincidences above, was about the Harmony of the Worlds. Seems like KSP was engineered in a way to truly mimic our solar system, even on these levels. Or, just by coincidence...

...

Now, there are some problems here. Well, three problems namely.

First, memory usage is going to get wildly out of control here. ...

Second, I'm worried about execution time. ...

Third, how do I display the information I compute? ...

Here's my plan. I'm going to move ahead with the release of v1.0.0 as planned. However, if I/we can come up with a definitive plan to deal with these issues, or at least are willing to say that we're willing to deal with their downsides (in the case of execution time), then I'll look into writing your "porkchop plot for multi-flybys" application afterwards.

Absolutely like your plan. And I like you show interest with that "porkchop".

Sure you're right, JPL runs these things on supercomputers. One thing that encourages me, is that the raw power (and memory) of the computers they used back when planning flybys for Voyager, is quite probably only a fraction of the power (and memory) of my desktop.

Certainly, 300 MB or more seem a bit eccessive even for my desktop. I need one bit of info: while computing a "normal" porkchop, KSPTOT shows to be calculating 2500 "entities", and then sorts/refines the 20 best solutions. Like it is applying the algorithm to a initial matrix of 50x50 (I guess the matrix links to departure and arrival time, thence with the positions of the two bodies involved). For one million solutions with one flyby, that means the matrix is 100x100x100 (threee bodies involved ?). However, is the relative position of each body totally unrelated (so needs a whole time dimension to represent) or some of the "solutions" are actually impossible? When solutions are impossible, they should be pruned, no memory required other than a "discarded" marker. Definitely, to solve such kind of complex problems, some optimization strategies have to be devised. I hope to be able to think at something, will let you know if some ideas come.

About the execution time. Definitely you're right, if I am running any process for more than a few seconds, I want to have some indication of progress. Would be nice if telling how much already done against how much to do in total. If the objective function never returns a value until done, maybe a little complication could be required: would be possible to call the objective function from inside another loop, restricting the range of the objective function at each call, so it is returning quite often, then the external loop would update a progress report?

About the display of information. Any diagram (porkchop or else) is actually a limited presentation of a subset of data. 3D diagrams have the higher number of dimensions we can represent at once, though often 2D diagrams are more readable. With a porkchop the choice is in showing DeltaV or characteristic energy as a function of time (start, duration). I am interested in total duration of the trip, but having all the info stored from a range of variables, it could be possible to select other "dimensions" to show on the plot (time for each flyby, DV change for each flyby). So, I would make the "dimensions" selectable by the user, from a list of those available after the solutions are found.

[Arrowstar]

This is one example. I took orbit data from KSP 0.23.5's quicksave. KSP shows that orbit goes through Jool's SOI. Periapsis is about 60000 km (above surface), orbit is prograde to Jool and inclination is few degrees. KSPTOT can not detect Jool encounter. However, when I added correction, limited dv components to +-30 m/s and made optimization for Tylo encounter, KSPTOT find solution, 4.7 m/s burn immediately after initial time. When I enter burn values in KSP it shows nearly the same orbit than KSPTOT. Also when I load new orbit from KSP as an initial state in KSPTOT, KSPTOT shows Jool and Tylo encounters correctly.

I suspect that this may have relation to large value of UT. Previous occasion happened also when UT value was larger than 300 Ms (about 12 Earth years). I could not detect problem when initial times was less than 50 Ms.

http://www.fileconvoy.com/dfl.php?id=gd28450b6171da3579995118601d8824c17b96a326

PS. Do you already have some option box or is it possible to program option to convert times to current KSP format (6h day and 426 d/year)?

Got it, thanks for the information. I'll investigate tonight.

At the present time there are no plans to support the Kerbin/KSP time system directly. Earth time was in use up to the previous update, and it is also pretty tightly embedded into KSP TOT. That this system of time could change was completely unforseen, to be honest.

Absolutely like your plan. And I like you show interest with that "porkchop".

Sure you're right, JPL runs these things on supercomputers. One thing that encourages me, is that the raw power (and memory) of the computers they used back when planning flybys for Voyager, is quite probably only a fraction of the power (and memory) of my desktop.

Certainly, 300 MB or more seem a bit eccessive even for my desktop. I need one bit of info: while computing a "normal" porkchop, KSPTOT shows to be calculating 2500 "entities", and then sorts/refines the 20 best solutions. Like it is applying the algorithm to a initial matrix of 50x50 (I guess the matrix links to departure and arrival time, thence with the positions of the two bodies involved). For one million solutions with one flyby, that means the matrix is 100x100x100 (threee bodies involved ?). However, is the relative position of each body totally unrelated (so needs a whole time dimension to represent) or some of the "solutions" are actually impossible? When solutions are impossible, they should be pruned, no memory required other than a "discarded" marker. Definitely, to solve such kind of complex problems, some optimization strategies have to be devised. I hope to be able to think at something, will let you know if some ideas come.

About the execution time. Definitely you're right, if I am running any process for more than a few seconds, I want to have some indication of progress. Would be nice if telling how much already done against how much to do in total. If the objective function never returns a value until done, maybe a little complication could be required: would be possible to call the objective function from inside another loop, restricting the range of the objective function at each call, so it is returning quite often, then the external loop would update a progress report?

About the display of information. Any diagram (porkchop or else) is actually a limited presentation of a subset of data. 3D diagrams have the higher number of dimensions we can represent at once, though often 2D diagrams are more readable. With a porkchop the choice is in showing DeltaV or characteristic energy as a function of time (start, duration). I am interested in total duration of the trip, but having all the info stored from a range of variables, it could be possible to select other "dimensions" to show on the plot (time for each flyby, DV change for each flyby). So, I would make the "dimensions" selectable by the user, from a list of those available after the solutions are found.

Here's where the memory issue comes in. Let's say I have a single flyby plan: Kerbin - Eve - Duna. I therefore have three dimensions to the problem: Kerbin departure time, Kerbin-Eve flight time, and Eve-Duna flight time. Say I want to get 100 unique solutions along each dimension. That means that I need to have 100x100x100 = 1,000,000 solutions! Each solution is three doubles, so I have a 1000000 x 3 matrix of doubles. A double is 8 bytes, so this is ~22 MB. This is not bad, but it's also not the worst case by far. Imagine just adding 1 more flyby: we'd have 1,000,000 x 100 more solutions! To answer your question: because I use flight time, every solution is in theory feasible. The only constraints are highly non-linear, that is, the radius of flyby periapsis and all that.

I'll consider the idea about execution time, it's not a bad one.

Regarding display: So would you suggest a plot of delta-v on a 2D plane with the Y-Axis being total flight time and the X axis being departure date? Any examples on what sort of other combinations of dimensions might be useful to show?

[diomedea]

Here's where the memory issue comes in. ...

To answer your question: because I use flight time, every solution is in theory feasible. The only constraints are highly non-linear, that is, the radius of flyby periapsis and all that.

...

Regarding display: So would you suggest a plot of delta-v on a 2D plane with the Y-Axis being total flight time and the X axis being departure date? Any examples on what sort of other combinations of dimensions might be useful to show?

Display: yes, I wouldn't know how to say that better, total flight time and departure date on 2D axes, Total DeltaV color-coded. It could come useful to allow to select each body in a (multiple) flyby instead of the destination, and show total flight time up to that body and DeltaV with that flyby, but other combinations may be found working better and this is a field where I have yet to build any practical experience.

Memory. Thanks for talking about that. Flight time! I have to think a bit about that, my feeling is valid solutions must be bound within a lower and upper limit, however it is a different approach than what I believed. I had hopes there was an angle relationship, valid flybys could only be found if the phase angle of the flyby body was within some specific range of values. Should be time for me to see if there is any corollary to the Lambert's problem solution useful in this case, instead of making you lose time .

[Arrowstar]

This is one example. I took orbit data from KSP 0.23.5's quicksave. KSP shows that orbit goes through Jool's SOI. Periapsis is about 60000 km (above surface), orbit is prograde to Jool and inclination is few degrees. KSPTOT can not detect Jool encounter. However, when I added correction, limited dv components to +-30 m/s and made optimization for Tylo encounter, KSPTOT find solution, 4.7 m/s burn immediately after initial time. When I enter burn values in KSP it shows nearly the same orbit than KSPTOT. Also when I load new orbit from KSP as an initial state in KSPTOT, KSPTOT shows Jool and Tylo encounters correctly.

I suspect that this may have relation to large value of UT. Previous occasion happened also when UT value was larger than 300 Ms (about 12 Earth years). I could not detect problem when initial times was less than 50 Ms.

http://www.fileconvoy.com/dfl.php?id=gd28450b6171da3579995118601d8824c17b96a326

Alright, I did some investigative work. There was, in fact, an issue. Let this be a lesson to all who hear (err, read): finding SoI transitions is hard. Here's what happened:

The SoI search code does quite a few things in order to minimize the amount of time the code spends inside an optimizer code (here, MATLAB's fminbnd function). The optimizer code is looking for SoI transitions, but I can't have it searching through all time and space, so I have some tricks to narrow the field a bit. One of those tricks is to find out where the spacecraft orbit radius is within the apoapsis/perapsis of the target body orbit (+/- the SoI radius, of course) and restrict the search to the corresponding interval universal times (aside: I actually search though the first feasible time interval and then again on the next two revs/periods of the spacecraft too). This works great for planets that have circular-ish orbits.

In any event, in the mission plan that Hannu provided, his initial spacecraft radius was already between the apoapsis and periapsis radii of Jool. My code essentially computed the time interval to search through, saw that the initial point was before the current UT, and threw out the whole interval. Opps. Anyway, the code has been modified to simply start the search time interval at the current UT if that happens. This resolved the issue. The fix will be in the upcoming v1.0.0 release. Hopefully that's the last SoI search issue I have to deal with for a while, they are a pain...

Display: yes, I wouldn't know how to say that better, total flight time and departure date on 2D axes, Total DeltaV color-coded. It could come useful to allow to select each body in a (multiple) flyby instead of the destination, and show total flight time up to that body and DeltaV with that flyby, but other combinations may be found working better and this is a field where I have yet to build any practical experience.

Memory. Thanks for talking about that. Flight time! I have to think a bit about that, my feeling is valid solutions must be bound within a lower and upper limit, however it is a different approach than what I believed. I had hopes there was an angle relationship, valid flybys could only be found if the phase angle of the flyby body was within some specific range of values. Should be time for me to see if there is any corollary to the Lambert's problem solution useful in this case, instead of making you lose time .

So if I go with the total flight time vs. departure time, I can certainly display all the information in one plot. However, due to the way that the contour plot function in MATLAB works, I won't be able to use it until I can somehow get a uniform 2D grid of departure dates (easy) and total flight times (probably hard). I could just do what PLAD is doing in his FF (dots on a Cartesian plane), but I feel like that'd be cheating a bit and I don't want to step on his toes. Of course, the other option is to plot a series of graphs, one for each leg of the journey, such as:

1) Flight Time 1 vs Departure Time

2) Flight Time 2 vs Flight Time 1

3) Flight Time 3 vs Flight Time 2

4) etc

I could also do something like this:

1) Flight Time 1 vs Departure Time

2) Flight Time 2 vs Departure Time

3) Flight Time 3 vs Departure Time

4) etc

Any thoughts on these? I'm asking you in particular because I don't usually think about planning fly by maneuvers like this, so please suggest whatever you think would make interpreting the data easiest.

---

There is no direct phase angle relationship for flyby feasibility. The two criteria for a feasible KSP flyby are:

1) periapsis above the atmosphere, and

2) periapsis below the SoI radius.

Periapsis is a function of two things: the required flyby angle (basically the angle between the required inbound/outbound v_infinity vectors) and the gravitational parameter of the flyby body. The greater the flyby angle, the lower the periapsis. The greater the gravitational parameter, the higher the periapsis. This is why Jool and Eve make great flyby bodies (high GMs), but Duna is awful (low GM).

Now, you can figure out the required flyby angle easily enough. However, what you'll find is that your inbound v_inf vector will likely have one of two qualities:

1) It's not large enough or small enough to give the required flyby angle; or

2) It's not the same magnitude as the required outbound v_inf

#2 is correctable with some delta-v at periapsis, which is why I solve for delta-v directly in my flyby code. It's also why the the flyby delta-v is alwaysprograde/retrograde only: v_inf is directly related to orbital energy, and only prograde/retrograde burns change only orbital energy.

#1 is a lot more challenging. Consider that with a delta-v maneuver, I have an inbound eccentricity, a maneuver, and then a different outbound eccentricity. Basically, I have two competing goals: I need to find two eccentricities that give the same radius of periapsis (since that's where the delta-v occurs, if any) and I need to find two eccentricities that, when their corresponding flyby angles are summed (each divided by two since they account for half the flyby angle each), sum to the correct flyby angle. There is no closed form solution to this problem, and so I use a iterative solver. Luckily, I'm pretty sure there is only ever one solution to this problem, so it's just a matter of finding it.

Anyway, I've rambled enough. You can see that actually finding flyby maneuvers is not trivial and I've put a ton of work into not only coming up with a code that works and provides meaningful results, but that runs quickly too. You also can understand my initial hesitation at trying to write a code that could do this for multiple flybys in one go.

Please let me know if you find any bugs in the latest v1.0 pre-release. I believe I'm going to push the release date back to Sunday because some Real Life events have more or less intervened and make tomorrow through Saturday non-ideal. It's coming soon though!

Edited June 5, 2014 by Arrowstar

[diomedea]

... However, due to the way that the contour plot function in MATLAB works, I won't be able to use it until I can somehow get a uniform 2D grid of departure dates (easy) and total flight times (probably hard).

...

There is no direct phase angle relationship for flyby feasibility. The two criteria for a feasible KSP flyby are:

...

Please let me know if you find any bugs in the latest v1.0 pre-release. ...

Thank you a lot, very interesting to know those details on the flyby search algorithm.

So you made me think about those angles again, and (of course) you are right. I wasn't thinking that the outbound orbit may pass at the perihelion before encountering the destination body. If only the most direct orbital patch was considered, then the phase angle would be relevant: with any body at a phase angle lower than the flyby body, it would be impossible to get a gravitational assist in the correct direction. On the graph below there is a correct flyby on Duna, found by MFMS; and in purple I sketched what kind of orbit I had in mind.

So, the correct algorithm shows I can almost always find a valid outbound trajectory, going the longer way.

About displaying info. Certainly I don't want you to replicate what PLAD already did. I expect DeltaV to be a continuous function (where solutions exist) of time, duration. So I would like the possibility to have it plotted as a continuum. I did not consider MATLAB plotting limitations, however. Definitely agree duration would show large jumps, finding continuity may prove hard. If going by the different graphs, my preference would be with your second option, all referenced to departure time: would make easier to follow the evolution in time.

No bugs found yet (but I am doing almost exclusively flybys now, new MA features are still unknown to me). I am coming to the conclusion the single flyby sequencer is no more useful, is slower and probably still affected by that Vinf issue you corrected with the MFMS (so it outputs worse solutions than the MFMS).

[luckyhendrix]

Hello, I've installed MCR with the link provided on the first page ,but when I try to launch KPS TOT it tells me it can't find version 8.1 of MCR

MCR is installed in in my along with my matlab installation in E:\Program Files (x86)\MATLAB\MATLAB Compiler Runtime\v81

[PLAD]

Here's what caused me to choose to graph departure date versus total travel time in my plots:

Dennis Tito Inspiration Mars

So I sure don't have a claim to that approach.

Notice that it's x-axis is 25 years wide, so there are a bunch of blobs that repeat every synodic period between Earth and Mars.

donfede pointed it out in a KSP challenge, Inspiration Kerbal.

My third 'axis' (color code) is start delta-V, but total delta-V might be better. Arrowstar you have a really good question in just what should be graphed, I suppose it comes down to what people will use it for. If you're looking to get from Kerbin into orbit around an airless world cheaply then total delta-v is the most important thing, if you're ending at Eve, Kerbin, Duna or Jool then only start dV matters. If it's a free-return mission then total flight time is important. For planning multistep missions, for instance Kerbin-Eve-Duna and land on Duna, then return to Kerbin at the next Hohmann window, then arrival date at Duna is most important. For science points you might choose the path with the lowest flybys.

I'm guessing that departure date vs travel time, with total dV color coded would be the most popular?

[diomedea]

Hello, I've installed MCR with the link provided on the first page ,but when I try to launch KPS TOT it tells me it can't find version 8.1 of MCR

MCR is installed in in my along with my matlab installation in E:\Program Files (x86)\MATLAB\MATLAB Compiler Runtime\v81

On my Win 8.1 PC, for unknown reasons, KSP TOT always fails to find MCR the first time it is launched (after a machine reboot). It always succeeds the second and following times.

Therefore my suggestion is to just try it a second time, it may work if you have the same issue.

[Arrowstar]

Hello, I've installed MCR with the link provided on the first page ,but when I try to launch KPS TOT it tells me it can't find version 8.1 of MCR

MCR is installed in in my along with my matlab installation in E:\Program Files (x86)\MATLAB\MATLAB Compiler Runtime\v81

Hi, please try diomedea's suggestion below: restart your PC and try opening KSPTOT twice. Let me know if that does or does not resolve the issue. Thanks!

About displaying info. Certainly I don't want you to replicate what PLAD already did. I expect DeltaV to be a continuous function (where solutions exist) of time, duration. So I would like the possibility to have it plotted as a continuum. I did not consider MATLAB plotting limitations, however. Definitely agree duration would show large jumps, finding continuity may prove hard. If going by the different graphs, my preference would be with your second option, all referenced to departure time: would make easier to follow the evolution in time.

No bugs found yet (but I am doing almost exclusively flybys now, new MA features are still unknown to me). I am coming to the conclusion the single flyby sequencer is no more useful, is slower and probably still affected by that Vinf issue you corrected with the MFMS (so it outputs worse solutions than the MFMS).

This evening, I put some initial prototype code together that will compute flybys and regular intervals and plot the resulting delta-v as a contour plot. I tested it with a Kebin -> Eve -> Duna flyby. So, regarding display, here's what I get when I run the numbers on the flybys and plot them in a contour plot:

Because there are multiple ways to achieve each departure time and Kerbin->Eve flight time, this takes the solution with the smallest delta-v for each combination of departure time and flight time. (NOTE: That axis label should actually read "Kerbin->Eve Flight Time... whoops. The Eve -> Duna flight time is NOT in there.)

Not pretty, is it? It also doesn't strike me as particularly helpful. Sadly, I'm pretty much at the edge of my memory (4-ish GB allocated to MATLAB) generating this plot and the required data. I can't really add more resolution, and as you start adding more flybys memory usage just gets worse.

Would definitely appreciate feedback here. Thoughts on making it look better or more useful? Thanks!

Oh, no worries about Mission Architect bugs, diomedea. I've been playing with it myself and I don't think I've found anything major yet myself.

---

EDIT: I squeezed a bit more performance (and thus resolution) out of the solver and came up with something like what you see below. Note that I also adjusted the flight time bounds downwards in order to provide a smoother display.

I think it's an improvement.... Thoughts?

Edited June 6, 2014 by Arrowstar

[luckyhendrix]

Hi, please try diomedea's suggestion below: restart your PC and try opening KSPTOT twice. Let me know if that does or does not resolve the issue. Thanks!

That was it, I had to try again it works now

[diomedea]

This evening, I put some initial prototype code together that will compute flybys and regular intervals and plot the resulting delta-v as a contour plot.

...

EDIT: I squeezed a bit more performance (and thus resolution) out of the solver and came up with something like what you see below. Note that I also adjusted the flight time bounds downwards in order to provide a smoother display.

...

I think it's an improvement.... Thoughts?

Hope your machine doesn't resent to have to work so hard! The results are awesome, I really hope to be able soon to make those on my PC as well .

Definitely that second plot is much more useful and similar to what I was expecting . It is possible to see specific departure dates where most of the DV minima are concentrated, though dispersed in duration; those dates seem to come at each Kerbin-Eve synodic period, really what helps me to make sense of the plotted data.

Believe that second plot is so good, it should not require to go further. Also, if 4GB RAM were used to have that, there is not much possibility to have more if we keep working with a 32 bit MCR. But certainly, this shows the limit. Any multiple flyby plot will require a lot more RAM to keep the solutions found (just for the added time dimension). Therefore, this plotting feature may have to be limited to a single flyby (until the time JPL graciously allows to use those computers they have to make plots for KSP).

I notice the Delta-V range (color-coded) is very large (0 - 45 Km/s). I get you had to make the range so large or most of the areas in the plot would be blank (no solution), and it is definitely helpful to see all areas plotted, rather than left blank. However, the best solutions are all at the very bottom of that range, and color does not really discriminate among them. I believe that second plot is much better than the first also because it makes colors different for those solutions.

One thought: would be possible to assign colors along an exponential scale rather than a linear one for DV? Instead of evenly spaced ticks every 5 or 10 Km/s, to have evenly spaced ticks at each power of 10 (10^N, and I would make intermediate ticks every 3*10^N: e.g. ticks at 30, 100, 300, 1000, 3000, 10000, 30000, 100000 m/s).

One feature would be required next: possibility to zoom in a particular area of the plot (therefore, with stricter limits in departure dates and durations), and recompute solutions only falling within that area, so to generate a highly defined plot for that area (the zoom in feature already with KSP TOT porkchop plot enlarges the plot, but still draws the contour based on the points already stored; instead I would like to generate more points to have more defined contour lines). Or, the possibility for the user to set not only the earliest date for departure and arrival (so to define the left-down corner of the plot) but also the latest dates to be plotted (and so, the right-up corner). Or even both the above features, as some users may like more the first and others the second.

[Arrowstar]

Hi everyone!

This evening I'm pleased to announce the release of KSP Trajectory Optimization Tool (KSP TOT) v1.0.0!

This release has been a long time coming. Records indicate that I released the first version of KSP TOT about a year ago. What a ride it has been! I realized not too long ago that KSP TOT has really matured recently and the code base is solid and ready to ditch the "0.x" label that indicates a beta. Tonight's v1.0 release is the realization of over 1.5 years of planning, testing, frustration, sweat, and blood (and over 500 hours of development time).

New features for KSP TOT v1.0 are as follows:

• New Application: Multi-Flyby Maneuver Sequencer. Replacing the Flyby Maneuver Sequencer, this application is capable of generating flyby trajectories around an arbitrary number of celestial bodies. It's also 100x times faster than FMS and tends to generate solutions which are more balanced and achievable. Really, try it out, it's a real work of art and arguably the best set of code I've ever written.
  
• Mission Architect has received a number of upgrades:
  
  • GUI now actively indicates when no errors are present in the execution of the missions script.
    
  • It is not possible to generate orbit constraints based on the current state of the mission and its associated events. See "Script" menu.
    
  • Two new script execution settings (see "Script" menu):
    
    • Strict SoI Search is an attempt to speed up the execution time of long missions by restructuring the way high->low SoI transitions are found. It can, in some cases, speed up execution and optimization by a factor of 2x.
      
    • Parallel Script Optimization allows users to take advantage of MATLAB's sophisticated parallel computing abilities to speed up the optimization of the mission script in most cases.
      
    • Both of these options default to "off" but are available in the "Script" menu.
      

    [*]A number of improvements to SoI search in general that increase its robustness.

    [*]Many, many bug fixes and improvements.

  [*]A number of other minor fixes and improvements to various other elements of KSP TOT.

It's been a pleasure to develop this application for the KSP community and I'm really happy it's received its fair share of exposure recently (particularly compared to most external "calculator" applications).

Amusingly, v1.1 is probably only a few weeks away. It will feature a new application that generates "porkchop-like" plots for flyby maneuvers. It's a slower but more surefire way to develop flyby trajectories. Thanks to user diomedea for the idea!

As usual, please let me know if you find any bugs or have any suggestions that will improve the application. Thanks! Happy orbiting.

[Arrowstar]

Definitely that second plot is much more useful and similar to what I was expecting . It is possible to see specific departure dates where most of the DV minima are concentrated, though dispersed in duration; those dates seem to come at each Kerbin-Eve synodic period, really what helps me to make sense of the plotted data.

Believe that second plot is so good, it should not require to go further. Also, if 4GB RAM were used to have that, there is not much possibility to have more if we keep working with a 32 bit MCR. But certainly, this shows the limit. Any multiple flyby plot will require a lot more RAM to keep the solutions found (just for the added time dimension). Therefore, this plotting feature may have to be limited to a single flyby (until the time JPL graciously allows to use those computers they have to make plots for KSP).

Noted. That's good to hear! I will probably leave the ability to plot multiple flybys, but you can bet I'll be checking memory usage aggressively as the application runs and attempting to terminate graceful if something bad happens...

I notice the Delta-V range (color-coded) is very large (0 - 45 Km/s). I get you had to make the range so large or most of the areas in the plot would be blank (no solution), and it is definitely helpful to see all areas plotted, rather than left blank. However, the best solutions are all at the very bottom of that range, and color does not really discriminate among them. I believe that second plot is much better than the first also because it makes colors different for those solutions.

One thought: would be possible to assign colors along an exponential scale rather than a linear one for DV? Instead of evenly spaced ticks every 5 or 10 Km/s, to have evenly spaced ticks at each power of 10 (10^N, and I would make intermediate ticks every 3*10^N: e.g. ticks at 30, 100, 300, 1000, 3000, 10000, 30000, 100000 m/s).

It's an interesting idea. I'm not sure how MATLAB handles colorbars, but I can look into it. It might be possible. It may also be necessary to simply filter the results more. Thanks for the thought, though, I'll keep it in mind!

One feature would be required next: possibility to zoom in a particular area of the plot (therefore, with stricter limits in departure dates and durations), and recompute solutions only falling within that area, so to generate a highly defined plot for that area (the zoom in feature already with KSP TOT porkchop plot enlarges the plot, but still draws the contour based on the points already stored; instead I would like to generate more points to have more defined contour lines). Or, the possibility for the user to set not only the earliest date for departure and arrival (so to define the left-down corner of the plot) but also the latest dates to be plotted (and so, the right-up corner). Or even both the above features, as some users may like more the first and others the second.

Definitely! I really like the idea of zoom-recompute. I'll put a checkbox on the GUI, though, to enable this feature, as recomputing is CPU/memory intensive, as I've said. I will also allow bounds for flight time, that's not a bad idea as well. I'll probably also have a "number of points per axis" input that users can use to adjust memory usage (less points per axis -> fewer calculations -> less memory usage). Unless you think this might be too complicated for basic users?

I don't have any additional progress to show on this tonight as I was concentrating on getting KSPTOT v1.0 out. But I'll start again tomorrow and see what progress can be made. Thanks!