[WEB APP] Launch Window Planner

[alexmun]

What is it?

After one too many failed attempts to make it to Moho with a minimal delta-v vehicle using the standard Hohmann transfer calculations I decided I needed a tool that would let me calculate transfers to and from eccentric and inclined orbits quickly and easily. Not finding such a tool already out there I decided I'd have to just make it myself.

What does it do?

Just give it basic information about the transfer you wish to perform and it will create a porkchop plot showing you the delta-v required to execute the transfer depending on the time of departure and time of arrival. Once you have picked a departure and arrival time you can click on that point of the chart to get a detailed look at the maneuvers needed to perform the transfer.

What does it look like?

Like this:

Looks awesome! How do I use it?

Just go to http://alexmoon.github.io/ksp and follow the instructions. To get the most use out of it, you'll probably want a few mods such as Kerbal Alarm Clock to keep track of the current time and Kerbal Engineer Redux or MechJeb to monitor your orbital characteristics. Please note that there is a bug in the current version (6.0.3) of Kerbal Engineer: when performing a transfer to a body with a smaller orbit, the "Angle to Retrograde" displayed is actually your angle from retrograde, so you'll need to subtract it from 360 degrees to get your actual angle to retrograde. I also calculate the phase angle slightly differently from how Kerbal Engineer does so it may be off by a few degrees for inclined orbits. Finally, I don't personally use MechJeb so while I assume it gives you enough information to set up the ejection maneuver correctly, I haven't actually tried it.

I look forward to getting lots of great feedback from the community. Please let me know if you run into any bugs or errors or if there is other data you would like to see.

Changes

2014-04-06

• Added support for Kerbin time.
  
• Changed the color map to use a logarithmic scale.
  

2014-03-02

• Added support for multiple-revolution ballistic transfers.
  

2014-01-26

• Added ability to edit orbits and add new bodies.
  
• Improved UI.
  

2013-07-06

• Changed the y-axis of the plot to be time of flight instead of arrival date. This makes the whole area of the plot meaningful and makes the periodic nature of the launch windows more clear.
  
• Added advanced settings to optionally control the scale of the x and y axes to let you zoom in or out on an area of the plot you are interested in.
  

2013-07-04

• Implemented an all-new lambert solver. More robust and much faster than the old one.
  
• 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.
  
• Fixed a minor bug in the ejection angle calculation.
  

2013-06-04

• Another new transfer type! The optimal plane change transfer searches for the best possible angle at which to perform the plane change maneuver. This is fairly slow, so I've also kept the previous mid-course plane change transfer type which uses 90 degrees to intercept as a reasonable guess.
  
• The optimum transfer type now chooses between the ballistic and optimal plane change transfer types instead of using the mid-course plane change transfer type. That does mean it is now as slow to calculate as the optimal plane change transfer type.
  
• Internet Explorer 10 is now supported.
  

2013-06-03

• New transfer types! You can now compare ballistic transfers (a single ejection burn to create an intersecting orbit) to transfers with a mid-course plane change, or select optimal to automatically pick the lowest delta-v transfer type.
  
• Crosshairs on the chart show your selected transfer
  
• The minimum delta-v transfer is now selected automatically after plot generation
  

2013-05-30

• Initial release
  

Edited April 7, 2014 by alexmun

[rkman]

Very nice. I'll be using this.

[tavert]

Nicely done, I've been waiting for something as polished as this and was hoping I wouldn't have to go write it myself! Interesting that your source web page refers to the Lambert problem as the Gauss problem, ah well. This doesn't need web connectivity to run does it? If I download the page to my local machine will it work offline?

Edit: Could you add a "select optimum" button to show details on the best transfer plotted, so we don't have to fish around inside the lowest contour? And how about an option to switch between plotting with the conventional arrival date on the y axis, or transfer time on the y axis (to get rid of the triangle of wasted space). Configurable axis limits for zoom/translation would also be cool.

Edited June 1, 2013 by tavert

[alexmun]

This doesn't need web connectivity to run does it? If I download the page to my local machine will it work offline?

As long as you download all the scripts, stylesheets and images it should work fine offline. All the calculations are performed in the browser.

