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

[Arrowstar]

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) ?

No.

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.

Please realize what you're asking for here. The mission planners who designed the Voyager grand tour spent years looking for and refining that trajectory. KSP TOT is, by comparison, a very simplistic tool. Even if I thought I could find a solver capable of such a task, no one in the private world has enough CPU power to actually carry it out. This problem is far beyond the scope of this application...

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.

Answer to question 1: The porkchop plot is a N by N grid of calculated points. The point you see selected on the porkchop plot with the tooltip is the best point of those computed while generating the plot. The point provided in the tool window is the "best" point found by a fairly sophisticated optimization algorithm. The porkchop plot is designed to give you the "lay of the land", whereas the results of the optimization algorithm (in that status box) is actually what you can plan missions with.

Answer to question 2: Because I haven't enabled that yet. I'll do that for the v0.7 release.

Please let me know if that answers your question! If I can answer anything else, do let me know here...

[Arrowstar]

Alright, folks, I need a beta tester for the v0.7 prerelease. This is unusual, but the parallel processing code I'm using (the stuff native to MATLAB) has a possibility of running differently on different system architectures. In particular, I'm looking for someone who can run the Maneuver Flyby Sequencer tool on a computer with a dual core processor. If you also happen to have a quad-core processor, run it on that too.

Here's the ZIP with the application. No source or license stuff included here, I'm keeping this one simple.

When you run the flyby maneuver sequencer (FMS), please use the following settings:

Launch window open = 0

Launch window close = 157680000

Depart Body = Kerbin

Flyby Body = Eve

Arrival Body = Moho

Initial Elliptical Orbit SMA = 800

All other initial orbit values = 0

I need to know two things:

1. Did the application run for you? Could you enter the values above, push the Compute button, and get a solution to appear?
   
2. Was your processor usage over (1/numCores)*100%? That is, if you have a quad-core machine, were you using total processor usage over 25%? This will be spread amongst multiple processes, so look at the total system usage, not just the KSPTOT.exe usage.
   

The more people who want to give this a go and report results, please feel free. Report your findings and any problems here on this thread. (Btw, I already know the status box text on the main window says 0.6 and not 0.7 - this is fixed for next build. )

Thanks, guys!

[Mr Shifty]

I'm running an AMD Phenom II 1055T 2.8GHz 6 core processor. I ran the test you asked for. During the first stage (finding feasible initial positions), my total CPU usage was an average of exactly 16.67%. First stage took 2m39s. During the second stage (particle swarm optimization), it was a little less (12-13%), but each core was active, as you can see here:

Second stage took 3m31s. (Total time: 6m10s). Here's the final computed result:

I ran it a second time and got different results:

Edited July 8, 2013 by Mr Shifty

[togfox]

As an early adoptor for this when it was in Java, I have resisted this version due to the download. Now that you are up to version 6 or so, I can see you're really starting to pack in the functionality and I'm now tempted to give this a shot.

In the original program, it was impossible to know when to launch as there was no universal clock, meaning, the perfect porkchop is useless if you didn't know the age of the Kerbolverse since the big bang (or whatever created it!). How is this resolved in this version? MET is relative - how does one find the absolute universe time?

[Arrowstar]

Mr Shifty: Thanks for the information! This is really useful. By "phase 1" do you mean the segment where the solver looks for feasible initial states? And by "phase 2", do you mean the actual solver run, with the PSO plot that comes up in a separate window?

Togfox: I would love to see you give KSP TOT a go here. Universal time (UT) is available in two places. You can grab it from the Tracking Station, and if you use MechJeb 2, you can also put UT on a window using the window editor. MechJeb is really necessary for using this program in KSP, to be honest, because only by physically entering the delta-v quantities and getting your current orbit can you really make use of everything KSP TOT has to offer.

I would love some feedback from you if you do decide to give the program a shot.

EDIT: Also, I prefer to think that it wasn't a big bang that started the Kerbal-verse, but instead a Big Harvester:

