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

[Arrowstar]

4 hours ago, Stract said:

Hi Arrowstar!

 

Yup, all I did is add this smaller body GM. As far as I can see, the only problem in TOT with RSS is that TOT calculates the relative position of planets and moons incorrectly, so every SOI transition creates an error. In my example stock TOT determined the wrong location of Earth on Sun orbit (wrong true\mean anomaly to be precise, caused by wrong orbital speed of the Earth) at the moment of SOI transition, which ended up in wrong Sun orbital parameters of a probe. By adding Earth GM into the function I corrected orbital speed of the Earth and hence the true anomaly of the Earth at that moment. So yes, my assumption is that adding GM of smaller body at every time TOT tries to locate the current position of planet or moon (i.e. at every SOI transition, every fly-by trajectory calculation and so...) should do the trick. At least it worked in my example.

Okay great.  So the big problem with implementing this fix here is going to be updating all the locations where any of the functions that require a GM input to use the correct input.  It'll potentially be quite the project.  Like I said, I'll look into it after the 1.5.7 release and hopefully we can put the RSS issues behind us once and for all...

Speaking of which, has anyone run into anything weird or wrong with the latest v1.5.7 pre-release?

[Drew Kerman]

12 hours ago, Arrowstar said:

Speaking of which, has anyone run into anything weird or wrong with the latest v1.5.7 pre-release?

Minor thing I just noticed - after loading up an asteroid orbit that intersects Jool (I see approach markers when I target Jool) I did a standard search for intercept by maxing out my search revs and then coasting to the next SOI, which came up empty. But in previous versions when I went to edit the coast event and switch it to True Anomaly, the TA value would fill itself out, now it just stays 0. Dunno if that's intended or an unintended side-effect of some changes made or just a consequence of changes made. Nothing horrible, I just have to copy the TA from the initial orbit and enter it myself, I think I'll manage But just pointing it out.

Oh, bummer seems this has been removed from other instances to - like if I have a Coast to PE event that I want to change to a Coast to UT the UT box no longer auto-fills with the UT the PE event was at (same for TA & MET)

Edited May 19, 2017 by Drew Kerman

[Phineas Freak]

On 5/18/2017 at 8:05 PM, Arrowstar said:

Speaking of which, has anyone run into anything weird or wrong with the latest v1.5.7 pre-release?

No but i had some awesome times trying out the new pre-state features!

Spoiler

<IMAGE REMOVED BY USER>

Now if only i could find a way to map exactly the resulting ascent sub-orbital profile to a launch vehicle...it probably requires the use of a PEG simulation program.

Edited February 14, 2019 by Phineas Freak
Remove images

[EpicSpaceTroll139]

TOT newb question alert!

So I've been looking at trajectories that use gravitational assists to getting Jool using minimal ∆v.

So I was using the Multi-Flyby Maneuver sequencer, and giving a it generous window of 0-100 years or so.

I figured something like Kerbin-Eve-Jool, Kerbin-Eve-Kerbin-Jool, or Kerbin-Eve-Kerbin-Kerbin-Jool would give me a fairly low ∆v requirement (hoping for worst case of 1.5km/s, which seems reasonable given Eve transfer requirements + significant course adjustments and Oberth maneuvers for later flybys), and that some opportunity for such a sequence of flybys would come up during that time.

TOT does indeed give me maneuvers to do these flybys, however they always require at the least ¾km/s more than what it takes to simply go straight to Jool from Kerbin. I've spent hours looking for a nice cheap trajectory, but nope.

I think what's going on is that the thing thinks that I don't want to go more than one orbit around the Sun without a flyby, so it will do huge burns to make the next flyby instead of making a minor adjustment and waiting a few orbits.

Is there a way for me to change a setting or something for this?

Then again maybe I'm just being a newb and not understanding how to set up good trajectories and/or being overly optimistic on the utility of gravity assists in KSP, due to having watched too many crazy smart YouTubers xD.

Picture

Spoiler