[Mr Shifty]

Is the gradient at a transfer angle of 180 real or an artifact of the discontinuity in the solution to the vector problem there? Seems like if the transfer angle is 180, you could just do a regular Hohmann transfer at any inclination, which my (probably faulty) intuition tells me would be a minimum delta-V solution.

[alexmun]

Is the gradient at a transfer angle of 180 real or an artifact of the discontinuity in the solution to the vector problem there? Seems like if the transfer angle is 180, you could just do a regular Hohmann transfer at any inclination, which my (probably faulty) intuition tells me would be a minimum delta-V solution.

The Hohmann transfer is ideal as long as the orbits are coplanar. When the orbits are not coplanar 180 degrees is actually bad because it takes a lot of delta-v to rotate your apoapsis around to hit your target. If you compare a Kerbin-Duna plot to a Kerbin-Moho plot you can see the difference. The Kerbin-Duna plot (which has very little relative inclination) is mostly one large window with a very narrow line at transfers very close to 180 degrees that are slightly more expensive. The Kerbin-Moho plot (which has significant relative inclination), on the other hand shows two distinct lobes, one for transfers of less than 180 degrees and one for transfers of more than 180 degrees with a large "ridge" separating them.

Kerbin and Duna are close enough to coplanar that you can pretty much ignore the problem, especially since you don't actually want to hit the planet, although you can theoretically save a few delta-v by doing a few degrees off of 180. Kerbin and Moho are far enough apart in inclination that it would be very expensive to try to do a 180 degree transfer.

[tavert]

I think Mr Shifty's noticing a singularity in the solutions for 180-degree transfers. Are all of the transfers trying to hit exactly the center of the target planet, or is there a fudge factor in there for "close enough to target"? It looks as if might be the former, so for 180-degree transfers you may need some crazy inclination to hit the target exactly. Example:

Kerbin to Duna, initial 100 km, final blank, earliest departure year 1 day 1. For the transfer with departure at year 1, day 61, 8:42:22 and arrival at year 1, day 136, 9:55:11, the transfer inclination ends up being 27.66 degrees, ejection inclination is -86.41 degrees, giving crazy ejection delta-V of 5989 m/s. And a NaN ejection angle...

Notice how the singularity goes away (and Hohmann 180-degree transfers are actually optimal) for transfers between Laythe and Vall, which is currently the only exactly circular and coplanar transfer pair.

Edited June 1, 2013 by tavert

[alexmun]

Are all of the transfers trying to hit exactly the center of the target planet, or is there a fudge factor in there for "close enough to target"? It looks as if might be the former, so for 180-degree transfers you may need some crazy inclination to hit the target exactly.

Yes, that's exactly right. The transfers try to hit the center of the planet which becomes pathological at 180 degrees if there is any inclination at all between the orbits. The Hohmann transfer works for Duna even though it is inclined because the inclination is low enough that its sphere of influence always intersects the ecliptic. I find it interesting that the lambert problem finds a solution of 1046 m/s delta-v at a transfer angle of 165 degrees vs the Hohmann transfer's delta-v of 1043 m/s with a small mid-course inclination correction required, so I think they end up being very close in delta-v required. The Hohmann transfer may require less delta-v for the insertion burn, because the orbits will intersect at a smaller angle.

[Mr Shifty]

How are you burning at the correct ejection inclination? It's easy enough to start my burn at the correct angle to prograde using Engineer Redux, but adjusting inclination using just the navball seems... imprecise, and just a tenth of a degree can mean your approach is way north or south of the target.

I suppose you could adjust your orbit around the origin body so that it's inclined at the proper angle, with either the ascending or descending node at the ejection angle as appropriate. You'd have to do it pretty near in time to your launch so that the origin's prograde direction doesn't change appreciably. Then you could just burn prograde when your launch window shows up.

Edited June 1, 2013 by Mr Shifty

[alexmun]

How are you burning at the correct ejection inclination? It's easy enough to start my burn at the correct angle to prograde using Engineer Redux, but adjusting inclination using just the navball seems... imprecise, and just a tenth of a degree can mean your approach is way north or south of the target.