Edited July 8, 2013 by Arrowstar

[Mr Shifty]

Mr Shifty: Thanks for the information! This is really useful. By "phase 1" do you mean the segment where the solver looks for feasible initial states? And by "phase 2", do you mean the actual solver run, with the PSO plot that comes up in a separate window?

Yeah, regarding phase 1 and 2. Should I expect that the solver gets different results on different runs? They're not too different wrt total delta-V.

Togfox: I would love to see you give KSP TOT a go here. Universal time (UT) is available in two places. You can grab it from the Tracking Station, and if you use MechJeb 2, you can also put UT on a window using the window editor. MechJeb is really necessary for using this program in KSP, to be honest, because only by physically entering the delta-v quantities and getting your current orbit can you really make use of everything KSP TOT has to offer.

Kerbal Alarm Clock also shows absolute time and allows you to set alarms that bring you out of warp at a particular UT.

[Arrowstar]

Yeah, regarding phase 1 and 2. Should I expect that the solver gets different results on different runs? They're not too different wrt total delta-V.

Yes, that's not unexpected. There are a lot of local minima in the trade space and the PSO solver, while good, can't usually avoid them all, and when this happens it tends to fall into different minima. Thus we end up with slightly different results each run. It's unavoidable and usually not too big of a deal.

[Mr Shifty]

The flyby tool is very cool. I'm gonna give the orbit a try this evening to see how well it works. It would be really useful to see the final hyperbolic trajectory around the target planet as well (including velocity vector info.)

[Arrowstar]

The flyby tool is very cool. I'm gonna give the orbit a try this evening to see how well it works. It would be really useful to see the final hyperbolic trajectory around the target planet as well (including velocity vector info.)

Please do! If you could document the whole thing with screenshots, that'd be great. It would certainly be helpful as I determine what changes I can make to improve the user interface.

Btw, do you use Mechjeb 2? I would recommend using it for the orbit panel and the maneuver node editor so you can create those maneuver nodes precisely.

[Mr Shifty]

Please do! If you could document the whole thing with screenshots, that'd be great. It would certainly be helpful as I determine what changes I can make to improve the user interface.

Btw, do you use Mechjeb 2? I would recommend using it for the orbit panel and the maneuver node editor so you can create those maneuver nodes precisely.

I'll post an album. I do use MechJeb, but I like Better Maneuver Nodes and Improved Maneuver Nodes for editing nodes.

[Arrowstar]

Thanks! And yes, however you'd like to use it is fine. Looking forward to seeing how you do!

[Arrowstar]

Oh, just another little thing I'm working on today.

This code is looking for the best way to take the given orbit around Kerbin (here) and turn it into the desired orbit. Magenta line is the orbit the spacecraft started in, blue line is the desired orbit, and the dashed black line is the transfer orbit between the two. The red line you see represents the burn direction (in this case, the second burn - the first burn is smaller and hard to see).

In particular, in this example I started with the standard equatorial, circular orbit around Kerbin with an SMA of 800 km. I then asked the code to make the following changes to the orbit:

1. Change eccentricity to 0.1
   
2. Change inclination to 30 degrees
   

The black line represents the best transfer orbit between the two orbits and the red line/lines are the optimized burns.

Eventually, I'll put together a GUI for this similar to the flyby maneuver sequencer GUI, and it'll be accessible within KSP TOT just like the FMS is. Some possible uses for the new tool (which has yet to be named):

1. Finding the best way to get into that optimal Kethane scanning orbit around Minmus.
   
2. Tweaking your inbound hyperbolic orbit towards Duna so that you can easily enter your desired science mission orbit.
   
3. And more!
   

[adammada]

Bug reports:

- point legend goes under other elements

- can't resize window ( plot should be scallable )

- optimal results from status box should be default values for "compute departure burn". Or somehow add button there to do it.

( Intel Pentiun G850 processor - 2 cores, windows 7 64 bit )

