[WEB APP] Launch Window Planner

[alexmun]

I think Chrome 28 broke this, sadly. It still works in Firefox, so I don't think the site itself is broken. :-(

EDIT: I should be more specific. The graphic isn't displaying (at all, even before I hit calculate), but everything else seems to be working fine.

Hmm, Chrome 28 is working fine for me. If you're still having problems, can you let me know what platform you're using (i.e. Windows/Linux/Mac/Android)? Also, if you could go to the Tools menu and click on Javascript Console and let me know any error messages that are displayed, that would be helpful.

I'm getting a strange issue, the dates on the porkchop plot are reversed:

Oops, yeah that's a bug. It should be fixed now.

[Eric S]

Hmm, Chrome 28 is working fine for me. If you're still having problems, can you let me know what platform you're using (i.e. Windows/Linux/Mac/Android)? Also, if you could go to the Tools menu and click on Javascript Console and let me know any error messages that are displayed, that would be helpful.

Was just getting on to say that a full reboot of the computer, thanks to a fan dieing, fixed the problem.

[Nephf]

The site says Minimus, but it's Minmus

And try to plot optimal transfer from a 150 Jool orbit to a 25 Eeloo orbit, is this bugged?

[Spanier]

Could you please some manouver information like the exact ejection orbit and it delta-v values for prograd, normal and radial

And it brakes if you set a minimum of 0 days of flight

Edited July 12, 2013 by Spanier

[alexmun]

The site says Minimus, but it's Minmus

And try to plot optimal transfer from a 150 Jool orbit to a 25 Eeloo orbit, is this bugged?

Good catch on the Minmus typo. It's fixed now.

The Jool to Eeloo transfer is unusual, I think because they are in resonant orbits. If you zoom out (click Show Advanced Settings then set the time of flight between 1 and 4000 days) you can start to see the pattern, particularly on the ballistic transfer type. On the plane change or optimal transfer type there are some discontinuities caused by my assumption that you always want a counter-clockwise transfer orbit. I think there may be a small region near that boundary where a clockwise transfer orbit would be more efficient (but still very expensive).

Could you please some manouver information like the exact ejection orbit and it delta-v values for prograd, normal and radial

And it brakes if you set a minimum of 0 days of flight

Ejection delta-v components are available if you hover over the delta-v value. I've added an underline to make that more obvious. And I've added some more sanity checking to the time of flight values.

[Jackissimus]

This tool is so thought-provoking. Why is it sometimes better to do a mid-course plane change and sometimes not?

[alexmun]

This tool is so thought-provoking. Why is it sometimes better to do a mid-course plane change and sometimes not?

It all depends on how expensive it is to do the plane change required to intercept your target. The two factors that go into determining how expensive the plane change is are:

- The delta-v required for a plane change is directly related to your orbital velocity. So if you're in an eccentric orbit, the closer you are to apoapsis the cheaper it is.

- The delta-v is also related to the sine of the half angle of the inclination change you need to make. Your inclination change is smallest if you change your plane 90 degrees before intercept and increases to 90 degrees if you wait until you're directly "under" your intercept point before making your plane change maneuver.

So for a transfer to an outer planet the mid-course strategy works to find the point at which the decreasing delta-v because you are getting farther from the sun starts to get counteracted by the increasing delta-v as the angle you have to achieve increases towards 90 degrees.

Now, when you're doing a ballistic transfer the raw delta-v for the inclination change is probably a lot higher than the inclination change delta-v for the mid-course strategy. For one thing, your orbital velocity around Kerbin is probably pretty high, and for another to shift your transfer orbit by a degree might take several degrees of inclination change to your ejection orbit (compare your ejection orbit inclination with your transfer orbit inclination to see what I mean). Both of those factors would seem to suggest that the mid-course plane change should always be better. However, there is one big factor in the ballistic strategy's favor and that is the law of cosines.

What the law of cosines says is that if you combine two maneuvers into one you don't have to spend the sum of their delta-v's, instead it's related to the square root of the sum of their squares and the cosine of the angle between them (for a 90 degree angle, this is just the pythagorean theorem). So if we combine our ejection burn with the plane change burn the net delta-v becomes: sqrt(v0^2 + (v0 + dv[ejection])^2 - 2*v0*(v0 + dv[ejection])*cos(angle)).

For a typical Duna transfer, the ejection delta-v without any plane change is about 1040 m/s. To do a ballistic transfer takes about a 2 degree ejection inclination in order to get about a 0.1 degree transfer inclination. Doing the plane change alone in a 100km Kerbin orbit (which has an orbital velocity of about 2250 m/s) would take about 80 m/s. Plugging into the formula we get sqrt(2250^2 + 3290^2 - 2 * 2250 * 3290 * cos(2)) = 1044 m/s. So by combining the maneuvers we get to do an 80 m/s plane change maneuver for only 4 m/s more than the ejection would otherwise take.