This first one doesn't have a full 100 year window, I did multiple searches of shorter windows after finding general times in which there were windows in hopes of getting more tests closer together.

Funny fluke. Didn't scroll down to see total mission Delta v. 3627m/s first burn is already far past my budget.

This one looked nice until I scrolled down and saw that the total mission Delta v was once again something like 3km/s

 

Sorry if a question like this has been asked BTW, I looked around a bit but this thread is huge. 

This app is awesome though.

I'll do more searching, maybe I just need to do a lot of that.

Edited May 23, 2017 by EpicSpaceTroll139

[Arrowstar]

On 5/18/2017 at 4:40 PM, Drew Kerman said:

Minor thing I just noticed - after loading up an asteroid orbit that intersects Jool (I see approach markers when I target Jool) I did a standard search for intercept by maxing out my search revs and then coasting to the next SOI, which came up empty. But in previous versions when I went to edit the coast event and switch it to True Anomaly, the TA value would fill itself out, now it just stays 0. Dunno if that's intended or an unintended side-effect of some changes made or just a consequence of changes made. Nothing horrible, I just have to copy the TA from the initial orbit and enter it myself, I think I'll manage But just pointing it out.

Oh, bummer seems this has been removed from other instances to - like if I have a Coast to PE event that I want to change to a Coast to UT the UT box no longer auto-fills with the UT the PE event was at (same for TA & MET)

Yeah, I turned that off because I noticed it was causing more issues than it was solving, at least for me.  Did you like it?  I can find a way to re-implement it that isn't so annoying if it's critical for you.

On 5/19/2017 at 3:16 AM, Phineas Freak said:

No but i had some awesome times trying out the new pre-state features!

  Reveal hidden contents

Now if only i could find a way to map exactly the resulting ascent sub-orbital profile to a launch vehicle...it probably requires the use of a PEG simulation program.

Yes, you would need PEG or something.  MechJeb works in a pinch, too.

8 hours ago, EpicSpaceTroll139 said:

TOT newb question alert!

So I've been looking at trajectories that use gravitational assists to getting Jool using minimal ∆v.

So I was using the Multi-Flyby Maneuver sequencer, and giving a it generous window of 0-100 years or so.

I figured something like Kerbin-Eve-Jool, Kerbin-Eve-Kerbin-Jool, or Kerbin-Eve-Kerbin-Kerbin-Jool would give me a fairly low ∆v requirement (hoping for worst case of 1.5km/s, which seems reasonable given Eve transfer requirements + significant course adjustments and Oberth maneuvers for later flybys), and that some opportunity for such a sequence of flybys would come up during that time.

TOT does indeed give me maneuvers to do these flybys, however they always require at the least ¾km/s more than what it takes to simply go straight to Jool from Kerbin. I've spent hours looking for a nice cheap trajectory, but nope.

I think what's going on is that the thing thinks that I don't want to go more than one orbit around the Sun without a flyby, so it will do huge burns to make the next flyby instead of making a minor adjustment and waiting a few orbits.

Is there a way for me to change a setting or something for this?

Then again maybe I'm just being a newb and not understanding how to set up good trajectories and/or being overly optimistic on the utility of gravity assists in KSP, due to having watched too many crazy smart YouTubers xD.

Picture

  Reveal hidden contents

This first one doesn't have a full 100 year window, I did multiple searches of shorter windows after finding general times in which there were windows in hopes of getting more tests closer together.

Funny fluke. Didn't scroll down to see total mission Delta v. 3627m/s first burn is already far past my budget.

This one looked nice until I scrolled down and saw that the total mission Delta v was once again something like 3km/s

 

Sorry if a question like this has been asked BTW, I looked around a bit but this thread is huge. 

This app is awesome though.

I'll do more searching, maybe I just need to do a lot of that.

Okay, astrodynamics lecture time!

It can be shown that given any two positions in space and a time of flight between them, you can draw a conic section (ellipse, hyperbola, or parabola) between those two points.  The resulting conic section will obey the two-body laws of motion that KSP uses.  Basically, you get an orbit.  The problem of determining what that orbit is is known as Lambert's Problem and an algorithm that solves said problem is called a Lambert solver.