- when i runned KSP TOL first time, windows firewall spammed me with warnings about making connections (ctfxlauncher process i think) i clicked to allow them. Then it started counting, but only around 50% of cpu usage. When it got to particles it started to jump to higher values like 90%. And it was done.

- second time i runned it i didin't got those firewall warnings. So now if i will not do anyting while starting, it just counts like in previous time (50%).

- but if i click "Ok" in "attemping to start parraller worksers" i get error from screenshot:

[wingnut]

Hi Arrowstar,

thank you for this wonderful application. I already have Trajectory Optimization Tool v2.1 installed with the corresponding MCR 7.14 - is it possible to run both TOTs (for KSP and Orbiter) on the same MCR? The one for Orbiter did not work when I only had MCR 8.x installed.

Will it be possible to enter the same planet as departing and arrival body in the Flyby Maneuver Sequencer, or are you even planning to implement flight plans with multiple customizable waypoints like in the TOT 2.1 for Orbiter?

Offtopic: Is there any trick to use the output of the Departure Analysis Tool of the TOT for Orbiter in TransX? When I input it directly into a TransX plan, there is no real encounter...

Edited November 2, 2013 by wingnut
Fixed typo

[The Lone Wolfling]

Alright, folks, I need a beta tester for the v0.7 prerelease. This is unusual, but the parallel processing code I'm using (the stuff native to MATLAB) has a possibility of running differently on different system architectures. In particular, I'm looking for someone who can run the Maneuver Flyby Sequencer tool on a computer with a dual core processor. If you also happen to have a quad-core processor, run it on that too.

I'm using a i5-3210M. (2 cores, with HT (so appears as 4 to many things)). Ran fine. First stage (finding departures) used 25% CPU: i.e. single-core. It also triggered turbo boost mode (pushed CPU speed above nominal maximum). Second stage (particle swarm) used both cores (50% CPU, because of hyperthreading). Interestingly, turbo mode was still engaged.

Oh, just another little thing I'm working on today.

Can you tweak this to include the possibility of long burn times? So for things like ion probes, where they take several orbits to do much of anything?

Also, looks great!

[Arrowstar]

Bug reports:

<snip>

- point legend goes under other elements

- can't resize window ( plot should be scallable )

- optimal results from status box should be default values for "compute departure burn". Or somehow add button there to do it.

( Intel Pentiun G850 processor - 2 cores, windows 7 64 bit )

- when i runned KSP TOL first time, windows firewall spammed me with warnings about making connections (ctfxlauncher process i think) i clicked to allow them. Then it started counting, but only around 50% of cpu usage. When it got to particles it started to jump to higher values like 90%. And it was done.

- second time i runned it i didin't got those firewall warnings. So now if i will not do anyting while starting, it just counts like in previous time (50%).

- but if i click "Ok" in "attemping to start parraller worksers" i get error from screenshot:

<snip>

Thanks for the bug notes and test information!

Bug 1 is unfixable, as the data cursor does not conform to the ui stacking order of the rest of the GUI (if someone can prove me wrong here, please do!).

Bug 2 is intentional for now. Getting things to resize nicely is a bit harder than it sounds and I'll tackle it at the end, once I get everything functional.

Bug 3 is a good one. I'll add a note to handle this for 0.7. Fixed. Also, the status window text is now selectable as well...

Hi Arrowstar,

thank you for this wonderful application. I already have Trajectory Optimization Tool v2.1 installed with the corresponding MCR 7.14 - is it possible to run both TOTs (for KSP and Orbiter) on the same MCR? The one for Orbiter did not work when I only had MCR 8.x installed.

Will it be possible to enter the same planet as departing and arrival body in the Flyby Maneuver Sequencer, or are you even planning to implement flight plans with multiple customizable waypoints like in the TOT 2.1 for Orbiter?

Offtopic: Is there any trick to use the output of the Departure Analysis Toll of the TOT for Orbiter in TransX? When I input it directly into a TransX plan, there is no real encounter...