TL;DR: It works out that for transfers outer planets with small inclination changes and for transfers to inner planets with moderate inclination changes the ballistic transfer tends to be cheaper because the benefits from combining the maneuvers outweigh the cost of doing the plane change at a less optimal time. However for transfers to outer planets with significant inclination changes or transfers to inner planets with extreme inclination changes the benefits of a cheaper plane change exceed the benefit from combining maneuvers.

[Jackissimus]

Alexmun's post

Ok, I think I sort of understand it, although I'm lucky you wrote the TLDR to sum it up

Is there like a book or something that I should maybe read?

[draeath]

Awesome tool, cheers! Kudos for putting the source up, too.

[Grizzlol]

I am not convinced that leaving the final orbit blank works properly (for fly-by or aerobraking). Plotting a Kerbin to Jool transfer with it blank gives me ejection dV results of around 2000 m/s. If I input a final orbit of 100 km, however, it gives me a best result of 1944 m/s (ejection). Surely the former should be giving lower dV results as the insertion dV is irrelevant and only the injection dV matters.

Otherwise excellent tool with superb results.

Edited July 24, 2013 by Grizzlol

[alexmun]

I am not convinced that leaving the final orbit blank works properly (for fly-by or aerobraking). Plotting a Kerbin to Jool transfer with it blank gives me ejection dV results of around 2000 m/s. If I input a final orbit of 100 km, however, it gives me a best result of 1944 m/s (ejection). Surely the former should be giving lower dV results as the insertion dV is irrelevant and only the injection dV matters.

Running those settings for a day 1 plot gives 1996m/s for a fly-by vs 2002m/s for a transfer with insertion. Can you tell me what other parameters you were using that gave you inconsistent results?

[Grizzlol]

Sorry, I forgot to add the plane change dV, it makes much more sense now.

Edited July 24, 2013 by Grizzlol

[alexmun]

Ok, the main thing is that a mid-course plane change transfer is optimal for transferring to Jool. For a mid-course plane change you need to add both the ejection delta-v and the inclination change delta-v to get the delta-v required to reach your target. In the 150km final orbit case your delta-v to reach jool is 1950m/s ejection delta-v + 138 m/s inclination change delta-v for a total of 2088m/s. In the fly-by case, your delta-v is 2003m/s ejection + 60m/s inclination change for a total of 2063m/s, which is 25m/s cheaper than the insertion case. The reason the inclination change is included is because without the inclination change you will never reach your target.

The other thing to note is that for the fly-by case the point it picked is at the very top of the plot. That usually means there is a more optimal transfer with a longer time of flight. If you increase the time of flight to go up to 600 days in the advanced settings, you'll find a ballistic transfer with an ejection delta-v of 2047m/s which is even cheaper than the previous fly-by solution.

[Grizzlol]

I assume that all transfers (including ballistic trajectories) are, as is explained, assumed to be departed from circular, equatorial orbits. Considering how accurate this tool is, how come you did not add the option to depart from an already appropriately inclined orbit, which would then result in less dV overall? I guess it does not apply if say you were to visit a station at an equatorial orbit first, but otherwise the vehicle could be launched from the ground inclined.

Edited July 26, 2013 by Grizzlol

[voneiden]

I assume that all transfers (including ballistic trajectories) are, as is explained, assumed to be departed from circular, equatorial orbits. Considering how accurate this tool is, how come you did not add the option to depart from an already appropriately inclined orbit, which would then result in less dV overall? I guess it does not apply if say you were to visit a station at an equatorial orbit first, but otherwise the vehicle could be launched from the ground inclined.

Doesn't the lambert solver exactly solve a non-planar transfer? Could "Ejection inclination" be the information you're looking for?

E: Of course you still need to figure the right launch angle and time of launch yourself to be able to get on the correctly oriented parking orbit.

Edited July 27, 2013 by voneiden

[Grizzlol]

Doesn't the lambert solver exactly solve a non-planar transfer? Could "Ejection inclination" be the information you're looking for?

E: Of course you still need to figure the right launch angle and time of launch yourself to be able to get on the correctly oriented parking orbit.

I think that is just the inclination you end up with after the burn is complete. Executing the burn from an equatorial orbit works perfectly well, so I assume that it would not be the case had the same burn been executed from an inclined orbit (given that the ejection dV has a normal or anti-normal component to it).