Every Lambert solver in existence necessarily can solve the normal Lambert's Problem in which the spacecraft necessarily makes less than one revolution around the central body before it arrives.  More specialized solvers can also solve what's called the multi-revolution Lambert's Problem, in which the spacecraft makes N revolutions around the central body prior to arriving at the destination point.  N is 0, 1, 2, ... etc.

The multi-revolution Lambert's Problem is quite a bit trickier to solve because not all values of N yield a solution.  You can, in fact, show that there is an N_max after which no more values of N will yield a valid solution.  This has to do with the fact that all multi-revolution solutions must have an eccentricity less than 1.0 (so you can actually go around more than once!).

Now, KSPTOT actually does have a multi-rev Lambert solver but it's only used in MFMS to do transfers to the same body (so like from Kerbin to Kerbin, etc), and the number of revs is always hard-coded to 1.  In other cases a normal Lambert solver (that can't do multi-revs) is used.  It wouldn't actually take too much in order to get the multi-rev stuff implemented on the algorithmic side of MFMS but then there's UI work and other related things that need to go in with it, as well. 

So basically you're not wrong, KSPTOT MFMS is not letting the spacecraft go around multiple times.  Good catch!  I didn't know this was actually something people wanted, but if you'd like, I can look into it for the next version (v1.5.8).  It probably won't be too much of a hassle.  Let me know.  

Edited May 23, 2017 by Arrowstar

[Drew Kerman]

5 minutes ago, Arrowstar said:

Did you like it?  I can find a way to re-implement it that isn't so annoying if it's critical for you.

It was very convenient, I wouldn't go so far as to call it critical. Mainly for things like, if I coast to Periapsis then want to muck around with the exact time I want to plot to I could just switch the state from Coast to Pe to Coast to UT and the time of Pe would be inserted to let me then right-click and modify. Now I have to right-click the event and get the UT at the end and then paste it manually. Yea, it's really not a huge deal, I just wanted to point it out in case it was an unforeseen side-effect of some changes. For what it's worth I never saw any issues from it myself.

8 minutes ago, Arrowstar said:

So basically you're not wrong, KSPTOT MFMS is not letting the spacecraft go around multiple times.  Good catch!  I didn't know this was actually something people wanted, but if you'd like, I can look into it for the next version (v1.5.8).  It probably won't be too much of a hassle.  Let me know

I'd say do this instead

[EpicSpaceTroll139]

1 hour ago, Arrowstar said:

<snip> (I did read it! Interesting info! Might do some research of my own into  that! )

So basically you're not wrong, KSPTOT MFMS is not letting the spacecraft go around multiple times.  Good catch!  I didn't know this was actually something people wanted, but if you'd like, I can look into it for the next version (v1.5.8).  It probably won't be too much of a hassle.  Let me know.  

I would indeed find this useful. However if it's significant work and I'm the sole person looking for it, I wouldn't want to eat your time.  Though perhaps if enough other people want it there could be some setting that tells the number of orbits the MFMS will cut the trajectories off at, if it hasn't reached N_max by that point.

I see @Drew Kerman seems to like the idea!

[Drew Kerman]

2 minutes ago, EpicSpaceTroll139 said:

I see @Drew Kerman seems to like the idea!

I do like the idea, but I want to add that I would very much respect Awrrowstar's decision to hold back on this if he deems it not to really be something that would ultimately be useful. I mean, I honestly cannot fully comprehend right now just how useful it would be due to my limited experience, but it sounds cool.

[Arrowstar]

24 minutes ago, Drew Kerman said:

I do like the idea, but I want to add that I would very much respect Awrrowstar's decision to hold back on this if he deems it not to really be something that would ultimately be useful. I mean, I honestly cannot fully comprehend right now just how useful it would be due to my limited experience, but it sounds cool.