What I do is guesstimate based on my orbital velocity and the delta-v of the burn. For example, if my orbital velocity is 2000 m/s and my delta-v is also 2000 m/s and the ejection inclination is 2.8 degrees, I would burn about 5.6 degrees north of prograde on the navball. If the delta-v is more than your starting velocity, burn closer to the desired angle, if it's less burn proportionally farther north or south of prograde. Then after the main burn is complete I check my inclination with Kerbal Engineer and make fine adjustments north or south as necessary. It's not perfect but it seems to work pretty well.

Also, keep in mind you'll probably need to start your burn before you get to the actual ejection angle since your engines don't have unlimited thrust. I try to split the difference so I'm halfway through the burn when I hit the ejection angle.

[Mr Shifty]

Also, keep in mind you'll probably need to start your burn before you get to the actual ejection angle since your engines don't have unlimited thrust. I try to split the difference so I'm halfway through the burn when I hit the ejection angle.

You can set up a maneuvering node to help. This worked for me to catch Eve from Kerbal. I came really close to ejection delta-V and transit time estimations. I did end up pretty far from Eve (~50,000km periapsis) so the injection burn was really long, but with some tweaking, it should be possible to get much closer.

1. Rotate the camera in map view until you're looking directly down (south) onto the origin body

2. Zoom out until you can see the path of the origin body around its primary (e.g. the sun for planets)

3. Rotate the camera until the prograde procession around the primary is pointing up.

4. Locate the approximate escape angle and put a maneuvering node there.

