Mun Free Returns (Spoilerish, I think)

[Fel]

Just a bit of a question as to how things work, I think.

For the past few mun launches (usually 1 -> 2 min burns), I've been somewhat manually piloting the craft from an equatorial orbit at the mun. I target the mun, and just follow the pink targeting cursor... and then I always seem to manage to get a heart shaped orbit.

http://i.imgur.com/QkCIX15.png

Now I recognize this as a free return; but I have no idea how the heck I managed to get it. I wanted to test a theory (Mostly that I could get a lower periapsis this way) but didn't really expect that to happen.

So I am curious as to why it is happening, and whether bending the orbit towards the mun in the first place is what facilitated it, or if it was just coincidental that it occurred.

Edited July 5, 2013 by Fel

[leax256]

what is happening is simply the mün is close enough to you it changes your orbit. the left part of the "heart is your initial orbit path, the orange after is your orbit path relative to Kerban while in mün SOI. the complete orbit path to the right is your orbit around kerban after the mün edits your path. this is completly normal and simply means you need to change velosity in order to get a stable orbit.

[Karriz]

If you approach Moon from the other "side", it'll slingshot you out of Kerbin's SOI.

[AceMgy]

Well, I typically put all my manned missions in a circumlunar free return just in case something happens in route and they're aren't able to make any big burns. That looks like what you're getting there, although you're encountering the Mun on your return leg. This is more costly both time / delta-v wise, so it'd be best to adjust your burn time to slightly earlier to compensate, you wouldn't need such a high apoapsis to encounter it.

It looks like you're coming in from behind the Mun to encounter it, with your Munar periapsis pointed towards Kerbin, then continuing on your free trajectory. Since you're behind the Mun it pulls you forward, flings you out higher, then you fall back to Kerbin. I'm assuming your periapsis around the Mun is pretty high, if it were low you'd be flung way out of Kerbin's SoI which is not what you want. I wouldn't try to lower the periapsis of this orbit for that reason. A better way would be to plan a maneuver like this:

You come in ahead of the Mun instead of behind it (meaning you burn before the target indicator hits your prograde marker), and it pulls you into a slower orbit back to Kerbin. Here I have the periapsis at 15 km on the opposite side of the Mun from Kerbin, and it only costs 867 delta-v, much less than what you burned for your trajectory, and only a little more than the 850 delta-v you need to just hit the Mun.

Do you know how to use the maneuver nodes? You're gonna want to use them if you want to do free returns with any accuracy.

Edited July 4, 2013 by AceMgy

[Fel]

You're being a bit presumptuous here, the periapsis wasn't high at all (~150km), nor was it an expensive burn.

It is a near 100% "accuracy" because "for current data set" (the past 4 launches I did for base project), it always worked. No maneuver nodes, just firing as the mun passes the horizon. I'm mostly wondering why it even works, or if it works outside the kerbin body.

*And yes, different ships; last one (yesterday) was an 14Mg absurdity that barely made it far enough out for sub-orbit. (70Km, -70Km), and it still flung with a fairly low mun perapsis and low kerbal perapsis....

Edited July 4, 2013 by Fel

[AceMgy]