I'll look into how the solver behaves with departure and arrival bodies that are the same. As far as TOT for Orbiter goes, please shoot me a PM with questions and we can talk more there. I'd like to keep this thread on topic. I will say that the two applications were compiled with different versions of the MCR and thus two different MCR versions are required to run them...

I'm using a i5-3210M. (2 cores, with HT (so appears as 4 to many things)). Ran fine. First stage (finding departures) used 25% CPU: i.e. single-core. It also triggered turbo boost mode (pushed CPU speed above nominal maximum). Second stage (particle swarm) used both cores (50% CPU, because of hyperthreading). Interestingly, turbo mode was still engaged.

Can you tweak this to include the possibility of long burn times? So for things like ion probes, where they take several orbits to do much of anything?

Noted, thanks for the trial run.

Sadly, the tweak you're asking for is really more of a major overhaul of the code. The lambert solver I'm using assumes instantaneous delta-v. To correctly model "long" burns, I would have to write an orbit propagator to model the thrust correctly. That is a huge task and not one I'm looking to take on at the moment.

In the mean time, here's how I would deal with the problem.

1) Compute a two burn solution.

2) Get as far along the first burn as you can.

3) Note the post-burn orbit and recompute a new optimal two-burn solution.

4) Execute new burn plan.

5) Repeat until you get the orbit you want.

This method ensures that your execution errors are accounted for and corrected while allowing for multiple burns to take place. Sometimes it's all about working within the limits of the tool you have.

Also, looks great!

Thanks, means a lot!

---

Hey Wingnut, I have good news...

Consider it included for 0.7.

Edited July 9, 2013 by Arrowstar

[Arrowstar]

Alright guys,

I've fixed up a bunch of the bugs and suggestions you all have had provided. Thanks! I've compiled all this into the v0.7 prerelease 2. Since this version has so many large changes, if I could ask you guys to take another look and see if anything has been left out or any bugs have surfaced, that'd be great.

Here's the updated ZIP file.

Same deal, just the EXE and no source or license. All of that will come with the formal 0.7 release. If all goes well, that will be tomorrow.

Please let me know what you think. Thanks for all your help, guys! You rock.

Edited July 9, 2013 by Arrowstar

[wingnut]

Hey Wingnut, I have good news...

That's good news Arrowstar.

I've run the Kerbin-Eve-Moho flyby scenario with the KSPTOTv7prerelease2:

Calculating the initial positions took 2:40 minutes

The Particle swarm optimization took 3:55 minutes

This is a screenshot of my resource monitor during the first third of the Particle swarm optimization:

The CPU usage was between 24 and 27% during the initial positions calculation.

The CPU usage during the Particle swarm optimization was fluctuating between 26 and ~65%.

Output:

Hyperbolic Departure & Flyby Orbits:

Hyperbolic Departure Orbit from Kerbin
---------------------------------------------
Semi-major Axis =               -2753.593 km
Eccentricity =                  1.2905
Inclination =                   7.675 deg
Right Ascension of AN =         236.603 deg
Argument of Periapse =          0.000 deg
---------------------------------------------
Inbound Hyperbolic Flyby Orbit to Eve
---------------------------------------------
Semi-major Axis =               -1455.331 km
Eccentricity =                  2.7298
Inclination =                   166.920 deg
Right Ascension of AN =         244.223 deg
Argument of Periapse =          169.668 deg
Periapse Radius =               2517.403 km
---------------------------------------------
Outbound Hyperbolic Flyby Orbit from Eve
---------------------------------------------
Semi-major Axis =               -1455.330 km
Eccentricity =                  2.7298
Inclination =                   166.920 deg
Right Ascension of AN =         244.223 deg
Argument of Periapse =          169.668 deg
Periapse Radius =               2517.403 km

Sun-Centric Transfer Orbit:

