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

[The Lone Wolfling]

Thanks! Please let me know what you like and dislike so I can make improvements as necessary.

Dislike: 388MB runtime. But there's no real way around that other than rewriting it in another language. Would it be alright for me to have a go at porting it to Python?

Like: pretty much everything else.

It might be possible for me to perform some sort of sensitivity analysis. To be honest, though, I guess I don't see the purpose. True, it would show you when your "long" burn might significantly change your answer, but this is KSP... aren't we all just going to go for it anyway?

Well, yes, but it would still be nice to have!

I've added the apses to the orbit transfer map tonight. I'll have to think about the nodes, because you need to pick the correct plane for them to make sense. There's a fair bit of thought, design, and math that needs to go into plotting those. Honestly, they will probably come about later, if only because they're a very small feature that requires a lot of work.

The thing about ascending/descending nodes is that they provide another data point as to if you are on the right orbit, assuming that you aren't using MechJeb or something similar.

Another suggestion if you get those implemented is a mouseover showing time to each of them - that way it again gives you another data point as to if you are on the right track.

Indeed. I apologize, I wasn't intending to come across as cheeky. It just struck me that what you were asking for is exactly what the porkchop plot is for in the first place.

In any event, I think you're right and some sort of indication of an optimized departure/arrival date/time is a good idea. Tonight I wrote the code to actually perform the optimization. It's just a matter of how to let the user call that. Right now I have it tied to the porkchop plot generator method: it generates the plot, then finds the optimal point within the plot. (Or, really, within 1 synodic period of the best point in the porkchop plot.) Do you have any suggestions on how I might present this "optimized" information to the user? I'm not sure I can use the data cursor thing I've got showing the best point computed for the porkchop plot, but I'll investigate anyway. Assuming that's a no-go, any thoughts? I'm thinking I either write it to the text box below the porkchop plot or bring up a pop-up box with the times in it. Would either of those be acceptable?

If it's possible to use the data cursor, pre-populate the data cursor with the "best" datum.

Otherwise, I'd suggest adding it as a box to the departure burn calculator - "Optimize delta-v" or something similar. Or alternatively, have it pre-populate the departure burn calculator with the lowest global delta-v.

Thanks for the suggestion! I'll consider it, though I have to admit, the plot is getting pretty cluttered with just the orbits and transfer orbit periapse/apoapse. We'll see.

Perhaps as an option?

I implemented the following requested features tonight:

• Find optimal departure for given arrival;
  
• Add transfer orbit periapse & apoapse to the orbit plot; and
  
• Find optimal arrival/departure on a generated porkchop plot (partial: result of optimization run needs to be displayed to user still).
  

Yay, yay, and yay.

Tomorrow's agenda is the following request:

• Find earliest arrival for provided delta-v. Btw, I'm assuming that the delta-v provided is for the full round trip: departing one place and arriving at another. If I just use the departure dv, that could make things a bit optimistic in some cases. Do you guys have any thoughts on this? Which delta-v (the departure + arrival delta-v or just the departure delta-v) would be more intuitive for you?
  

Yay! I'd prefer both options, actually. Departure delta-v is good for fly-bys and aerobraking, total is good for most other missions.

EDIT: Also, see below:

Allow either via a toggle setting. For destinations with atmospheres, departure only makes the most sense, but for destinations without, you care about the total.

I'm also going to rewrite the Lambert solver at some point using the code I gave to R4m0n for MechJeb (yep, that's my Lambert solver) as a base.

o.O

[Arrowstar]

Dislike: 388MB runtime. But there's no real way around that other than rewriting it in another language. Would it be alright for me to have a go at porting it to Python?

Like: pretty much everything else.

I'm glad you like it! I'd rather you didn't port it to anything at the moment. The application is still under heavy development and you'd be chasing a moving target. I'd rather not have conflicting versions of my tool out "in the market" until things firm up. Thanks for the offer, though! I may take you up on it in the future if you're still willing.

(Note: the license actually forbids derivative works, of which a port would be, at the moment for this reason.)

Well, yes, but it would still be nice to have!

True. I'll see what I can do.

The thing about ascending/descending nodes is that they provide another data point as to if you are on the right orbit, assuming that you aren't using MechJeb or something similar.

Another suggestion if you get those implemented is a mouseover showing time to each of them - that way it again gives you another data point as to if you are on the right track.

Perhaps as an option?