Edited July 27, 2013 by Grizzlol

[tavert]

You essentially just wouldn't need the normal component of the ejection burn, if you happened to be sitting in an inclined parking orbit with exactly the correct inclination and LAN as the hyperbolic ejection orbit. Timing the LAN to be correct is the tricky part, you'd have to work that out from the ejection angle and the departure time.

[Grizzlol]

That makes sense, so what is missing here is a tool to figure out the approximate launch time and exact inclination which is a problem aside.

[alexmun]

That makes sense, so what is missing here is a tool to figure out the approximate launch time and exact inclination which is a problem aside.

The inclination you want is the ejection inclination. You would want to launch when the KSC is at the ejection angle relative to Kerbin's prograde vector (or actually, just slightly before). The delta-v of the burn from that orbit is a little more complicated than just the prograde component, unfortunately. If v(prograde) is the prograde component of the normal burn, v0 is your circular orbital velocity and i is the inclination, you can calculate the delta-v by:

dv = (v(prograde) + v0) / cos(i) - v0

And you would want to time your burn for when you're passing over the equator in your inclined orbit, either the ascending node for positive inclinations or the descending node for negative inclinations.

Overall the procedure is complicated enough that I don't think it's usually worth it.

[tssn1611]

Any thoughts on adding graphical plotting of the transfer orbits, such as in Arrowstar's KSPTOT, instead of (or in addition to) the text readout? Seems like you might be able to display the same information in a much more intuitive fashion than a wall of text.

BTW, as it is, it's a very nice, light-weight tool. I might try to make use of it for my Moho trip that I have yet to complete ...

Also, a bug report (or perhaps just an oversight): in Chrome 28, the "Reset" button sets the "Latest Departure" field to Year 1, Day 1 and the "Time of Flight" fields both to 1 day.

Edited August 12, 2013 by tssn1611

[alexmun]

Any thoughts on adding graphical plotting of the transfer orbits, such as in Arrowstar's KSPTOT, instead of (or in addition to) the text readout? Seems like you might be able to display the same information in a much more intuitive fashion than a wall of text.

BTW, as it is, it's a very nice, light-weight tool. I might try to make use of it for my Moho trip that I have yet to complete ...

Also, a bug report (or perhaps just an oversight): in Chrome 28, the "Reset" button sets the "Latest Departure" field to Year 1, Day 1 and the "Time of Flight" fields both to 1 day.

I don't have any plans to add a graphical plot of the transfer orbit at the moment. I know it would be useful, but I'm not convinced it's useful enough to justify the effort, at least for me.

Thanks for the bug report, I'll work on getting that fixed.

[regex]

• Added a tooltip to the ejection delta-v parameter giving the prograde and normal components of the maneuver.
  
• Added UT tooltips to dates in the transfer details.

I just noticed this, thank you and well done!

[regex]

I'm a big fan of the ability to do suboptimal transfers at odd times so I do a lot of planning with your app, but I seem to have to do a lot of high delta-V corrections after doing the indicated burn. Here is a plot I recently ran:

I then plugged the UT and burn parameters directly into Maneuver Node Improvement (because MechJeb doesn't allow me to set a UT) and then used MechJeb to execute the maneuver. My craft has a TWR around 0.4 so the burn took a good 6 minutes; not at all unreasonable and MechJeb did a half/half burn so it should be at least be somewhat accurate. Here is the resulting orbit from the plot above:

I don't know if this is an issue with the plot or Maneuver Node Improvement but there are no intercepts on the orbit (you can't really see, but it goes right through Moho's orbit) and it looks like it ended up inclined way too much. I tried doing a correction node but couldn't find an intercept anywhere near the stated time on the plot. It looks like Moho is too far advanced for the earlier time so I tried getting an intercept on the other side of the sun and found a relatively close intercept (not within SOI), but it added an additional 800m/s on to my trip.

I don't know if I just need some direction on using this tool. I'll try using the mid-course correction and just plug in the values, and let MechJeb do the burns to see what happens.

[Crater]

Did you just time it for exactly the UT specified, or did you adjust it to correct the ejection angle? (If the latter, I'd love to know how you worked it out, as I end up eyeballing them as often as not)

[m4v]

In my Moho trip I had to drag around my maneuver node (neglecting the whole "your ejection path must be parallel" stuff since I couldn't get even a close approach marker with that) for get an intersect, it was all good until I had to do the insertion burn, as I had to use like 4km/s more of what it was indicated by the app. It was the same launch window, with departure in day 10. Next time I will try to be more rigorous but it does seem that small errors in your initial burn create bigger ones later.