Phase 1 Transfer Orbit (Kerbin -> Eve)
---------------------------------------------
Semi-major Axis =             11073006.720 km
Eccentricity =                0.2282
Inclination =                 0.672 deg
Right Ascension of AN =       107.217 deg
Argument of Periapse =        180.202 deg
Kerbin Depart True Anomaly =  179.798 deg
Eve Arrive True Anomaly =     70.070 deg
---------------------------------------------
Phase 2 Transfer Orbit (Eve -> Moho)
---------------------------------------------
Semi-major Axis =             8191378.476 km
Eccentricity =                0.26514
Inclination =                 0.949 deg
Right Ascension of AN =       135.733 deg
Argument of Periapse =        76.445 deg
Eve Depart True Anomaly =     145.315 deg
Moho Arrive True Anomaly =    30.400 deg
---------------------------------------------
Departure Date = Year 5, Day 223 20:25:29.912
                      (145398329.912 sec UT)
Flyby Date =     Year 5, Day 273 06:31:29.541
                      (149668289.541 sec UT)
Arrival Date =   Year 5, Day 308 05:00:39.870
                      (152686839.870 sec UT)

DV Maneuver Information:

Burn Information to Depart Kerbin
---------------------------------------------
Total Delta-V =              1.13291 km/s
Prograde Delta-V =           1050.30975 m/s
Radial Delta-V =             -0.00000 m/s
Orbit Normal Delta-V =       424.66546 m/s
---------------------
Departure True Anomaly =     236.60284 deg
Departure Time Past Peri. =  1572.34027 sec
Departure Time Before Peri. = 820.03384 sec
---------------------------------------------
Burn Information to Depart Eve
---------------------------------------------
Total Delta-V =              0.00000 km/s
Prograde Delta-V =           0.00060 m/s
Radial Delta-V =             -0.00001 m/s
Orbit Normal Delta-V =       0.00000 m/s
---------------------
Departure True Anomaly =     0.00000 deg
Departure Time Past Peri. =  0.00000 sec
Departure Time Before Peri. = 0.00000 sec

[adammada]

I just tried this Kerbin->Eve->Moho transfer.

I started with 200666 m orbit. Then i entered into mechjeb node those values:

Prograde Delta-V = 1050.30975 m/s

Radial Delta-V = -0.00000 m/s

Orbit Normal Delta-V = 424.66546 m/s

Time of lanuch was within minute from predicted:

Year 5, Day 223 20:25:29.912 (just to be on correct angle).

Sadly, closest encouter with EVE was aroun 42 000 000 m. Any prograde/normal burn changes were only getting it worse.

So i tried to move burn forward and backward by whole orbit period. (39m54s), and ended about 10 hours earlier, because this was giving me closer PE. I also reduced normal burn (about 100 m/s), and ended with about 5 000 000 km Eve periapsis. I lanunched and used mechjeb "fine approach" to get me closer to eve ( about 10 m/s used).

Then i waited until entering Eve SOI, sadly i was going wrong way around. I needed about 90 m/s radial burn just to go by other side. Then i was keep raising Eve PE by adding (about -130 m/s at the end) radial burn, until it gave me Moho SOI.

So, thoughts:

1. Something was wrong with time of launch, was bit (10 or more hours) too late.

2. Its really, really hard to set launch excactly to get one burn. I know that i should set correct Eve PE before entering its SOI, because this would take much less fuel, but:

a) Warp changes PE on changing SOI

Its harder to set correct burn angle, to change just PE, not inclination when not in SOI

c) it has to be really carefull

But it worked!

P.S.

When i set SMA to 700 (i usually start from 100 km orbit, not 200km), it gave me totally different solution:

year of launch: 3

around 1400 delta-v

just by changing Kerbin start orbit.

[Mr Shifty]

I tried to do a Kerbin->Eve->Moho burn last night starting at about day 180, I think. The solver gave me a solution with an ejection delta-V of around 5,000 m/s, which is more than 3 times what you need to do a direct Kerbin->Moho burn, so I didn't bother with the gravity assist. I'll try again at some point.

[The Lone Wolfling]

Sadly, the tweak you're asking for is really more of a major overhaul of the code. The lambert solver I'm using assumes instantaneous delta-v. To correctly model "long" burns, I would have to write an orbit propagator to model the thrust correctly. That is a huge task and not one I'm looking to take on at the moment.

