alexmun

Historically, the launch window planner has used Earth time. I've now added an option so you can use whichever time system Everything you need to change is in the celestialbodies.js file. All values are in meters, kilograms, seconds or the appropriate combination thereof.

Hi Regex, It looks to me like you updated Duna's orbit but not Kerbin's. In the code you posted Duna's semi-major axis is about 10x Kerbin's, which doesn't seem right.

The problem here is Moho. MechJeb's transfer maneuver generator calculates a Hohmann transfer (just like Protractor, ksp.olex.biz, etc). This works great for Eve, Duna, Jool or other bodies with orbits that are mostly circular with low inclinations. It doesn't work so well for Eeloo, Dres, or especially Moho. MechJeb's midcourse correction maneuver does properly account for Moho's eccentricity and inclination so it has to use a lot of delta-v to fix the bad ejection burn. It's possible that a midcourse correction somewhere else along your transfer orbit could be substantially cheaper (I've had what would have been a 150m/s burn drop to 7m/s just by changing when the burn was executed), so you might try it at different points along your transfer. However, if you want to create a truly efficient transfer to Moho you're going to need use a different strategy than a Hohmann transfer. For example, you could use a gravity assist from Eve to help lower your orbit. You could use a pork chop plot generator, like my launch window planner, to calculate a non-Hohmann ejection burn. I've even seen someone recommend just targeting your transfer at Moho's periapsis then waiting however many orbits it takes to get a close encounter. Finally, be aware that your Moho capture burn can be prohibitively expensive unless you have a very good transfer that ends up with a small amount of relative velocity at intercept. A bad transfer can easily leave you with a 5000m/s or greater capture burn. Also, there's no need to match Moho's inclination. You just need your transfer orbit to intersect Moho's at the point of intercept.

Yes, it surprised me too. If you only have to pay half the ÃŽâ€v to raise then re-circularize, the formula becomes: Apoapsis = r * sin(θ/2) / (0.5 - 2 * sin(θ/2)) In that case, the critical angles are 19.2 degrees and 28.96 degrees. Below 19.2 degrees do the maneuver in your original orbit. At or above 28.96 degrees raise your apoapsis to the SoI. In between use the formula. And, of course, if you don't have to pay any of the ÃŽâ€v to raise then re-circularize (e.g. you're aerobraking in from an interplanetary transfer) then you always want the apoapsis for your plane change maneuver to be as high as possible. For example, aerobrake to a very high apoapsis, do your plane change maneuver, then aerobrake to a circular orbit.

Ok, I worked on this some more. The solution to your original equation is: Apoapsis = 2 * r * sin2(θ/2) / (2 - (sin(θ/2) + 1)2) Where r is your initial circular orbital radius and θ is the angle of inclination change. That equation will give you the apoapsis where raising your orbit to that apoapsis, doing the plane change, then circularizing costs exactly the same ÃŽâ€v as doing the plane change directly. However, what we actually want to know is what is the optimal apoapsis to raise our orbit to for a minimal ÃŽâ€v plane change. That equation turns out to be: Apoapsis = r * sin(θ/2) / (1 - 2 * sin(θ/2)) You will find that for angles less than 38.9 degrees, that formula gives you an apoapsis less than your current orbital radius (which is non-sensical). So for those angles, doing the plane change without changing your apoapsis is optimal. At 60 degrees, the formula gives an apoapsis of infinity, so for angles greater than 60 degrees raising your apoapsis to just inside the SoI and doing the maneuver is optimal. For angles between 38.9 degrees and 60 degrees, raise your apoapsis to the radius given by the formula, do your plane change maneuver there, then re-circularize. For plane change angles less than 50 degrees or so, you're going to save less than 5% ÃŽâ€v compared to just doing a simple plane change in your original orbit, so for small plane change angles this method is probably not worth it. For large plane change angles, however, the savings become significant, getting to about 40% by 90 degrees and up to a max of about 60% for a 180 degree plane change.