Yeah, I'll get ascending/descending nodes on the map at some point. I can see how they're valuable now. It'll be a bit in the future, but they'll come. I'll probably have checkboxes in the departure information GUI that you can use to turn them on and off at will.

If it's possible to use the data cursor, pre-populate the data cursor with the "best" datum.

Otherwise, I'd suggest adding it as a box to the departure burn calculator - "Optimize delta-v" or something similar. Or alternatively, have it pre-populate the departure burn calculator with the lowest global delta-v.

When you say adding it as a box to the departure burn calculator, do you mean as a button or as part of those context menus that come up when you right-click the departure and arrival time fields?

Yay! I'd prefer both options, actually. Departure delta-v is good for fly-bys and aerobraking, total is good for most other missions.

Done! I've implemented an option that dictates the behavior of the solvers (that is, which delta-v they attempt to minimize) globally across the application. The one setting impacts all calls to the delta-v minimization code, so be careful and change as needed...

o.O

Err, I don't know what you mean? You are surprised I wrote the MechJeb Lambert solver?

[Arrowstar]

Time for a nice development update! A bunch of new features have been added in the past two days.

Starting basic, I've added a data cursor that pops up after generating a porkchop plot. It displays the best point on the graph in terms of delta-v. (Which delta-v will be discussed below.) This is the same data cursor you could manually add before, I'm just pre-setting it to a particular point on the plot. Note that it now also shows transfer duration.

The position of the data tip is also passed in the departure calculation screen as initial inputs for departure/arrival time.

I've also added the synodic period between the two selected bodies below the depart/arrival parameters.

I've also added a global optimization feature that tries to find the best departure/arrival time. This is currently run when the porkchop plot is generated, but I will likely make it accessible elsewhere. The output doesn't do anything at the moment, I still need to figure out where to go with it. But it does work, it's just a design problem at this point.

Previously, I mentioned that the optimizer will attempt to minimize a delta-v of a type you select when you run the porkchop plot generator. Which delta-v you minimize is based on what you select in this box:

The default is departure+arrival delta-v. But if you going to a place where you plan to aerocapture into orbit, you can select departure delta-v only, and it will ignore the delta-v needed to arrive in orbit at the destination. I also put arrival delta-v there for completeness.