Drat! Standard orbital maneuver calculators are a dime a dozen - it's long burn calculations that's the thing I'm unable to find anywhere.

[Arrowstar]

Hi everyone,

I have the pleasure to announce the v0.7 release of the KSP Trajectory Optimization Tool! This is a major update that brings the following capabilities:

• A Flyby Maneuver Sequencer(FMS)that is capable of searching for optimal flybys (gravity assist maneuvers) around planets. Spending too much fuel on that trip to Moho? Try a flyby around Eve first!
  
• Optimal launch/arrival date is now the default setting in the Compute Departure GUI.
  
• "Time To Periapse" is now shown alongside "Time After Periapse" in the DV Maneuver Information boxes in the Departure Information GUI and the FMS GUI. Useful for using maneuver node editors mostly.
  
• Some minor visual changes/tweaks to the plots.
  
• Some bug fixes and a code reoganization on the back-end.
  

The ZIP file in the original post should be updated by now. Go check it out!

(Note: for those who tried the 0.7 prerelease 2, this is the same executable. I didn't have any changes to make after yesterday, so I'm calling that good for now.)

---

Drat! Standard orbital maneuver calculators are a dime a dozen - it's long burn calculations that's the thing I'm unable to find anywhere.

Yep. That's because this problem is pretty hard. To hit targets on a finite duration burn or optimize the same could require something called variational calculus. I've taken some coursework in the field and while it's very interesting academically, it's not worth implementing here. And really, I promise, the impulsive burn model will serve you just fine 99% of the time in KSP.

I tried to do a Kerbin->Eve->Moho burn last night starting at about day 180, I think. The solver gave me a solution with an ejection delta-V of around 5,000 m/s, which is more than 3 times what you need to do a direct Kerbin->Moho burn, so I didn't bother with the gravity assist. I'll try again at some point.

So, the problem is probably just that the solver didn't find a good solution. This can happen sometimes. The PSO solver is not fool-proof and it occasionally doesn't produce good results. The only way to mitigate this is to add more particles, which is more expensive to evaluate. I've picked settings that I think represent a good balance between speed and accuracy.

tl;dr: If you get terrible results, try optimizing again (maybe with a larger launch window).

I just tried this Kerbin->Eve->Moho transfer.

I started with 200666 m orbit. Then i entered into mechjeb node those values:

Prograde Delta-V = 1050.30975 m/s

Radial Delta-V = -0.00000 m/s

Orbit Normal Delta-V = 424.66546 m/s

Time of lanuch was within minute from predicted:

Year 5, Day 223 20:25:29.912 (just to be on correct angle).

Sadly, closest encouter with EVE was aroun 42 000 000 m. Any prograde/normal burn changes were only getting it worse.

So i tried to move burn forward and backward by whole orbit period. (39m54s), and ended about 10 hours earlier, because this was giving me closer PE. I also reduced normal burn (about 100 m/s), and ended with about 5 000 000 km Eve periapsis. I lanunched and used mechjeb "fine approach" to get me closer to eve ( about 10 m/s used).

Then i waited until entering Eve SOI, sadly i was going wrong way around. I needed about 90 m/s radial burn just to go by other side. Then i was keep raising Eve PE by adding (about -130 m/s at the end) radial burn, until it gave me Moho SOI.

So, thoughts:

1. Something was wrong with time of launch, was bit (10 or more hours) too late.

2. Its really, really hard to set launch excactly to get one burn. I know that i should set correct Eve PE before entering its SOI, because this would take much less fuel, but:

a) Warp changes PE on changing SOI

Its harder to set correct burn angle, to change just PE, not inclination when not in SOI

c) it has to be really carefull

But it worked!

P.S.

When i set SMA to 700 (i usually start from 100 km orbit, not 200km), it gave me totally different solution:

year of launch: 3

around 1400 delta-v

