[WEB APP] Launch Window Planner

[alexmun]

More updates!

Since tavert challenged my assumption that 90 degrees would be an optimal point to perform the plane change maneuver, I decided to implement another transfer type to search for the best time to do the plane change. Unfortunately, this is pretty slow because it has to try many different solutions for each point, however it does show that 90 degrees is usually not optimal although it is usually pretty close to the optimal burn time in terms of delta-v. The biggest difference in the first launch window for the outer planets is again Dres, which goes from 3611 m/s (including insertion) to 3537 m/s.

Also, I have added support for Internet Explorer 10 so now all major browsers are supported.

[alexmun]

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

Yup, that's an orbit that passes very near the center of the sun. Basically a hyperbolic orbit that is nearly a straight line. And to answer your earlier question, yes the calculator handles hyperbolic orbits just fine.

[Fyrem]

Thanks for the ie10 support

[mrenigma03]

Wonderful tool! I sent you a PM about it a few days ago. Let me know if have a moment to read it.

[SRFirefox]

Can I request an option to look for ejection burn dV only when transferring to planets with an atmosphere? I'm sure there are some good trajectories that are being missed because the calculator isn't taking into account the fact that braking is 'free.'

Also, I'm trying to get a small space station to Moho in a fresh save to see how this works, and for the life of me I can't get the calculator to spit out a number I've managed to use. I could be doing it wrong, but here's my stats just to make sure for a Kerbin to Moho transfer, optimized for minimum dV. 100km to 40km orbit, with the trip lasting day 10 to day 33 or day 25 to day 66 depending on which point in the chart you use. Using the sine and cosine of the ejection angle to figure out the prograde and normal dV vectors, I can get the encounters close (in astronomical terms, anywho), but they always seem to arrive when Moho is in another part of it's orbit when the ascending or descending node are adjusted to intercept Moho's orbit as I assume this is where the slightly inclined intercept orbit is intended to meet Moho. The transit times do not seem to be working out either. I'll be trying to make an intercept with the other planets in the near future and let you know how it goes.

Nevermind. Turns out sine/cosine don't work for ballistic trajectories. After much fiddling, I got it!

I see great potential in this widget, and I will be using it greatly in the future if I can get me to work with it. Thanks for the hard work thusfar!

Edited June 21, 2013 by SRFirefox

[tavert]

Can I request an option to look for ejection burn dV only when transferring to planets with an atmosphere? I'm sure there are some good trajectories that are being missed because the calculator isn't taking into account the fact that braking is 'free.'

Just leave the Final orbit altitude blank, and it'll do what you're looking for here.

Not sure what's up with your Moho problem, maybe your measurement of game time is off a bit?

[SRFirefox]

I got it, Tavert. Took a bit of fiddling and I found a trajectory that only took a few hundred m/s more than planned, due to the whole not-instantaneous power problem and the need to make small mid-course corrections. Works a charm!

[aquilux]

Would it be possible to include maneuver node values for these transfers in the "selected transfer details" section? I understand the steps that have been indicated here are rather simple, but it seems a bit inefficient and repetitive to have to do more math after the script has done some already, and then have to eyeball it. There are a few different ways to plug in specific values into maneuver nodes (for example, mechjeb has a maneuver node editor built in), and it would be quite helpful if the script could give us the particulars to adjust our nodes to for each burn.

[fibonatic]

I took a quick look at your source code and I wondered why you are using the mass of the celestial bodies, while you are only using gravitational parameter, since dividing two gravitational parameters yields the same as dividing two masses. Because I would accept that the relative error would go down, since you are currently using a gravitational constant with only 4 digits (G = 6.674e-11). I would like to ask the same question regarding the sphere of influence. Or does the game KSP itself also uses these values?

[alexmun]

I took a quick look at your source code and I wondered why you are using the mass of the celestial bodies, while you are only using gravitational parameter, since dividing two gravitational parameters yields the same as dividing two masses. Because I would accept that the relative error would go down, since you are currently using a gravitational constant with only 4 digits (G = 6.674e-11). I would like to ask the same question regarding the sphere of influence. Or does the game KSP itself also uses these values?

KSP uses the truncated gravitational constant, so that's where that comes from. I can't think of any place where I'm dividing two gravitational parameters off the top of my head, do you have an example? Generally for (simplified, 2-body) orbits all you care about is the gravitation parameter, not the actual masses.

[fibonatic]

KSP uses the truncated gravitational constant, so that's where that comes from. I can't think of any place where I'm dividing two gravitational parameters off the top of my head, do you have an example? Generally for (simplified, 2-body) orbits all you care about is the gravitation parameter, not the actual masses.

I mainly looked at celestialbodies.coffee (weird extension by the way), which uses "Math.pow(@mass / @orbit.referenceBody.mass, 0.4)" which would be the same if you would use the gravitational parameters.

And what about the sphere of influence, since I assume that this would be rounded to a certain value in-game, instead of the exact result from a*(m/M)^0.4?

By the way where did you find that they use that gravitational constant, I did a quick search and got this: http://wiki.kerbalspaceprogram.com/wiki/API:CelestialBody which also states that, but it doesn't give any source.

[alexmun]