It shouldn't be that bad from an algorithmic perspective.  I'll look into it for v1.5.8.

Speaking of which, @Drew Kerman, here's the 7th pre-release of the upcoming version.  I restored your coast conversion stuff with a fix for the issue that I was seeing.  Turns out it was fairly easy to work out.  Let me kno w how it works for you.

Edited May 24, 2017 by Arrowstar

[Drew Kerman]

2 minutes ago, Arrowstar said:

Speaking of which, @Drew Kerman, here's the 7th pre-release of the upcoming version.  I restored your coast conversion stuff with a fix for the issue that I was seeing.  Turns out it was fairly easy to work out.  Let me kno w how it works for you.

as always, you rock

[Arrowstar]

1 hour ago, Drew Kerman said:

as always, you rock

No problem!  Btw, if that works out for you, then I think we'll make this pre-release the actual release tomorrow.

[Drew Kerman]

Can't guarantee I will have time to thoroughly check it out but if you don't hear from me assume all is well

[Arrowstar]

Hi everyone!

Tonight I'm happy to announce the release of KSP Trajectory Optimization Tool v1.5.7!  This release has been in the works for a few months now and it's great to get it into production.  The development is documented over the past several pages of forum posts, but the summarized change log is as follows:

• Mission Architect: New experimental N-body coast event.  This event models N-body gravity for selected bodies.  Allows for basic Principia compatibility.
• Mission Architect: New event "Docking" that models the user spacecraft being docked to another spacecraft by propagating the user spacecraft along the same orbit as the other spacecraft.
• Mission Architect: New event "Landing" that fixes your spacecraft relative to the rotating surface of the current central body.  Can be used to model landings on the surface.
• Mission Architect: New initial state type "Estimate Launch."  Allows for users to model a launch into a circular parking orbit at a desired altitude.  Useful for determining initial orbits when that information is otherwise hard to guess or not available.
• Mission Architect: Initial state parameters may now be optimized like burn and coast parameters.
• Mission Architect: Relative in-track, cross-track, and radial positions of other spacecraft are now represented more correctly in Graphical Analysis.
• Mission Architect: Major update to the optimizer contraint system that allows for nearly all Graphical Analysis tasks to be used as constraints.
• A number of bug fixes in Mission Architect and the KSPTOTConnect plugin.

As usual, the download link is in the OP.  Please let me know if you find any bugs or issues that need to be addressed!

Happy orbiting!

Edited May 24, 2017 by Arrowstar

[Arrowstar]

On 5/18/2017 at 2:29 AM, Stract said:

I don't know how MechJeb deals with RSS, but at least the following seems to be true because it is easy to check: RSS calculates orbital periods using sum of masses unlike TOT. Actually I've played with TOT code a bit. I've changed the way of calculating the SOI upward transition in mission architect by replacing "[rVectBody, vVectBody] = getStateAtTime(bodyInfo, ut, parentBodyInfo.gm);" line with "[rVectBody, vVectBody] = getStateAtTime(bodyInfo, ut, parentBodyInfo.gm+bodyInfo.gm);" in "convertRVVectOnUpwardsSoITransition" function. After this correction mission architect became to predict orbits after upward SOI transition much more accurately. Here are exapmles for stock and modified TOT (TOT predictions for the probe on Earth escape trajectory and actulal orbital parameters after entering Sun SOI:

  Reveal hidden contents

Stock TOT, edited TOT and actual parameters

 

Quick sanity check, @Stract: the period of an orbit and its mean motion would also use the G(M+m), yes?  And G(M+m) would also factor into the element conversions from vectors to normal elements and back again, yes?

[Stract]

11 hours ago, Arrowstar said:

Quick sanity check, @Stract: the period of an orbit and its mean motion would also use the G(M+m), yes?  And G(M+m) would also factor into the element conversions from vectors to normal elements and back again, yes?

Yes as far as I can tell. Kopernicus Orbit loader contains the following lines:

body.orbit.period = 2 * Math.PI * Math.Sqrt(Math.Pow(body.orbit.semiMajorAxis, 2) / 6.67408e-11 * body.orbit.semiMajorAxis / (body.referenceBody.Mass + body.Mass));

body.orbit.meanMotion = 2 * Math.PI / body.orbit.period;

So yes, it seems RSS use G(M+m) for all planets and moons motion. Strictly speaking this is also true even for spacecrafts motion since the mass of spacecraft is neglidgeble compared to mass of any RSS body, so for spacecraft G(M+m) and GM are practically the same. 

[drunkeNNN]

On 24.5.2017 at 2:13 AM, EpicSpaceTroll139 said:

I would indeed find this useful. However if it's significant work and I'm the sole person looking for it, I wouldn't want to eat your time.  Though perhaps if enough other people want it there could be some setting that tells the number of orbits the MFMS will cut the trajectories off at, if it hasn't reached N_max by that point.

I see @Drew Kerman seems to like the idea!

I've just started to get into KSP TOT and have to say its a really great tool overall. I also ran into the fact that multiple revolutions are not considered in the MFMS. Especially for the inner planets, that would be useful. In particular, that should make it possible to use a Kerbin as the first bouncing point (just like ESA did at the beginning of Rosetta).

Another thing that I wonder is whether the MFMS also optimizes the excess vel at the final destination. Very often I do end up with extremely high velocities which basically makes the solution impractical (typically, you would not want to fly by the body but rather enter orbit at least I do :-) ) Related to that: is there a way to also minimize the injection burn in the MFMS? I think that would greatly improve the usability of the tool.

[Arrowstar]

Okay, I can't promise that it's perfect, but I think I'm close on RSS compatibility.  This is from my test tonight.

I could really use some testers.  @Stract, @gruneisen, anyone else, if I provided a pre-release, would you be willing to put it through the RSS paces and see what issues arise?  I am obviously doing the same, but this task was really huge.  I've basically had to sort through the whole code base and make updates to the locations where celestial body states are being computed to update the GM values... I think I got them all but I could use a double check.

3 hours ago, drunkeNNN said:

I've just started to get into KSP TOT and have to say its a really great tool overall. I also ran into the fact that multiple revolutions are not considered in the MFMS. Especially for the inner planets, that would be useful. In particular, that should make it possible to use a Kerbin as the first bouncing point (just like ESA did at the beginning of Rosetta).

Got it, thanks for the feedback on this.  I suspect this feature is coming next, after I finish RSS compatibility.

Quote

Another thing that I wonder is whether the MFMS also optimizes the excess vel at the final destination. Very often I do end up with extremely high velocities which basically makes the solution impractical (typically, you would not want to fly by the body but rather enter orbit at least I do :-) ) Related to that: is there a way to also minimize the injection burn in the MFMS? I think that would greatly improve the usability of the tool.

MFMS already optimizes the arrival excess hyperbolic velocity.  It's just that the optimizer is balancing that against the departure excess velocity and the flyby delta-v and sometimes that quantity has to give to minimize the other ones.  It's all a balance.