Yeah I was assuming, as there was no way for me to see the how much it cost for the burn or how high the periapsis was from that image. I think I might be wrong about it pulling you into a faster / slower orbit, that only really works if the periapsis is in front of or behind the Mun (prograde or retrograde the Mun's orbit). If the periapsis is on the Kerbin side or dark side of the Mun (Radial + or -) then it would mostly just change the argument of periapsis instead of adding/subtracting energy to the orbit. That's why the return path has approximately the same eccentricity and semi-major axis but just appears rotated around Kerbin relative to the incoming orbit. I'm by no means an expert and trying to remember this from my astrophysics course, somebody more knowledgeable correct me if I'm wrong, please. If that's the case then you should be able to get the periapsis as low as you want.

I see what you're doing now, trying to reach the Mun without maneuver nodes. In orbiter I used to always just burn prograde with the delta glider when the Moon crossed the horizon, just like you're doing. It got me there every time, as the Moon's SoI is large enough to allow for some inaccuracy. So I can tell you it works with the Earth/Moon system too if your thrust to weight ratio is pretty good (the delta glider had stupidly good TWR). My guess is that this "burn when it crosses the horizon" strategy wouldn't work in general for other systems. This is because the phase angle you would get from burning at the horizon would change depending on the planet's radius. For very large planets the phase angle doing this would approach 90 degrees, and for very small planets and/or very high orbits it'd approach 180 degrees. The phase angle to get to the Mun from a 90km parking orbit is about 110 degrees, so this strategy would give you something a little over 90 degrees. That sounds about right.

Edit: Just realized I had some errors in my trig when I drew out the situation. Trying to do the math to get you a definite answer if this horizon-burning strategy works everywhere.

Edited July 4, 2013 by AceMgy

[AceMgy]

Alright. I decided to do the math and see if burning when a moon rises over the horizon worked in general or just for Earth/Kerbin. I got this:

where r_1 is the radius of the spacecraft's orbit

r_2 is the radius of the moon's orbit

and R is the radius of the planet they orbit.

All assuming circular orbits and an instantaneous transfer burn.

If that equation is satisfied, then burning exactly when the moon rises over the horizon will get you into a perfect Hohmann transfer to that moon. If my math is correct, then this certainly isn't true for any arbitrary planet / moon system. Do with that what you will.

[Dkmdlb]

A better way would be to plan a maneuver like this:

IMG

That is an absolutely gorgeous trajectory. I'm going to have to start doing this. Just beautiful.

[Fel]

Alright. I decided to do the math and see if burning when a moon rises over the horizon worked in general or just for Earth/Kerbin. I got this:

where r_1 is the radius of the spacecraft's orbit

r_2 is the radius of the moon's orbit

and R is the radius of the planet they orbit.

All assuming circular orbits and an instantaneous transfer burn.

If that equation is satisfied, then burning exactly when the moon rises over the horizon will get you into a perfect Hohmann transfer to that moon. If my math is correct, then this certainly isn't true for any arbitrary planet / moon system. Do with that what you will.

let x1 be r_1 / R

let x2 be r_2 / R

and first level gets you

1 - sqrt((x1^2 - 1)(x2^2 - 1))

----------------------------------

x1 * x2

Separating the roots and pushing the terms in gets

(x1 * x2) ^ -1 - sqrt((1 - 1 / x1^2) * sqrt((1 - 1 / x2^2))

Which can then, given r_2 >> R, be approximated as

(x1 * x2) ^ -1 - sqrt((1 - 1 / x2^2))

Assuming x1 << x2, and x1 ~= 1 (close orbit),

That can simplify the cosine expression down to

-COS(SQRT(1 + (3 / x2) + (3 / x2 ^ 2) + (1 / x2 ^ 2)) * (pi / sqrt(8)))

Which can then, given r_2 >> R, be aproximated as

-COS(SQRT(1 + (3 / x2)) * (pi / sqrt(8)))

so,

sqrt((1 - 1 / x2^2)) - (x1 * x2) ^ -1 = COS(SQRT(1 + (3 / x2)) * (pi / sqrt(8)))

Uhh, idk...

sqrt((1 - 1 / x2^2)) - (x1 * x2) ^ -1 = SIN((pi / 2) - SQRT(1 + (3 / x2)) * (pi / sqrt(8)))

Small(ish) angle approximation

sqrt((1 - 1 / x2^2)) - (x1 * x2) ^ -1 = pi / 2 - SQRT(1 + (3 / x2)) * (pi / sqrt(8))

sqrt((1 - 1 / x2^2)) - (x1 * x2) ^ -1 + SQRT(1 + (3 / x2)) * (pi / sqrt(8)) = pi / 2

(x1 * x2 * sqrt((1 - 1 / x2^2)) - 1 + x1 * x2 * SQRT(1 + (3 / x2)) * (pi / sqrt(8))) / (x1 * x2) = pi / 2

(x1 * x2 * sqrt((1 - 1 / x2^2)) - 1 + x1 * SQRT(x2^2 * (1 + (3 / x2))) * (pi / sqrt(8))) / (x1 * x2) = pi / 2

(x1 * x2 * sqrt((1 - 1 / x2^2)) - 1 + x1 * SQRT(x2^2 + 3 * x2)) * (pi / sqrt(8))) / (x1 * x2) = pi / 2

From last time, we excluded a + 3 / X2^2 ,

(x1 * x2 * sqrt((1 - 1 / x2^2)) - 1 + x1 * SQRT(x2^2 + 3 * x2 + 2.25)) * (pi / sqrt(8))) / (x1 * x2) = pi / 2