I mainly looked at celestialbodies.coffee (weird extension by the way), which uses "Math.pow(@mass / @orbit.referenceBody.mass, 0.4)" which would be the same if you would use the gravitational parameters.

And what about the sphere of influence, since I assume that this would be rounded to a certain value in-game, instead of the exact result from a*(m/M)^0.4?

Ah, yes. I don't actually use the sphere of influence for anything so I had forgotten that. I treat the mass as the underlying value and the gravitational parameter as a (possibly less precise) derived value so I will use the mass where that makes sense such as in that equation.

By the way where did you find that they use that gravitational constant, I did a quick search and got this: http://wiki.kerbalspaceprogram.com/wiki/API:CelestialBody which also states that, but it doesn't give any source.

I think I got it from that same source. I don't remember if I validated it in-game or not, but I think I may have. When you write mods you have access to the innards of the game such as that value.

[alexmun]

I've put up a new version! In addition to an all new lambert solver on the back end, the main new feature is that it now calculates the prograde and normal components of your ejection maneuver. Just hover over the ejection delta-v value and a tooltip will pop up with the details. So if you use something like MechJeb's maneuver node editor you can now enter the values for the maneuver directly.

[Commander Zoom]

You are awesome, and so is this tool. Thank you.

[Guest]

I am trying to figure a launch window for a return to Kerbin from Eeloo. No matter what date I put in as earliest departure, the launch window planner says my departure date is the same as my earliest departure, or right now. For example, what I'm trying to do now is return to Kerbin. My current time is year 2, day 295. Launch window planner says my departure is Year 2, day 295 at 0:00:00. It continues to do this no matter what date you enter for earliest departure. It wants you to leave right now. Is there something I'm missing? This doesn't seem right.

edit : beginning at earliest departure of year 3 day 99 the launch planner begins to give departure dates that aren't right now. It looks like it just starts working at year 3 day 99. I'm confused.

Edited July 6, 2013 by Otis

[m4v]

By the way where did you find that they use that gravitational constant, I did a quick search and got this: http://wiki.kerbalspaceprogram.com/wiki/API:CelestialBody which also states that, but it doesn't give any source.

You can get the gravitational constant in game from the planet's information window in map mode.

[alexmun]

I am trying to figure a launch window for a return to Kerbin from Eeloo. No matter what date I put in as earliest departure, the launch window planner says my departure date is the same as my earliest departure, or right now. For example, what I'm trying to do now is return to Kerbin. My current time is year 2, day 295. Launch window planner says my departure is Year 2, day 295 at 0:00:00. It continues to do this no matter what date you enter for earliest departure. It wants you to leave right now. Is there something I'm missing? This doesn't seem right.

edit : beginning at earliest departure of year 3 day 99 the launch planner begins to give departure dates that aren't right now. It looks like it just starts working at year 3 day 99. I'm confused.

Eeloo is sort of a weird case. Because it's orbit is so slow you can pretty much leave whenever you want as long as you pick a good arrival time back at Kerbin. I've just put up an update that includes advanced controls to change the scale of the x and y axes of the plot that might help you visualize it better.

[alexmun]

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

So I finally got around to implementing these for you, tavert. I decided to just make the transfer time axis the default because I think it makes the periodic nature of the transfer windows a little bit more clear. It is more computationally intensive because I have to recalculate the position of the destination planet for every point instead of just once for every row, but the improvements I've made to the lambert solver recently help to offset the performance penalty.

[Guest]

Thanks alexmun. I am trying to put together an entry for smallest manned craft to Eeloo and back. It's been way harder than I thought it would. For now, I went ahead and left Eeloo soi and the let mechjeb figure a Hohman transfer. I think I've got enough delta-v left to finish the mission. I'll go back later and try to figure out more about what I'm doing wrong.

[tavert]

So I finally got around to implementing these for you, tavert. I decided to just make the transfer time axis the default because I think it makes the periodic nature of the transfer windows a little bit more clear. It is more computationally intensive because I have to recalculate the position of the destination planet for every point instead of just once for every row, but the improvements I've made to the lambert solver recently help to offset the performance penalty.

Thank you thank you! Much awesomeness, glad it wasn't many lines of code to add. Must stop myself from planning a grand tour now...

Couldn't you work along diagonals to avoid recalculating destination position for every point?

[alexmun]

Thank you thank you! Much awesomeness, glad it wasn't many lines of code to add. Must stop myself from planning a grand tour now...

Couldn't you work along diagonals to avoid recalculating destination position for every point?

Unfortunately that only works if the scale of the two axes is the same. I've thought of trying to round the scale of the y-axis to a harmonic of the x-axis to reduce the workload, but I haven't had a chance to try it yet.

[Eric S]

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.

Edited July 11, 2013 by Eric S

[Guest]

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

The parameters you can't see (sorry, on a widescreen laptop) are:

Kerbin 100km orbit

TO

Eeloo 50km orbit

Great tool, by the way; I've used this on missions to Duna and it's spectacularly helpful.

[Mr Shifty]

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

I think if you click on the "Show Advanced Settings..." link, you'll find that your latest departure is set at about year 1 day 132.

[Guest]

I think if you click on the "Show Advanced Settings..." link, you'll find that your latest departure is set at about year 1 day 132.

That helps, thanks. Apparently I need to leave now.