Actually, I just realized that this equation: ÃŽâ€i = 2 asin(vesc/v - 1) = 2 asin(sqrt(2) - 1) = 48.9 degrees. So that threshold is constant regardless of your starting orbit. If you are making a plane change of greater than 48.9 degrees, it is most efficient to raise your apoapsis as high as possible, do the plane change, then recircularize. The higher you raise your apoapsis in that case, the more efficient the maneuver will be. If you are making a plane change of less than 48.9 degrees it is most efficient to just do it in your existing orbit.

Your basic plane change ÃŽâ€v formula can be simplified to: ÃŽâ€v = 2v sin(ÃŽâ€i/2) Second, let me take a tangent to solve a related problem. There is a threshold of ÃŽâ€i at which the bi-elliptic method of plane change becomes more efficient. Below that threshold it doesn't matter how high you raise your apoapsis it will never be more efficient than doing the plane change from your original orbit. We can find that threshold fairly easily by solving for the case where your a2 = infinity (i.e. a parabolic orbit where the apoapsis is at infinity). At infinity, the your orbital velocity is zero and therefore your plane change costs zero ÃŽâ€v and we can calculate the total ÃŽâ€v as just the ÃŽâ€v to raise your apoapsis to infinity and then lower it again. The velocity required to put your apoapsis at infinity is just the escape velocity, so that ÃŽâ€v is twice the difference between the escape velocity and your orbital velocity. So we can solve: v = sqrt(μ/r) vesc = sqrt(2μ/r) 2(vesc - v) = 2v sin(ÃŽâ€i/2) ÃŽâ€i = 2 asin(vesc/v - 1) If your ÃŽâ€i is above that threshold, it will be more efficient to raise your apoapsis, do the plane change, then recircularize than to do the plane change directly from your circular orbit (well, unless it's really really close to the threshold and you'd have to put your apoapsis outside of the SoI). The higher you can raise your apoapsis, the more efficient the overall maneuver will be. Edit: Assuming I haven't made any errors (which may be a big assumption), I think your original equation simplifies down to: a2 = a1 * (sin(theta / 2)^2 + 1) / (4 * sin(theta / 2) + 2) Nope, this was wrong.

Period = 2 * pi * sqrt( a^3 / mu ) Apoapsis radius = a * (1 + e) Periapsis radius = a * (1 - e) Given the period and gravitational parameter of the central body (mu), you can solve for the semi-major axis (a). Given the semi-major axis and the apoapsis you can solve for the eccentricity (e). Given the semi-major axis and eccentricity the periapsis is trivial to calculate.

You can try to walk the intercept in by slowly burning along the three major axes (prograde, normal, and radial). The axis to start with depends on your situation. If you have closest approach markers (and they look to be in about the right place) and are around 180 degrees from your target, start with the prograde/retrograde axis. Burn a little prograde and see if the approach gets closer. If not burn retrograde instead until the closest approach hits a minimum. Then switch to another axis (radial in/out or normal/anti-normal) and burn until the distance is minimized for that axis. Repeat for the last axis then start over again until you get an encounter. If you're closer to 90 degrees until intercept, start with the radial axis. If you don't have closest approach markers at all, start by burning normal/anti-normal until either the ascending or descending node marker (whichever was closer) intersects the target orbit at the point where you expect to intercept the planet. That should give you the closest approach markers so you can adjust the other axes. Walking the intercept in manually like that will usually work but it's not very efficient and can be time consuming. If you happen to be using a mod that gives you your orbital elements (like Kerbal Engineer Redux, MechJeb, or Telemachus) or you're willing to fish around in the persistent.sfs file for them, you can use my Launch Window Planner calculator (see link in my sig) to generate a precise correction burn. Just click "Add Body" next to the origin selection, enter in the orbital elements of your vessel, select your destination and it will generate a pork chop plot of all the possible transfers from your orbit to your target. If you're close to an intercept already, this plot will look like a diagonal blue/green line from top left to bottom right. You may want to zoom in on the line a bit to get a better fix on when to do your burn, then you can get the details for your midcourse correction by clicking on the info icon next to the "ejection burn delta-v" value. It will give you the prograde/radial/normal delta-v values for making a maneuver node as well as the pitch and heading of the burn if you'd rather do the burn that way. Do note that the burn it gives you will probably put you on a collision course with the planet so you may want to cut it short once you see your periapsis hit the level you want.