This option impacts the entire application (except the data cursor, which shows dv based on which porkchop plot you're looking at), so make sure you change it if you need to.

Moving to the departure calculation screen:

Per a request, I added an option to compute the best departure for the input arrival time. This is in addition to the ability to find the best arrival time based on the input departure time.

I also added the ability to find the earliest departure for an input delta-v:

When you select that, a box comes up that asks you for a delta-v magnitude. Note that if you enter a delta-v that is too small, the solver will kinda freak out and spit out an error. It will still provide an answer, it just won't be very good (most likely).

Finally, the transfer orbit map has gotten a minor addition in the form of markers for apoapse and periapse. Markers for ascending and descending node will come later. A marker for the location of your destination planet at the departure burn was also added.

Finally, the last change I made was to go through and fix/update/add to the list of bodies that the program knows about. I've now got all the moons of Jool in there, as well as corrected orbital parameters for the main planets.

My next major task is to rewrite the Lambert solver (as I said earlier) and then we'll go from there.

What do you guys think?

[Arrowstar]

I've just uploaded version 0.5. It will be online shortly. Feedback is appreciated as always.

[Arrowstar]

I'll just leave this here... *whistles*

[The Lone Wolfling]

Version 5 looks awesome!

Some comments/queries/concerns, though, as usual:

• For the various calculation windows, would it be possible to add estimates of the remaining time until the calculation is complete?
  
• On the "find earliest arrival for delta-v" window, could you also search to see if delaying the launch might make an earlier arrival feasible?
  
• If you hit "Select Departure/arrival date", and then exit the main window, it crashes instead of exiting cleanly.
  
• The console window still shows v0.1.
  
• On the "find earliest arrival for delta-v" window, instead of using a value in the options, could you use the plot data type? It seems to me to be a little more intuitive that way.
  
• Can you add an option to enter in the orbital parameters of a spacecraft around the transfer central body, and calculate transfer burns from said orbit? (Say, my spacecraft currently in an odd inclined orbit around the sun after a failed aerocapture...)
  
• What are the "swirls" in this plot: ?
  
  • 
    

  [*]On the "find earliest arrival for delta-v" window, if there aren't any feasible options, could you still select the best trajectory?

  [*]The scroll wheel currently always zooms towards the center of the porkchop plot, and doesn't zoom at all in the transfer orbit view.

  [*]Would it be possible to calculate the time to start multipart burns? (Or rather, when your spacecraft doesn't have enough thrust to do the burn in a single orbit, so you do a burn into an elliptical orbit, then next time around do the final burn.)

[Arrowstar]

Version 5 looks awesome!

Thanks, I'm glad you're enjoying it!

• For the various calculation windows, would it be possible to add estimates of the remaining time until the calculation is complete?

  
  

I believe so, yes. Let me investigate though. It may be a bit of a hack since that information (time elapsed) is not natively available in the function I use to generate those. But I will see what I can do.

EDIT: Yup, not only is it possible but I've just implemented it. In the process I cleaned up some calls to the MATLAB multistart solver and put them in a common function for easy access later. I also standardized the progress bar windows across all computation functions (they all use the same function now, so they all look the same). It's a small improvement that really adds a bit of polish on things.

• On the "find earliest arrival for delta-v" window, could you also search to see if delaying the launch might make an earlier arrival feasible?

  
  

So basically what you want is a "minimize time of flight" function that is constrained by delta-v and varies either arrival time or departure/arrival time?

• If you hit "Select Departure/arrival date", and then exit the main window, it crashes instead of exiting cleanly.

  
  

Fixed. I've basically told the code to look for errors when doing so and throw up a nice message box with the error message MATLAB gives if something goes wrong.

• The console window still shows v0.1.

  
  

Fixed. Thanks for noticing.

• On the "find earliest arrival for delta-v" window, instead of using a value in the options, could you use the plot data type? It seems to me to be a little more intuitive that way.

  
  

I thought about this, but decided against it. I don't want to force people to remember to set the plot type before they go into that window. My thought was this: even if you're only interested in optimizing the departure dv, you may still be interested the arrival dv as well, because it influences your aerocapture or whatnot. Hence, I made a separate option so people could have flexibility.

• Can you add an option to enter in the orbital parameters of a spacecraft around the transfer central body, and calculate transfer burns from said orbit? (Say, my spacecraft currently in an odd inclined orbit around the sun after a failed aerocapture...)

  
  

One day I will have an option where you can alter and add to the celestial bodies in the application. Part of this is their orbital parameters. When I get this done, you could always enter your spacecraft's parameters here and then use it like you would any other planet/moon in the game.

• What are the "swirls" in this plot:
  

  • 

  
  

Those are the boundary between the Type I (short way, transfer angle < 180 deg) and Type II (long way, transfer angle > 180 deg) cases. The physics works out that you typically get this high delta-v boundary between the two sets of cases. As an example, see this JPL-generated porkchop plot.

• On the "find earliest arrival for delta-v" window, if there aren't any feasible options, could you still select the best trajectory?

  
  

I believe it's doing this already, actually.

• The scroll wheel currently always zooms towards the center of the porkchop plot, and doesn't zoom at all in the transfer orbit view.

  
  

On the departure information window, those are 3D plots. MATLAB has a bug in it where zooming in on 3D plots physically makes the axis larger, which means it starts to cover up other elements of my GUI. Hence, zooming has been disabled on those plots until I can figure out a work-around (not likely, I've been trying for years).

• Would it be possible to calculate the time to start multipart burns? (Or rather, when your spacecraft doesn't have enough thrust to do the burn in a single orbit, so you do a burn into an elliptical orbit, then next time around do the final burn.)

  
  

Not immediately possible but on the radar. I am going to do a type of "burn planner" tool within KSP TOT that will compute the burns and whatnot based on information you provide about your vehicle. Part of that could be a "multi-burn" setup where you put a cap on delta-v per burn or specify the number of burns to break things up into, yes. I'll make a note.

Thanks for the great suggestions! Btw, all bug fixes I've specified above will show up in v0.6...

----------------------------------------------------

Now for something completely different!

I thought I'd share a picture from my trip to Jool yesterday. I used KSP TOT to plan the journey (of course) and after plunking burn times and delta-v info into MechJeb's maneuver node editor, this is the transfer I got in the game.

I don't know about you guys, but nailing the transfer on the first pass without having to modify any of the numbers KSP TOT gave me is pretty awesome, I think.

Edited June 29, 2013 by Arrowstar

[Arrowstar]

Another update:

In addition to some of the work I described above, I also added the line of nodes to the transfer orbit plot:

By rotating the image, it's easy enough to see which node is ascending and which is descending. I don't want to put markers on the map because things are getting pretty cluttered, so I hope this line is sufficient for everyone's purposes.

As usual, suggestions and comments welcome.

[tavert]

Arrowstar, I see your Lambert solver is a binary mex file. Based on the I/O, it looks like you're using http://www.mathworks.com/matlabcentral/fileexchange/26348-robust-solver-for-lamberts-orbital-boundary-value-problem ? I believe you need to reproduce the BSD license of that file somewhere in your documentation to redistribute it in binary form, unless (maybe) you happen to be the original author.

I was going to play around with this a bit and see if switching to a real solver rather than fmincon could speed things up noticeably, but it seems the license server is down at the moment for my installation of Matlab that has the Global Optimization Toolbox. And I can't profile or modify anything using the MCR.

The singularity at 180 degree transfer angle goes away if you calculate a 2-burn ecliptic projection solution, like alexmun implemented in his JavaScript web-app porkchop plotter.

[The Lone Wolfling]

So basically what you want is a "minimize time of flight" function that is constrained by delta-v and varies either arrival time or departure/arrival time?

No.

What I want is a refinement of the current solver. Given an amount of delta-v and a minimum start time, find the earliest possible arrival time.

In some cases delaying the launch can actually make the earliest possible arrival (given an amount of delta-v) earlier. Currently, the solver doesn't search for this.

I thought about this, but decided against it. I don't want to force people to remember to set the plot type before they go into that window. My thought was this: even if you're only interested in optimizing the departure dv, you may still be interested the arrival dv as well, because it influences your aerocapture or whatnot. Hence, I made a separate option so people could have flexibility.

I disagree with this, but it's your program, after all. It's just a pain to have to go into the settings to double-check that you're solving for the right thing.

Those are the boundary between the Type I (short way, transfer angle < 180 deg) and Type II (long way, transfer angle > 180 deg) cases. The physics works out that you typically get this high delta-v boundary between the two sets of cases. As an example, see this JPL-generated porkchop plot.

I wasn't aware of the periodicity of the delta-v boundary. Interesting...

The singularity at 180 degree transfer angle goes away if you calculate a 2-burn ecliptic projection solution, like alexmun implemented in his JavaScript web-app porkchop plotter.

...And it goes away with a 2-burn solution? Weird.

I believe it's doing this already, actually.

...derp. I had the starting parameters set to the global minimum, so of course it wasn't changing.

On the departure information window, those are 3D plots. MATLAB has a bug in it where zooming in on 3D plots physically makes the axis larger, which means it starts to cover up other elements of my GUI. Hence, zooming has been disabled on those plots until I can figure out a work-around (not likely, I've been trying for years).

Weird bugs ahoy!

Now for something completely different!

[snip]

Neat! Always nice to see things go according to plan.

[Arrowstar]

Arrowstar, I see your Lambert solver is a binary mex file. Based on the I/O, it looks like you're using http://www.mathworks.com/matlabcentral/fileexchange/26348-robust-solver-for-lamberts-orbital-boundary-value-problem ? I believe you need to reproduce the BSD license of that file somewhere in your documentation to redistribute it in binary form, unless (maybe) you happen to be the original author.

That's the one. Thanks for pointing this out. I had this solver on my hard drive from another personal project a while ago and just grabbed the binary. I've added the license text file to the KSP TOT ZIP file.

I was going to play around with this a bit and see if switching to a real solver rather than fmincon could speed things up noticeably, but it seems the license server is down at the moment for my installation of Matlab that has the Global Optimization Toolbox. And I can't profile or modify anything using the MCR.

It's worth noting that I am using a "real solver." Indeed, the algorithms behind fmincon are quite sophisticated. What you mean is that you'd like to switch to a global solver... which is fine. I'm not using one of those here because I spent two years of graduate school working on this problem with MATLAB's genetic algorithm solver (simulated annealing is garbage for this.) It worked... okay, but it's very CPU intensive. As only as I only have 1 or 2 design variables to adjust (such as depart and arrival time) I'd rather just use the very quick fmincon and MultiStart, which works well for what I'm doing.

That said, if you make progress, please do let me know about it. I'd be happy to see!

The singularity at 180 degree transfer angle goes away if you calculate a 2-burn ecliptic projection solution, like alexmun implemented in his JavaScript web-app porkchop plotter.

Noted. I'll see what I can do.

No.

What I want is a refinement of the current solver. Given an amount of delta-v and a minimum start time, find the earliest possible arrival time.

In some cases delaying the launch can actually make the earliest possible arrival (given an amount of delta-v) earlier. Currently, the solver doesn't search for this.

Okay, so it sounds like you actually want to minimize time of flight while allowing the code to shift the departure time to help minimize it further. I can do this. Unless, of course, I'm still not understanding, in which case maybe you could illustrate with an example.

I disagree with this, but it's your program, after all. It's just a pain to have to go into the settings to double-check that you're solving for the right thing.

Yesterday I added notes in the relevant GUIs to help alleviate this.

Thanks for the suggestions/tips tavert, Lone Wolfling. Very much appreciated!

[tavert]

It's worth noting that I am using a "real solver." Indeed, the algorithms behind fmincon are quite sophisticated. What you mean is that you'd like to switch to a global solver... which is fine. I'm not using one of those here because I spent two years of graduate school working on this problem with MATLAB's genetic algorithm solver (simulated annealing is garbage for this.) It worked... okay, but it's very CPU intensive. As only as I only have 1 or 2 design variables to adjust (such as depart and arrival time) I'd rather just use the very quick fmincon and MultiStart, which works well for what I'm doing.

You are at least telling it to use the interior-point algorithm, which is leaps and bounds better than the lousy old default active-set fmincon solver. I'm just referring to the local solver here - I regularly work with large-scale sparse problems with tens of thousands of variables, and fmincon just doesn't cut it. The state of the art is solvers like Ipopt, which is basically the reason Mathworks went and wrote an interior-point algorithm in the first place. For big problems, it can be an order of magnitude difference in performance, if not more. But I guess for these purposes you have very small problems, and you care more about the solver doing finite differences for you to get the gradient and Jacobian. Wonder if there are any redistributable auto-differentiation tools for Matlab that are good enough to be worth using...

[Arrowstar]

You are at least telling it to use the interior-point algorithm, which is leaps and bounds better than the lousy old default active-set fmincon solver. I'm just referring to the local solver here - I regularly work with large-scale sparse problems with tens of thousands of variables, and fmincon just doesn't cut it. The state of the art is solvers like Ipopt, which is basically the reason Mathworks went and wrote an interior-point algorithm in the first place. For big problems, it can be an order of magnitude difference in performance, if not more. But I guess for these purposes you have very small problems, and you care more about the solver doing finite differences for you to get the gradient and Jacobian. Wonder if there are any redistributable auto-differentiation tools for Matlab that are good enough to be worth using...

Ah indeed. Yes, one of the most important features of fmincon (for me) is the auto-differentiation. If I didn't have that, I'd either have to write my own, which I grant you would not be too terrible, or try to find analytic gradients for my problem, which I suspect don't exist. It makes my life a lot easier that MATLAB can do this for me, and in a (fairly) sophisticated way.

Out of curiosity, what do you do that has you working with numerical problems such as the one you described?

[tavert]

Well fmincon isn't doing auto-diff, it's numerical finite differences which works okay for small problems but just plain sucks for big stuff. Technically this isn't the solver (many state-of-the-art solvers require the user to provide gradients), it's the optimization modeling environment. Matlab isn't quite up to par with what AMPL, OpenOpt, etc. can provide.

Optimization-based control. Large-scale real-time optimization of HVAC energy efficiency across an entire large commercial building, for example.

[The Lone Wolfling]

Okay, so it sounds like you actually want to minimize time of flight while allowing the code to shift the departure time to help minimize it further. I can do this. Unless, of course, I'm still not understanding, in which case maybe you could illustrate with an example.

Again, nothing to do with time of flight. Here's an example:

I want to find the earliest Moho arrival time after the start of the game, that requires <=7190 m/s delta-v.

Earliest departure time = 0, departure body = Kerbin, arrival body = Moho. Compute porkchop plot. Compute departure burn. Departure time = 0. Find earliest arrival for delta-v: 7.19km/s.

Current result: arrival time: 2645496.8329s, departure time 0s, delta-v 7.19km/s.

Wanted result: arrival time 2605640.6069s, departure time 252538.0995s, delta-v 7.19 km/s.

(Wanted result found by alternating delta-v and optimal departure time.)

Almost 40,000s (11h) earlier arrival time. Not a great improvement in this case, but it's a simple case. Yes, it does reduce the time of flight, but that is incidental. (A time of flight minimizer would also be useful, but that isn't what I'm asking for here.)

Yesterday I added notes in the relevant GUIs to help alleviate this.

Could you add an option in the enter max delta-v GUI to change between solver types? This helps, but it's the act of having to switch between different windows constantly that makes it tedious for me.

Also, minor tweak: could you make it so when the program starts it starts with Kerbin selected as the departure body, and Duna as the arrival body? Currently it starts with Moho as both. Sane defaults are always good

[TheProdigy]

This looks amazing! Not sure if this was already asked.

But do you have plans to make it possible to plan gravity assists/slingshots?

[Arrowstar]

Again, nothing to do with time of flight. Here's an example:

I want to find the earliest Moho arrival time after the start of the game, that requires <=7190 m/s delta-v.

Earliest departure time = 0, departure body = Kerbin, arrival body = Moho. Compute porkchop plot. Compute departure burn. Departure time = 0. Find earliest arrival for delta-v: 7.19km/s.

Current result: arrival time: 2645496.8329s, departure time 0s, delta-v 7.19km/s.

Wanted result: arrival time 2605640.6069s, departure time 252538.0995s, delta-v 7.19 km/s.

(Wanted result found by alternating delta-v and optimal departure time.)

Almost 40,000s (11h) earlier arrival time. Not a great improvement in this case, but it's a simple case. Yes, it does reduce the time of flight, but that is incidental. (A time of flight minimizer would also be useful, but that isn't what I'm asking for here.)

Okay, I understand what you want. I'll see about implementing this tomorrow. Sorry for the delay, I've been having too much fun with the Kethane 0.72 release.

Could you add an option in the enter max delta-v GUI to change between solver types? This helps, but it's the act of having to switch between different windows constantly that makes it tedious for me.

Also, minor tweak: could you make it so when the program starts it starts with Kerbin selected as the departure body, and Duna as the arrival body? Currently it starts with Moho as both. Sane defaults are always good

1) I'll look into it. Not sure how hard it'll be to keep everything synced up, but will investigate.

2) Yes, I need sane defaults. I actually had it doing this originally, but I ran into a bug and the workaround was to eliminate the default setting. I've got an idea to fix it though, will try to get to it tomorrow or this weekend.

This looks amazing! Not sure if this was already asked.

But do you have plans to make it possible to plan gravity assists/slingshots?

I'm working on that right now. The math is all figured out and coded up, but the problem is still very tricky to solve. Not sure at this point if it will every make it into the main program. Keep checking this space for more updates.

[tavert]

Regarding gravity assists, is there anything worth using or learning from http://www.mathworks.com/matlabcentral/fileexchange/29272-skipping-stone-an-interplanetary-space-mission-design-tool ? Written by the same guy as the Lambert solver.

[Arrowstar]

Hi everyone,

Just a quick development update this morning.

I plan on getting 0.6 out the door tonight if possible. This is a minor update that includes the following:

-Lone Wolfling's "minimize arrival time" with variable departure time optimizer;

-The ability to input arithmetic statements (2+2 for example) into numeric text boxes and have them evaluate (so if you enter 2+2, the box changes to read 4)

-I am going to change the "optimizer departure time for given arrival" to use the current input arrival as a lower bound for the optimizer. This way you don't end up with solutions in the past if you don't want them.

-Other minor bug fixes and enhancements

My plan is for 0.7 to be the "flyby optimizer" release. I've been spending a lot of time lately on getting this to work (hence the slowdown in my posting and releasing new versions of this), and I think I've got it at the point where it's at least release-able. To be honest, my research into all of this suggests that fly-bys aren't as useful as one might think, but I'll provide the functionality and let people mess around with it anyway.

Was there anything else quick you guys wanted for 0.6? If I can whip it up in a few hours tonight, I'll include it.

[Arrowstar]

Hi everyone,

I'm happy to announce the release of v0.6 (main posting pending update shortly). This is a relatively minor release I'm using to get some basic outstanding features out of the way before I go ahead and implement my experimental "fly-by" solver code (the math of which currently functional - basically it needs a GUI.)

New functionality includes:

-Lone Wolfling's "minimize arrival time" with variable departure time optimizer;

-The ability to input arithmetic statements (2+2 for example) into numeric text boxes and have them evaluate (so if you enter 2+2, the box changes to read 4)

-"Optimize Departure for Input Arrival" now uses the input departure time as a lower bound. Useful for when you're in the middle of a game and you clearly can't go back in time to find that "better" solution.

-Some bug fixes and tweaks under the hood.

Most of my work the past week has concentrated on getting the fly-by math worked out and working prototype code implemented, which is why this release is pretty minor. Nevertheless, I think it's a improvements, while small, are helpful.

As always, comments, questions, and questions are welcome. Please also let me know if you find a bug or something works not as expected.

Thanks!

[Arrowstar]

Hi guys!

I wanted to offer a sneak peak of where they fly-by optimizer is at right now. I've been looking at a number of trajectories to serve as examples, but the one I like the best is the Kerbin-Eve-Moho flight plan. As we know, flying to Moho is usually pretty expensive. The one KSP delta-v map I looked at (not terribly accurate, but it'll do here) suggests 2.2 km/s == 2200 m/s.

This evening, I asked my solver to find me a cheaper trajectory to get to Moho by using Eve as a fly-by. Here's what it came up with. (Red trajectory is the to-Eve trajectory, blue is the to-Moho trajectory.)

And here's what the trajectory around Eve looks like.

The delta-v number of there is the amount of delta-v that the s/c needs to apply at periapse of the fly-by in order to hit the outgoing trajectory (and thus the target planet). In this case, the solver found a great ~0 m/s delta-v trajectory. The periapse around even was ~800 km in radius.

Here's some other relevant information that the solver spits out.

Departure DV = 0.852133165506862 km/s

Arrival DV = 4.71245869089299 km/s

Okay, now I realize that the arrival dv is a bit high. The solver is only looking to optimize the departure and fly-by delta-v right now. I found that throwing in the arrival delta-v resulted in a poor departure and a poor arrival. This way, at least leaving is very easy. When I get things put together this weekend, I'll include the option to add arrival delta-v to the optimizer, but no promises on how that will work out when you actually go to run it.

I'm still working on GUI design at this point, but that should be straight-forward. Please note that, despite my best efforts and about a week's worth of work, this is still going to be a challenging tool for the average user to use. The PSO (particle swarm optimizer) I'm using doesn't get consistently good results (though I'll be the first to say it does really well most of the time!), and frankly, some trajectories are just going to be stupid. (Flyby around Dres? How about no.) This will require some knowledge of what you're ultimately going for unless you have days of CPU time for the solver to go through every possible trajectory (an impossibility) to find the good stuff. And as I said, some trajectories will either not be possible or cost much more than their equivalent direct Lambert arc siblings.

Anyway, it's all in good fun. I may allow the use of two fly-by bodies if I think it's possible, but that'll be the limit. It already takes 5-10 minutes to try and optimize a 1 fly-by trajectory: any more than that and things are going to start getting expensive.

Anyway, thoughts? Comments and questions are welcome as always.

[The Lone Wolfling]

Hi guys!

I wanted to offer a sneak peak of where they fly-by optimizer is at right now.

Wow that solver looks great!

Here's some other relevant information that the solver spits out.

Departure DV = 0.852133165506862 km/s

Arrival DV = 4.71245869089299 km/s

Okay, now I realize that the arrival dv is a bit high. The solver is only looking to optimize the departure and fly-by delta-v right now. I found that throwing in the arrival delta-v resulted in a poor departure and a poor arrival. This way, at least leaving is very easy. When I get things put together this weekend, I'll include the option to add arrival delta-v to the optimizer, but no promises on how that will work out when you actually go to run it.

Would restricting it to not burn on the flyby help any? It would certainly reduce the sample space. Also, any possibility of calculating possible aerobraking for the flyby?

Anyway, it's all in good fun. I may allow the use of two fly-by bodies if I think it's possible, but that'll be the limit. It already takes 5-10 minutes to try and optimize a 1 fly-by trajectory: any more than that and things are going to start getting expensive.

Sounds like it's time to try (more?) optimization... What's the most expensive part? Have you tried profiling? (Though, that being said, it's going to be computationally expensive regardless - the sample space is just so large...)

[Arrowstar]

Wow that solver looks great!

Thanks! It's taken about a week to get things working nicely, but I think I'm on to something here.

Would restricting it to not burn on the flyby help any? It would certainly reduce the sample space. Also, any possibility of calculating possible aerobraking for the flyby?

So, interestingly enough, it doesn't actually reduce the sample space. Here's why:

To compute a fly-by, you first need to know where you're coming from and where you're going. So if your mission is from Kerbin to Eve to Moho, you need the Kerbin-Eve and Eve-Moho trajectories already figured out. This then defines the fly-by around Eve. Now, a standard gravity assist with no engine burn will have the same specific orbital energy at SOI entry and exit (w.r.t. the flyby planet, here Eve). However, your Sun-centered trajectory may require a higher exit energy than entry energy. In this case, you must expend fuel to make up the difference in energy.

The solver is designed around a Lambert solver, which requires position vectors to the planets and a time of flight. Basically, you get these by selecting a departure date and two times of flight for your transfer arcs. The solver attempts to optimize the departure date and the flight times to the flyby body and destination body. These quantities dictate the Sun-centered orbits, which dictate the Eve flyby orbit, which dictates any delta-v you need to burn while flying by Eve.

Now, I can constrain my solver such that the fly-by delta-v is 0, but then it really freaks out and has a hard time with the problem. Better to just let it come up with what it's going to come up with.

tl;dr: Can't avoid engine burns in some cases because of orbital math.

Sounds like it's time to try (more?) optimization... What's the most expensive part? Have you tried profiling? (Though, that being said, it's going to be computationally expensive regardless - the sample space is just so large...)

The problem is not the objective function being minimized (it's actually quite fast, since the Lambert solver is a compiled MEX file and that's the bulk of the work). It is, as you said, the size of design space and (more importantly) the number of function evaluations needed to do a good job traversing it. I'm using a particle swarm optimizer (it's on the MATLAB file exchange and I'll include the BSD license the first time around this time lol), which takes a population of particles and uses them to find global minima. Now, I also have a speedy Core i5 processor, and I can tell you that even 100 of those particles is a lot, even running the optimization in parallel mode on all four cores at once. If I increase the trade space to another flyby, I'll need even more particles, the whole thing takes longer, and my electric bill spikes because of the insane CPU usage. In short, I've explored it and it's not really feasible for my tool.

---

Now for something completely different!

Here's what I did today.

I think it's fairly self-explanatory, but I'll point out a few things here.

First, the trajectory was my favorite Kerbin-Eve-Moho. I started in LKO and entered the solid white line on the trajectory plot. I then swung by Eve and entered the dashed white trajectory. A bit later I arrive at Moho!

You'll see that the GUI is set up very much like the Departure Information GUI for showing single transfer arc information. All required information about the Kerbin departure hyperbolic orbit and the Eve fly-by hyperbolic orbits is given. Same goes for the Sun-centered transfer orbit arcs. I also provide the usual information you need to execute the departure from Kerbin and the fly-by around Eve.

Next up I will get the apse and node markers on the transfer orbit map. After that, I'll probably release (tomorrow or Monday maybe) and try to get some feedback. I should note here:

Flyby optimization is computationally intensive. Be prepared to wait a few minutes for the software to do its thing.

So, thoughts? I really think KSP TOT is shaping up to be the premier mission planning software for Kerbal Space Program.

[adammada]

Does this "fly-by" assistance takes into account possibility of first waiting few orbits, then getting to destination (like Kerbin->Eve->3 orbits around Kerbol-> Moho) ?

Also, could you somehow add posibility for searching "all planets flyby" path, just like here:

http://forum.kerbalspaceprogram.com/showthread.php/37974-Optimal-gravity-assisted-grand-tour-%28AKA-Voyager-like-mission%29-challenge

I understand that this could take really long, but it is one time to find for everybody, so i think that many users could spare their computer CPU to find it. So it should be splittable to many parts, so many users can count different parts.

[adammada]

Bug (or just to complicated to users...)?

I'm looking for Kerbin -> Eve launch window (going to Eve, so aerobreaking)

http://alexmoon.github.io/ksp/ (100 km orbit start, no orbit end, ballistic) :

Departure

Year 1, day 147 at 6:43:12

Arrival

Year 1, day 196 at 22:43:12

Time of flight

49 days 16:00:00

Phase angle

-36.35°

Ejection angle

150° to retrograde

Ejection inclination

-1.07°

Ejection delta-v

1,074 m/s

Transfer periapsis

8,879 Mm

Transfer apoapsis

13,339 Mm

Transfer inclination

0.12°

Transfer angle

238°

Insertion inclination

N/A

Insertion delta-v

N/A

Total delta-v

1,074 m/s

KSPTOT:

http://imgur.com/a/HS2k0

Questions:

- why there is different optimal time selected on plot and different displayed in status box?

- why i cant copy text to clipboard from status box?

Result: when I entered correct arrival time in "Compute Burn Box" ( 196 at 22:43:12 ), it computed correct departure time, and gave me ~1000 delta-V departure burn. But i could get it on porkchop. (but i set in options 100 points per axis). But by itself it gives very not-optimal results.