(x1 * x2 * sqrt((1 - 1 / x2^2)) - 1 + x1 * SQRT((x2 + 1.5)^2)) * (pi / sqrt(8))) / (x1 * x2) = pi / 2

(x1 * x2 * sqrt((1 - 1 / x2^2)) - 1 + x1 * (x2 + 1.5) * (pi / sqrt(8))) / (x1 * x2) = pi / 2

sqrt(1 - x1^-2) + sqrt(9 / 32) * pi / x2 - 1 / (x1 * x2) = (2 - sqrt(2)) * pi / 4

And then... uhh... inaccuracy spikes while solving for x2.

*Random calcs show that it'll generally be "near" despite the distance; just wanted to prove that ;p

Edited July 5, 2013 by Fel

[KerbMav]

Is there a perfect constellation of variables - Kerbin escape burn angle relative to position Mun, speed, path around the Mun ... - to leave Kerbin and enter an orbit around Mun without retrograde burns?

Is this only possible for target bodies with an atmosphere to aerobreak in?

[Majorjim!]

let x1 be r_1 / R

let x2 be r_2 / R

and first level gets you

1 - sqrt((x1^2 - 1)(x2^2 - 1))

----------------------------------

x1 * x2

Separating the roots and pushing the terms in gets

(x1 * x2) ^ -1 - sqrt((1 - 1 / x1^2) * sqrt((1 - 1 / x2^2))

Which can then, given r_2 >> R, be approximated as

(x1 * x2) ^ -1 - sqrt((1 - 1 / x2^2))

Assuming x1 << x2, and x1 ~= 1 (close orbit),

That can simplify the cosine expression down to

-COS(SQRT(1 + (3 / x2) + (3 / x2 ^ 2) + (1 / x2 ^ 2)) * (pi / sqrt(8)))

Which can then, given r_2 >> R, be aproximated as

-COS(SQRT(1 + (3 / x2)) * (pi / sqrt(8)))

so,

sqrt((1 - 1 / x2^2)) - (x1 * x2) ^ -1 = COS(SQRT(1 + (3 / x2)) * (pi / sqrt(8)))

Uhh, idk...

sqrt((1 - 1 / x2^2)) - (x1 * x2) ^ -1 = SIN((pi / 2) - SQRT(1 + (3 / x2)) * (pi / sqrt(8)))

Small(ish) angle approximation

sqrt((1 - 1 / x2^2)) - (x1 * x2) ^ -1 = pi / 2 - SQRT(1 + (3 / x2)) * (pi / sqrt(8))

sqrt((1 - 1 / x2^2)) - (x1 * x2) ^ -1 + SQRT(1 + (3 / x2)) * (pi / sqrt(8)) = pi / 2

(x1 * x2 * sqrt((1 - 1 / x2^2)) - 1 + x1 * x2 * SQRT(1 + (3 / x2)) * (pi / sqrt(8))) / (x1 * x2) = pi / 2

(x1 * x2 * sqrt((1 - 1 / x2^2)) - 1 + x1 * SQRT(x2^2 * (1 + (3 / x2))) * (pi / sqrt(8))) / (x1 * x2) = pi / 2

(x1 * x2 * sqrt((1 - 1 / x2^2)) - 1 + x1 * SQRT(x2^2 + 3 * x2)) * (pi / sqrt(8))) / (x1 * x2) = pi / 2

From last time, we excluded a + 3 / X2^2 ,

(x1 * x2 * sqrt((1 - 1 / x2^2)) - 1 + x1 * SQRT(x2^2 + 3 * x2 + 2.25)) * (pi / sqrt(8))) / (x1 * x2) = pi / 2

(x1 * x2 * sqrt((1 - 1 / x2^2)) - 1 + x1 * SQRT((x2 + 1.5)^2)) * (pi / sqrt(8))) / (x1 * x2) = pi / 2

(x1 * x2 * sqrt((1 - 1 / x2^2)) - 1 + x1 * (x2 + 1.5) * (pi / sqrt(8))) / (x1 * x2) = pi / 2

sqrt(1 - x1^-2) + sqrt(9 / 32) * pi / x2 - 1 / (x1 * x2) = (2 - sqrt(2)) * pi / 4

And then... uhh... inaccuracy spikes while solving for x2.

*Random calcs show that it'll generally be "near" despite the distance; just wanted to prove that ;p

Wait.. What?