Ok, if I understand what you're trying to do correctly, you should be able to do it with just one fuel depot. Kerbin's orbital period is ~106.5 days. The synodic period between Kerbin and Duna (which is the time between Hohmann transfer windows) is ~227.4 days. That means Kerbin will complete 2.135 (227.4 / 106.5) orbits between transfer windows. Therefore Kerbin's prograde direction will move by 360 * 0.135 = 48.4 degrees from one transfer window to the next. All you need is an orbit for your fuel depot that completes x.135 orbits in 227.4 days where 'x' is an integer. That will make sure that your fuel depot is at the same angle to Kerbin's prograde at every Hohmann transfer window. A circular orbit right at Kerbin's SOI boundary would have a period of ~29.9 days. That would have about 7.6 orbits per synodic period, so let's pick an orbit that would have 8.135 orbits per synodic period or ~27.9 days per orbit. That gives an orbit with a semi-major axis of ~80505.5 km or an altitude of ~79905.5 km (that's within 4000km of the SOI). You will still need to position the station so that in the time it takes to go from its altitude to your periapsis where you're executing your ejection burn you end up at the correct ejection angle. But if you get it right for one transfer window with a station at that altitude it should continue to be right for all subsequent transfer windows.

You're looking for the great circle distance in spherical geometry: http://en.wikipedia.org/wiki/Great-circle_distance d = r * acos( sin(lat1) * sin(lat2) + cos(lat1) * cos(lat2) * cos(|long2 - long1|) ) r is the radius of the sphere, you could use the average altitude of your two points plus the sea level radius to get a more accurate result than just using sea level radius. |long2 - long1| should be the included angle between the two longitudes (e.g. if the longitudes were 170 and -170, the difference would be 20 degrees).

Another quick update. I've added a "Refine transfer" button, which adjusts the selected transfer's ejection burn taking into account how your transfer orbit is affected by your origin body while you're leaving it's sphere of influence. This makes the calculated ejection burn details more accurate. The difference is pretty minor for planetary transfers, because the planet's sphere of influence tends to be quite small relative to the distance of the transfer. But the difference can be significant for transfers between moons.

In that case you're asking when the synodic period of Duna will line up with its sidereal period. The synodic period is how long it takes for Kerbin and Duna to reach the same angle again, and there is one transfer window per synodic period. The sidereal period is just how long it takes Duna to go around the sun. The simple answer to your question is never. A slightly more accurate answer is about a million years (Earth-years, not Kerbin-years). That would work out to around 1.6 million transfer windows. You'd get a smaller number if you'd accept an approximate alignment (say +/- 1 degree from the original alignment), but that gets much harder to calculate.

-247 should mean the exact same thing as 113, it's just a wrapping error. I'd assume positive is East, but I don't know for sure. This is the cheapest way I know to set your inclination after an interplanetary transfer: After entering the SoI (or even before, if you're really good with fine tuning maneuver nodes) adjust your orbit so that the latitude of your periapsis is close to the equator. If you're trying to match the orbit of another vessel, target it and adjust your periapsis to be at a node (ascending or descending) with the other orbit. When you get to periapsis, burn retrograde until your apoapsis is just inside the sphere of influence. When you get to apoapsis, burn normal/antinormal to get the inclination you want. This should take only a few m/s of delta-v because you will be moving very slowly. Finally, when you get back to periapsis, you can circularize into your final orbit. You can calculate how much delta-v a plane change costs using: dv = 2 * v * sin(theta / 2) Where v is your orbital velocity when you perform the maneuver and theta is the angle by which you want to change your orbit. If you target your other ship, you can read that angle off the node and calculate whether you have enough left to do the plane change. For large plane change maneuvers, you can also use a bi-elliptic strategy, where you would burn prograde at a node (ascending or descending) until your apoapsis is near the edge of the sphere of influence, coast to apoapsis, do the plane change there (which will be much cheaper due to the lower orbital velocity), then re-circularize at periapsis. Finally, the reason your two 24 degree inclination orbits don't line up is that your orbital plane is defined by two numbers, inclination and longitude of ascending node (which is where the orbit crosses the equator, and confusingly has nothing to do with terrestrial longitudes). So even though your two orbits have the same inclination, they have different longitudes of ascending nodes (238 vs 167), and so they're on different planes.

