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.