just by changing Kerbin start orbit.

I'm glad it worked for you! Very good job. Next time, could you take some screenshots of the game's map and KSP TOT's output so I can compare?

A couple points on your comments.

First, the actual initial orbit you provide isn't used up until the code says "Computing Departure Orbit." I assume that if I can minimize the hyperbolic excess speed of departure, I've minimized the actual departure delta-v, so I don't need to use that information right away. This makes it faster to optimize the whole problem. The assumption isn't strictly true, but it's a good enough approximation.

Second, regarding the time of launch: Your actual execution time of the burn is critical for these maneuvers. If you run the tool once, get a departure time and a departure true anomaly and then create a maneuver node, what you'll see is that the departure time doesn't match what KSP TOT is telling you that you need. You'll probably be off on the order of minutes. This about the speed of the planets though: multiple km/s. So how many kilometers would, say, Eve move in the space of 30 minutes? Enough to throw off your arrival trajectory, easily.

How do you get around this? You do what we astrodynamicists do a lot of in the Real World: you iterate on your solution. Compute a departure time, toss the burn information into KSP, and get your actual departure time. Put this actual time back into KSPTOT, reoptimize the departure, then put the burn information back into KSP TOT. In one of two iterations, you'll see that your KSP departure time and your KSPTOT departure time are basically the same. That's the burn information you'll want to use to get to Eve.

I agree with your points in (2), but there's not much I can do about them sadly. I'll see if I can mitigate the problem any, though...

Thanks for the great feedback!

---

Here's a little preview of what I worked on today. It's a continuation of something I showed yesterday, but with a partially working GUI...

Anyone want to guess?

[wingnut]

I made similar experience like adammada with a Kerbin->Eve->Kerbin flyby optimization. Thanks to MechJeb executing the departure burn, the outbound orbit from LKO and the Sun-centric orbit were relatively accurate (much more than when I would do the burn manually of course) but not accurate enough to actually enter Eve's and Kerbin's SOI. Consequently at least one additional maneuver would be required.

Nevertheless I'm amazed that it works out so well already, without your tool I never would have figured out when and how to depart for such a mission in the first place.

How do you get around this? You do what we astrodynamicists do a lot of in the Real World: you iterate on your solution. Compute a departure time, toss the burn information into KSP, and get your actual departure time. Put this actual time back into KSPTOT, reoptimize the departure, then put the burn information back into KSP TOT. In one of two iterations, you'll see that your KSP departure time and your KSPTOT departure time are basically the same. That's the burn information you'll want to use to get to Eve.

Is the departure time the time when I start the burn in LKO or the time when the ship is leaving Kerbin's SOI?

[Arrowstar]

I made similar experience like adammada with a Kerbin->Eve->Kerbin flyby optimization. Thanks to MechJeb executing the departure burn, the outbound orbit from LKO and the Sun-centric orbit were relatively accurate (much more than when I would do the burn manually of course) but not accurate enough to actually enter Eve's and Kerbin's SOI. Consequently at least one additional maneuver would be required.

Nevertheless I'm amazed that it works out so well already, without your tool I never would have figured out when and how to depart for such a mission in the first place.

Is the departure time the time when I start the burn in LKO or the time when the ship is leaving Kerbin's SOI?

Thanks, glad everything worked out! I've been using the "Departure Time" as the burn time in LKO, though since the patched-conics thing is only an approximation, you could argue either way.

Something you might try: get the departure date and time from the Flyby program, then go plunk in the departure and arrival times from Kerbin->Eve into the Compute Departure program (accessible from that button on the main GUI). It should give you the same departure burn result. You can use that to iterate on the departure without having to rerun the who flyby optimization thing multiple times to iterate (which, now that I think about it, is impossible at the moment anyway).

I feel like I should put together a tutorial on this whole iteration thing. Should I do that?

[adammada]

I feel like I should put together a tutorial on this whole iteration thing. Should I do that?

Yes. Please include how to best enter it into MechJeb node editor. Or some other plugin node editor?