Thanks for the detailed bug report! It should be fixed now. It's licensed under Creative Commons BY-SA-NC, so feel free to fork it! All you should have to edit is the celestialbodies.coffee or celestialbodies.js files (and maybe change some of the defaults in porkchop.coffee from Kerbin/Duna to whatever is appropriate). If you change the name of the sun from Kerbol, there's a few other references you'd have to update.

I've updated the Launch Window Planner to have greater accuracy in its delta-v calculations, particularly for bodies with relatively small spheres of influence. This should help those using maneuver node editors to execute more precise transfer burns. In the process I discovered that optimal (e.g. Hohmann) transfers from Laythe to Vall are not physically possible, so you will now see a section of that plot that is inaccessible (unless your parking orbit is 20km or more below the surface).

I've done some more work and it turns out there's another wrinkle to this case. There is no orbit with a periapsis above the surface of Laythe that will leave you with 347 m/s when leaving the sphere of influence. The reason for this is that an orbit with a periapsis altitude of 0 (on the surface), and a apoapsis equal to the edge of the sphere of influence, has a speed at apoapsis of 353 m/s. The higher your periapsis above the surface, the faster your speed at apoapsis will be, so 353 m/s is your minimum excess velocity for a single burn ejection from Laythe. As a result, it is not possible to execute a pure Hohmann transfer from Laythe to Vall (which is too bad, since they're the only two bodies in the game with zero inclination and eccentricity around a common parent, i.e. the only two bodies for which a Hohmann transfer is actually correct). You will either need to depart or arrive at a different time, or you will need to make midcourse corrections at some point during the transfer. Thanks for bringing this question up. I've updated my calculator to give more accurate results in situations like this.

The only way to match inclinations upon ejection is to leave Kerbin's sphere of influence at one of the nodes (either ascending or descending). Your ejection trajectory will actually need to have a greater inclination than your target orbit's inclination because when you leave Kerbin's sphere of influence your net solar orbital velocity is the sum of Kerbin's orbital velocity (which has no inclination) and your velocity relative to Kerbin. But the fact that you have to leave the sphere of influence at the node makes matching the inclination directly from Kerbin orbit usually infeasible because it is rare for a transfer window to line up with a node. The good news is you don't actually have to match inclinations at all in order to transfer. All you need to do is get a node (either ascending or descending) of your transfer orbit to intersect your target's orbit at the right time. This method can save a ton of delta-v relative to trying to exactly match the target's inclination, but it can be more difficult to find an intercept.

Your problem is that Laythe's sphere of influence is relatively small for its mass because it is so close to Jool. As a result, the ejection orbit that gets you into Jool orbit with the correct velocity is not actually a hyperbolic escape orbit, but just an elliptical orbit with an apoapsis outside of Laythe's sphere of influence. This means you can't use the true anomaly at infinity to calculate the ejection angle, because an elliptical orbit does not go to infinity. Specifically, instead of: theta = acos(-1/e) use: e (eccentricity) = r1 * v1^2 / u - 1 a (semi-major axis) = r1 / (1 - e) theta (ejection angle) = acos((a * (1 - e^2) - r2) / (e * r2)) This equation also works for hyperbolic ejections and will be marginally more accurate than the simpler version at the expense of a lot more terms.

If you click the blue info icon after the ejection delta-v value, it will give you a full breakdown of the delta-v components.

Yup, it sure does.

I've just added the ability to add new planets to my launch window calculator (http://alexmoon.github.io/ksp), so if you have the orbital elements of the new planets, you can add them and calculate whatever you need.

The Hohmann transfer from Kerbin to Duna comes around about every 227 days. If you're 209 days from the next transfer, that means you're only about 18 days past the last transfer. The Duna launch window is pretty big, so you should still be able to launch right now without a big delta-v penalty. For example, if I use the calculator in my sig to find a launch window on day 84 (18 days after the first optimal launch window, which occurs on day 66) I get an ejection delta-v of 1162 m/s vs the optimal ejection delta-v of 1046 m/s, so you're only getting a penalty of about 120 m/s for launching late. Now, if you aren't doing an aerocapture, you may have a greater penalty on the insertion side because you will end up catching up to Duna with a greater relative velocity (in my example it ended up being 1189 m/s vs 647 m/s). I should also note the time of flight for the later launch is much longer (120 days vs 66 days), but you'll still get there earlier than if you waited for the next window to come around. The bottom line is (1) launch windows are bigger than you think, and (2) you can always get from point a to point b, it's just a matter of how much delta-v you have to spend.

That is a very cool tool! Unfortunately, I don't think it's computationally feasible to calculate all those windows in real time. Someone has gone through and created a spreadsheet of launch windows which you could use to create a plot like that: http://www.reddit.com/r/KerbalAcademy/comments/1qt764/a_compiled_list_of_optimal_interplanetary/ Eventually, I would like to make it possible to calculate ejections from an arbitrary parking orbit, using the new features to add your vessel's orbital elements. No idea when I'll get around to doing that, however, because the current calculations take a lot of shortcuts based on the equatorial, circular assumptions.

A new version of the launch window planner is now live! Aside from some cosmetic upgrades, the main new feature for this version is the ability to edit the list of celestial bodies. You can now add new planets and moons to the list. You can also add your vessels, if you have their orbital elements from MechJeb, Kerbal Engineer, Telemachus, or the like. This allows you to do fun things like get a pork chop plot for transfers from any Kerbin orbit to the Mun or plotting a rendezvous with a stranded ship in solar orbit, or even just a simple rendezvous between two ships in Kerbin orbit. Now to catch up on some old questions... The amount of time it takes to calculate the plot is directly related to the size of the graph. I've chosen the current size to give a good trade-off of speed vs detail. If you need more detail, you can always zoom in on an area of interest using the advanced settings. You can read the flight time and time of departure (roughly) by looking at the Y and X axes of the graph, respectively. The new version does allow you to select the component delta-v's of your ejection burn after you click on the little info button. If you enter 0 for your initial orbit, it will calculate a plot that ignores the origin planet's gravity which can give you an idea of what launch windows are open at what times for a given planet. The ejection delta-v that it gives you on that plot will represent the "hyperbolic excess velocity" you would need when leaving the planet's sphere of influence to get to your next destination. Actually calculating a gravity assisted trajectory is a much harder problem that is beyond what I plan to do with this tool. I've just released an update that allows you to edit the orbits and parameters of all the bodies in the system (except for the Sun). If you have the orbital elements of the Real Solar System bodies, you could enter them in and everything should work, except that you would also need to change the values for the Sun. That you would need to do from your browser's javascript console with the command: CelestialBody.Kerbol.mass = mass CelestialBody.Kerbol.gravitationalParameter = 6.674e-11 * mass CelestialBody.Kerbol.radius = radius Where mass is the mass of the Sun in kilograms and radius is the radius of the Sun in meters. If somebody wanted to fork the project to provide the Real Solar System bodies by default, that would be very easy to do and fine with me.