5. Add prograde to the maneuvering node until it matches the prograde component of the ejection delta-V (should be delta-V*cosine(ejection-inclination.)

6. Zoom out until you can see the escape path for your ship.

7. Pull the manuevering node around your orbital path until the escape path is parallel to the prograde direction if you're moving to a higher orbit or to the retrograde if lower. It should be pretty close to start with since you put it at the approximate angle to prograde in step 4.

8.Zoom out and adjust the north/south on the manuevering node until you see intercept with the target. Total delta-V should match the ejection delta-V.

I used dual LV-N's for transfer so the ejection burn runs about 3 minutes/1,000m/s. Like you said, centering the timespan on the burn point seems to work pretty well.

You could add the prograde/retrograde and north/south components of the ejection delta-V to the calculator, but it's not hard to calculate cosines.

Edited June 1, 2013 by Mr Shifty

[Mr Shifty]

If you don't mind, I think I'm going to make a guide based on those steps.

[alexmun]

If you don't mind, I think I'm going to make a guide based on those steps.

That sounds great!

[Mr Shifty]

Tutorial is here.

[alterbaron]

Wow, this tool is very impressive!

I took a peek at your code and coffeescript looks really nice. I might have to try it in my next project.

[alexmun]

Wow, this tool is very impressive!

I took a peek at your code and coffeescript looks really nice. I might have to try it in my next project.

Thanks, alterbaron! I like coffeescript a lot, it makes javascript programming much more pleasant IMHO.

[alexmun]

I've made a couple of updates to the calculator. The main one is that it can now calculate transfers consisting of an in-plane ejection followed by a mid-course inclination change burn (suggested by tavert). The plane change burn is done at 90 degrees to intercept for optimum efficiency. The two methods have slightly different launch windows but largely similar delta-vs as long as the inclination between origin and destination is not great (as one would expect). If there is a significant inclination difference, the plane change method can be significantly cheaper when transferring to a higher orbit (for example, the first launch window to Dres is about 500m/s cheaper with the plane change method). The ballistic method seems to be consistently cheaper when transferring to a lower orbit. You can also have the calculator select the optimal transfer type at each point on the plot which tends to increase the size of your possible launch windows.

[tavert]

I've made a couple of updates to the calculator. The main one is that it can now calculate transfers consisting of an in-plane ejection followed by a mid-course inclination change burn (suggested by tavert). The plane change burn is done at 90 degrees to intercept for optimum efficiency. The two methods have slightly different launch windows but largely similar delta-vs as long as the inclination between origin and destination is not great (as one would expect). If there is a significant inclination difference, the plane change method can be significantly cheaper when transferring to a higher orbit (for example, the first launch window to Dres is about 500m/s cheaper with the plane change method). The ballistic method seems to be consistently cheaper when transferring to a lower orbit. You can also have the calculator select the optimal transfer type at each point on the plot which tends to increase the size of your possible launch windows.

Very nice! Can you explain in a bit more detail why 90 degrees from intercept is the optimum time to do a plane change? It sort of makes sense intuitively, but couldn't it be more efficient in some circumstances to do the plane change with either a longer time to intercept, or at a further solar distance?

Couple feature requests that I for one would find quite useful:

- Could we optionally switch the y axis to transfer time instead of arrival time? The triangle of wasted space bugs me.

- "Detailed options" for user-selectable upper limits on the axes.

- Decimal days (or hour/minute fields in "detailed mode") for more precision with some of the moon-to-moon transfers

(Also thanks for auto-selecting the optimum point, super useful!)

[Specialist290]

I'm getting a weird error with the new planner. The "porkchop plot" isn't showing up -- just a red background and a greyed-out cross. Also, it doesn't let me select any other routes than the first one that displays.

I'm running the latest version of Firefox, if that matters.

[alexmun]

Very nice! Can you explain in a bit more detail why 90 degrees from intercept is the optimum time to do a plane change? It sort of makes sense intuitively, but couldn't it be more efficient in some circumstances to do the plane change with either a longer time to intercept, or at a further solar distance?

90 degrees isn't really optimal in all cases. For example, you could set up a bi-elliptic transfer with an inclination change at apoapsis which would end up being cheaper (assuming the bi-elliptic transfer is cheaper than a two-impulse transfer in the first place). However, I think it should be optimal or close to optimal in nearly all reasonable cases since it minimizes the angle of the plane change required for intercept and it makes the math dramatically simpler because the plane change does not otherwise interfere with your transfer orbit (whereas at other angles a plane change will also change the radius of your intercept point).

I'm getting a weird error with the new planner. The "porkchop plot" isn't showing up -- just a red background and a greyed-out cross. Also, it doesn't let me select any other routes than the first one that displays.

I'm running the latest version of Firefox, if that matters.

Stupid browser compatibility bugs! It should be fixed now.

[Specialist290]

Indeed it is. Thanks!

[TriggerAu]

I love this tool. It is soo useful and the graphic makes it easy to visualise the idea of it being a window to transfer and what the effect of missing it will be. Kudo's alexmun, many kudos.

[Mr Shifty]

Great updates! I notice that the 180 degree gradients are gone on the mid-course plane change graph (and thus on the optimal solution.) I presume this is because you've made the plane change for those Hohmann-like transfers much more efficient by moving it to mid-course.

- Regarding the 90 degree point: I could easily be mis-understanding the mechanics, but shouldn't the course-correction point be a 90 (or 270) degree true anomaly on the transfer ellipse to ensure that the radius to target doesn't change. You're currently calculating it by determining the true anomaly at the destination and subtracting 90 degrees (with a fallback to ballistic if the transfer angle is less than 90 degrees.) But that doesn't result in a 90 or 270 degree true anomaly at course change unless the transfer is Hohmann.

- Some of the solutions have a negative periapsis. What does that mean physically? I understand a negative apoapsis represents a hyperbolic orbit (and does this calculator work for such orbital transfers?), but what does a negative periapsis mean?

[tavert]

How far negative, can you give an example? If it's negative but still greater than -r, it just means the periapsis is below the surface of the parent body. If it's negative but less than -r, that seems like a bug.

[Mr Shifty]

How far negative, can you give an example? If it's negative but still greater than -r, it just means the periapsis is below the surface of the parent body. If it's negative but less than -r, that seems like a bug.

Here's an example. After thinking about it for a minute, I think you're right, but the "parent" body is actually Kerbol in this case, not Kerbin. Kerbol's radius is 261.6Mm, which I supposed means this orbit would pass through the sun if it were continued past Jool (but at a transfer angle of 4 degrees, it probably wouldn't pass through during transfer.)

Edited June 5, 2013 by Mr Shifty