Regarding optimizing the injection burn: Sadly not, no.  That's computed after the fact for a reason, namely that it's fairly expensive to compute.  (All those iterations on the waitbar after the GA finishes?  That's the calculation for the optimal departure burn.)  If I put that calculation in the loop with the flyby math, the whole thing would take weeks to run.  But you can optimize your burn and initial orbit in Mission Architect, so I would suggest trying that out.

Edited May 27, 2017 by Arrowstar

[quietghost]

Forgive me if I am missing something, but I seem to be unable to load saves when the planets for OPM are involved in my trajectories. Otherwise it loads just fine when the trajectories do not involve the OPM planets. Is there any workaround for this besides replotting the mission? Luckily I have it saved right up until the final maneuver so its not too big a hassle.

The specific behavior of TOT is to not show anything when the file is loaded, but in the status window it says it loaded the file with no error. I have attached the 2 mission files: the first is with a Sarnus intercept, the second is without, just in case you would like to take a look.

Mission with Sarnus Encounter

Mission without Sarnus Encounter

Edit:

I have done some further testing and figured out that it doesn't have anything to do with Sarnus or OPM, because I have created missions that will load with Sarnus in the trajectory. I have uploaded a file that works for more information.

Mission with Sarnus that Works

Hopefully this additional file helps.

Thanks!

Edited May 27, 2017 by quietghost
Additional testing to isolate issue

[Stract]

8 hours ago, Arrowstar said:

I could really use some testers.  @Stract, @gruneisen, anyone else, if I provided a pre-release, would you be willing to put it through the RSS paces and see what issues arise?  I am obviously doing the same, but this task was really huge.  I've basically had to sort through the whole code base and make updates to the locations where celestial body states are being computed to update the GM values... I think I got them all but I could use a double check.

Sure, I'll be happy to try.

[Arrowstar]

9 hours ago, quietghost said:

Forgive me if I am missing something, but I seem to be unable to load saves when the planets for OPM are involved in my trajectories. Otherwise it loads just fine when the trajectories do not involve the OPM planets. Is there any workaround for this besides replotting the mission? Luckily I have it saved right up until the final maneuver so its not too big a hassle.

The specific behavior of TOT is to not show anything when the file is loaded, but in the status window it says it loaded the file with no error. I have attached the 2 mission files: the first is with a Sarnus intercept, the second is without, just in case you would like to take a look.

Mission with Sarnus Encounter

Mission without Sarnus Encounter

 

Thanks!

I was able to load both save files just fine.  Can you show me screenshots of the behavior you're seeing?  Maybe try the pre-release below, which is what I'm on.

6 hours ago, Stract said:

Sure, I'll be happy to try.

Thanks!  Here you are.  I guess this is KSP Trajectory Optimization Tool v1.5.8 pre-release 1.  Please let me know what you find, good or bad.  I'll try to get the bugs fixed ASAP so you can get up and running.

To use the new RSS mode, in the main KSPTOT GUI, go Edit -> Gravitational Parameter -> RSS Like.

Thanks!  @Phineas Freak, I think you were interested in this modification too, so you're welcome to help out here as your interest and time dictate.

Edited May 27, 2017 by Arrowstar

[quietghost]

Quote

I was able to load both save files just fine.  Can you show me screenshots of the behavior you're seeing?  Maybe try the pre-release below, which is what I'm on.

Hmm, strange that you can load it, perhaps I have a weird bodies.ini file issue. I am using the one packaged with the tutorial.

Anyway, here is a link to the screenshot. This happened after I opened a new mission, then went straight to loading my Sarnus mission, but it happens after I load any mission. Sorry for the tiny log text.

Screenshot

Also, I posted an edit above that seems to indicate this has nothing to do with OPM.

Edit:

The pre-release seemed to solve the issue. It loads fine for me too! I guess all is well then.

Thanks for your help!

Edited May 27, 2017 by quietghost
Resolved

[gruneisen]

24 minutes ago, Arrowstar said:

I was able to load both save files just fine.  Can you show me screenshots of the behavior you're seeing?  Maybe try the pre-release below, which is what I'm on.

Thanks!  Here you are.  I guess this is KSP Trajectory Optimization Tool v1.5.8 pre-release 1.  Please let me know what you find, good or bad.  I'll try to get the bugs fixed ASAP so you can get up and running.

To use the new RSS mode, in the main KSPTOT GUI, go Edit -> Gravitational Parameter -> RSS Like.

Thanks!  @Phineas Freak, I think you were interested in this modification too, so you're welcome to help out here as your interest and time dictate.

Hey @Arrowstar - I can't wait to try this out tonight! Thank you so much for working this!

Edited May 27, 2017 by gruneisen

[Stract]

16 hours ago, Arrowstar said:

Thanks!  Here you are.  I guess this is KSP Trajectory Optimization Tool v1.5.8 pre-release 1.  Please let me know what you find, good or bad.  I'll try to get the bugs fixed ASAP so you can get up and running.

Hi Arrowstar, so far most of the things works great! I've noticed only one issue: there are some problems with fast-orbiting moons like Phobos, Deimos or Charon. Predictions for fly-by near them are not as good as for other planets or moons, sometimes TOT didn't see SOI transitions near them at all. Orbital periods for them are fine (or at least good enough), so maybe the problem is with initial mean anomaly or something. At least I've input manually current Charon mean anomaly and epoch into bodies.ini, skip 20 years and put a probe into fly-by trajectory near it. The predictions were fine, while automatically generated bodies.ini didn't give SOI transition at all. I'll look at it more carefully but anyway it is a minor issue. Overall TOT handles RSS really good now. Thank you for this great instrument!

[Arrowstar]

4 hours ago, Stract said:

Hi Arrowstar, so far most of the things works great! I've noticed only one issue: there are some problems with fast-orbiting moons like Phobos, Deimos or Charon. Predictions for fly-by near them are not as good as for other planets or moons, sometimes TOT didn't see SOI transitions near them at all. Orbital periods for them are fine (or at least good enough), so maybe the problem is with initial mean anomaly or something. At least I've input manually current Charon mean anomaly and epoch into bodies.ini, skip 20 years and put a probe into fly-by trajectory near it. The predictions were fine, while automatically generated bodies.ini didn't give SOI transition at all. I'll look at it more carefully but anyway it is a minor issue. Overall TOT handles RSS really good now. Thank you for this great instrument!

Could you post a mat file that shows the issue you're talking about with the moons?  Also the new and old bodies files, if you could. :-) 

[drunkeNNN]

On 27.5.2017 at 2:03 AM, Arrowstar said:

Got it, thanks for the feedback on this.  I suspect this feature is coming next, after I finish RSS compatibility.

MFMS already optimizes the arrival excess hyperbolic velocity.  It's just that the optimizer is balancing that against the departure excess velocity and the flyby delta-v and sometimes that quantity has to give to minimize the other ones.  It's all a balance.

Regarding optimizing the injection burn: Sadly not, no.  That's computed after the fact for a reason, namely that it's fairly expensive to compute.  (All those iterations on the waitbar after the GA finishes?  That's the calculation for the optimal departure burn.)  If I put that calculation in the loop with the flyby math, the whole thing would take weeks to run.  But you can optimize your burn and initial orbit in Mission Architect, so I would suggest trying that out.

That sounds great. Maybe I just had bad RNG luck with the optimizer there.

I do agree that including the inclination component is computationally not feasible. But I dont think that a good estimate of the injection and ejection dv requires a lot of computation time if you already optimize  the hyperbolic excess velocity. The dv needed is fairly straightforward to compute using energy conservation if you neglect inclination changes. After simplification you end up with:

dv_inject=sqrt(v_inf^2+2*mu/R)-sqrt(mu/R)

All this requires are two additional user parameters (the radii of the circular orbits R). According to the formula the circularization burn dv is not that different when the excess velocity is below the escape velocity of the associated circular orbit. For example, departing from a 100km orbit around Kerbin with an excess velocity of 500m/s costs 969m/s, departing with 1500m/s only costs 1267m/s, so you get additional 1000m/s for burning only 300m/s more. In contrast, leaving with 5000m/s costs 3678m/s while leaving with 6000m/s costs 3543m/s so you have to pay an additional ~900m/s. This means that the hyperbolic excess velocity generally isn't a good parameter to optimize for ejection and injection if that makes sense to you.

Neglecting the inclination would not be a big deal here. A vessel can always be launched into the correct orbital plane and the arrival orbital plane can be easily changed with only a couple of m/s. If I understood you correctly, the current solution is good if one would always circularize at the edge of the SOI (where the associated escape velocity is basically 0) and for very small planets (where typical transfer excess velocities exceed the low orbit escape velocities). This was the reason why I was interested in the feature.

Edited May 28, 2017 by drunkeNNN
added additional information