Gravity assists: do you use them?

[Duban]

If you're going fast enough, then Kerbin's gravity wasn't going to have much effect on your speed during the time you are in Mun's SoI (reflected by the small change in direction of Mun's velocity). I understand about using the Mun's orbital velocity to your advantage, I just don't see how patched conics saves you from Kerbin's gravity to any significant degree.

There's never any reason to get a gravitational assist off the Mun. The oberth effect by burning in Kerbin's much larger gravity well is better than a weak slingshot manuever off the mun for reaching every body in the game. Gravitational assists off the Mun are a waste of time/fuel.

Let me give a breakdown of the planets and why gravitational assists are/aren't useful on each.

Moho- Performing a gravitational assist off Eve is the way to go with landing on Moho. The unpowered section of the gravitational slingshot will help match Moho's high inclination while Eve's immense gravity well will improve your rocket's efficiency (oberth effect) when reaching the inner solar system. This is by far the most useful and necessary slingshot in KSP.

Eve/Gilly- Nothing to slingshot off of to reach. Eve is a useful body for reaching Moho though.

Mun/Minmus- Again Kerbin's gravity is more useful for getting to other planets the Mun is. Gravitational slingshots off Mun/Minmus are a waste.

Duna/Ike- Duna and Ike are too small and have orbits too similar to Kerbin's to be useful for gravitational slingshots. Kerbin's gravity is more useful than a Duna/Ike system slingshot.

Dres- Is in a useful position for slingshots, but is too small to be worth bounching off of.

Jool- Is more likely to hurl you out of the Kerbol system than send you anywhere useful. Its gravity might (in theory) be useful for matching Eeloo by performing a powered gravitational slingshot using its immense gravity (oberth effect). I haven't tried though.

Laythe- Has a nice atmosphere for aerobraking off of which can be useful for matching a few other planets.

Vall- Reaching Vall directly from Kerbin results in your ship blasting toward the planet at high velocity. Vall lacks Laythe's atmosphere for performing an aerbrake into, and doesn't have Tylo's immense gravity to cancel out your momentum from falling into Jool. Consider performing an aerobrake maneuver off Laythe, or a gravitational slingshot off Tylo to match Vall's orbit better before landing.

Tylo- Tylo's gravity cancels out nearly all of your velocity on approach. You're best just going straight from Kerbin to Tylo here.

Bop & Pol- Laythe/Tylo can be useful for getting into a closer orbit and losing all the velocity you have on approach to Jool.

Eeloo- Nothings to really slingshot off of to reach and nowhere to go after sling-shotting off Eeloo.

[Red Iron Crown]

The oberth effect by burning in Kerbin's much larger gravity well is better than a weak slingshot manuever off the mun for reaching every body in the game.

You can do both. Burn at low Kerbin periapsis, catch a slingshot from the Mun on the way out.

You left Kerbin off your list, it's a great slingshotter. Hit it repeatedly and you can get just about anywhere for very little dV expended.

[_Augustus_]

I can't gravity assist right.

[Aragosnat]

The only gravity assist I can regularly get is.... Going down hill with rovers and up hills when all the wheels have been blown. Sadly it only saves me time as I only drive during the day time so the solar panels always keep the rover charged up.

[Kinglet]

My missions are usually too short for gravity assist opportunities.

[Yakky]

I treat gravity assists more as accomplishments in their own right. A seriously beneficial gravity assist is a fun and elegant mission objective to try to accomplish, just like landing on Tylo or returning from Eve. You do them "because they are there" (to paraphrase George Mallory), not because they're the most practical way to accomplish some other mission goal.

If you're not into doing gravity assists for their own sake, they are probably not worth the time and tedium to figure out in KSP unless you are trying to set some kind of minimum delta-V record.

[Superfluous J]

If you're going fast enough, then Kerbin's gravity wasn't going to have much effect on your speed during the time you are in Mun's SoI (reflected by the small change in direction of Mun's velocity). I understand about using the Mun's orbital velocity to your advantage, I just don't see how patched conics saves you from Kerbin's gravity to any significant degree.

Ah. I see the disconnect.

I never said it was SIGNIFICANT. I said it was present. And the original person you quoted said 40 m/s which - when it comes to interplanetary maneuvers - fits both of those: It's not very significant but it is present.

[Red Iron Crown]

Ah. I see the disconnect.

I never said it was SIGNIFICANT. I said it was present. And the original person you quoted said 40 m/s which - when it comes to interplanetary maneuvers - fits both of those: It's not very significant but it is present.

Honestly, I wouldn't expect the difference to be measurable, but that's an intuitive impression that I don't have the math to back up (and I certainly could be wrong, Kraken knows my intuition has been wrong about much involving orbital mechanics). That's why I asked numerobis to expand upon it.

[martin.stejskal]

could somebody who understand how to use the gravity assist post an article with some schemas to the kerbal wiki how to use it in proper way. Thx.

[Red Iron Crown]

could somebody who understand how to use the gravity assist post an article with some schemas to the kerbal wiki how to use it in proper way. Thx.

There's a good simple pictorial explanation here on the forum, as well as a much more in-depth explanation.

[PLAD]

I did some experiments and I think KSP does alright. I set up flights that went straight out from Kerbin at about 1000m/s at Mun's altitude and measured the outward speed at about 9200km, 11200km and 13500km 3 times- passing in front of Mun, behind Mun, and with Mun nowhere near. I had to use different altitudes to make the flyby periapsis and Mun-SOI-durations roughly the same. Summary- if you pass behind Mun (but through it's SOI) it does indeed reduce your outward speed loss, by 24m/s in my test (1900km perimun, 34 minutes in Mun's SOI). But if you pass in front of Mun it increases your outward speed loss by roughly the same. This happens even though Mun only changed the velocity vector by about 2 degrees. It all fits the math. But now I still don't know why my Mun flybys are so error-prone.

[Superfluous J]

Honestly, I wouldn't expect the difference to be measurable, but that's an intuitive impression that I don't have the math to back up (and I certainly could be wrong, Kraken knows my intuition has been wrong about much involving orbital mechanics). That's why I asked numerobis to expand upon it.

It would be an easy test. Make a maneuver node that would get you to - say - Jool but make sure it passes through Mun's sphere of influence. F5 to quicksave. Do the burn (Use mechjeb if you want perfect(ish) reproducibility) and go out to just after you exit Mun's SOI. Note the altitude and speed.

Then F9 to restore and push the maneuver node an orbit or two forward in time. Do the burn again, timewarp up to the same altitude, and see what your speed is.

Also, by getting Mun out of the way you may just be able to see the difference in the planned maneuver node itself. 40 m/s isn't super significant (as I said) but it may be enough to make the difference between reaching Jool and falling short.

[PLAD]

Here's the experiment I did.

Javascript is disabled. View full album

I think KSP is doing everything just the way it should, given that it uses patched conics. (And I think it's great that it uses patched conics, because it makes it run much faster with not much loss of accuracy!)

[Red Iron Crown]

It would be an easy test. Make a maneuver node that would get you to - say - Jool but make sure it passes through Mun's sphere of influence. F5 to quicksave. Do the burn (Use mechjeb if you want perfect(ish) reproducibility) and go out to just after you exit Mun's SOI. Note the altitude and speed.

Then F9 to restore and push the maneuver node an orbit or two forward in time. Do the burn again, timewarp up to the same altitude, and see what your speed is.

Also, by getting Mun out of the way you may just be able to see the difference in the planned maneuver node itself. 40 m/s isn't super significant (as I said) but it may be enough to make the difference between reaching Jool and falling short.

That experiment won't show the effect numerobis describes alone, it will show the effect of the gravity assist as well. Numerobis said that gravity assists are improved in patched conics due to reduced effect of Kerbin's gravity when in the Mun's SoI, which is the part I'm struggling with. Kerbin's gravity still affects everything in the Mun's SoI; patched conics just approximates the gravity by making it exactly equal to Kerbin's effect on the Mun itself. Have a look at the following diagram (forgive my crude image editing skills):

The SoI itself is following the Mun's orbital path, anything exiting it has the Mun's orbital velocity added. In the time that it takes to cross the SoI, the direction of that velocity changes due to Kerbin's gravity, so it's not really correct to say that things in Mun's SoI are not affected by Kerbin's gravity. What does change compared to not entering Mun's SoI is the magnitude of the effect of Kerbin's gravity; while in the red area a ship is affected less than it otherwise would be and while in the blue area it is affected more than it would have been. Thus, a trajectory that spends more time in the red area experiences less effect of Kerbin's gravity while a trajectory that is mostly in the blue area is affected more by Kerbin's gravity.

This is a separate effect from the gravity assist itself, which is caused by the curve imparted on the trajectory by the Mun's gravity. I'm not sure how to do an experiment that isolates the effect, the trajectory would have to pass straight through the SoI without curving, which is only possible if it passes through the center of the Mun.

[cantab]

Think you've hit the nail on the head there. I'll add that a trajectory from LKO, past the Mun, and onto interplanetary space will spend about equal times in the red and blue regions, since it's got to go from inside to outside the Mun's orbit. On the other hand an interplanetary gravity assist might well spend much longer in one region than the other.

Regardless, the effect should be small - that's the whole point of the conic patch approximation.

[numerobis]

PLAD, the effect I'm talking about is implicit in the conic patch approximation, so if you're calculating things in a conic patch model, your calculations should be exact.

Red Iron Crown: I think you're overthinking this. Consider a spacecraft anywhere in the SOI of a body. In patched conics, the forces on that spacecraft are gravity towards the body -- and that's it. IRL, there's gravity towards that body, PLUS there's gravity towards every other body in the system. So it's relatively simple arithmetic to figure out how much additional gravity you're skipping out on compared to what reality-based rocket scientists have to contend with. The net effect is that KSP gravity assists can be more helpful than IRL gravity assists in terms of delta-V.

cantab: yes, the effect is pretty small, but it's always fun to see ways in which KSP violates conservation laws.

[Red Iron Crown]

Red Iron Crown: I think you're overthinking this. Consider a spacecraft anywhere in the SOI of a body. In patched conics, the forces on that spacecraft are gravity towards the body -- and that's it. IRL, there's gravity towards that body, PLUS there's gravity towards every other body in the system. So it's relatively simple arithmetic to figure out how much additional gravity you're skipping out on compared to what reality-based rocket scientists have to contend with. The net effect is that KSP gravity assists can be more helpful than IRL gravity assists in terms of delta-V.

The gravity of the grandparent body is still affecting the spacecraft, it's just that the effect is not visible until exiting the SoI. The velocity vector subtracted from the craft when entering an SoI is different from the vector added back on when it leaves the SoI. The direction is different though the magnitude is the same. The reason for that difference in direction is the parent body's gravity, though the patched conics simplify this by applying the same gravity vector everywhere in the SoI. You are definitely right that uncle and cousin bodies have no effect, whereas they would in real life.

[numerobis]

The gravity of the grandparent body is still affecting the spacecraft, it's just that the effect is not visible until exiting the SoI. The velocity vector subtracted from the craft when entering an SoI is different from the vector added back on when it leaves the SoI. The direction is different though the magnitude is the same. The reason for that difference in direction is the parent body's gravity, though the patched conics simplify this by applying the same gravity vector everywhere in the SoI. You are definitely right that uncle and cousin bodies have no effect, whereas they would in real life.

Hmm... We clearly are in disagreement about how conic patches work.

My model is that each body gets a sphere of influence. Within that sphere (unless the craft is in a child sphere), we completely ignore all other bodies. This means we're solving a 2-body problem and the solution is a conic section. To compute where the spacecraft is compared to the parent of its SoI (e.g. Kerbin), we just add two conics: that of the spacecraft around its body (e.g. Mun), and that of the body around its parent (e.g. Mun around Kerbin). When a spacecraft changes SoI, we know its speed and position relative to the new SoI body, so we can compute a new conic patch, repeat until you get bored (in KSP, that defaults to 3 patches).

What's your model? You mentioned a constant gravitational field to represent the parent body, and you mention acceleration at SoI boundaries, both of which seem to be contrary to my model.

[PLAD]

Doh, Cantab you're right, I'm just checking that KSP does the patched conic approximation correctly. If I check it's performance against what would really happen I will find it off. Here's my favorite example of that, from my low-dV-to-Mun mission. I've just entered Mun's SOI and done no braking yet:

I usually like my hyperbolas a little less.. closed...

If Mun's influence had been working on the ship from infinity (or at least from Kerbin) I would have had to use about 245m/s to brake into that planned circular orbit instead of 209. So I'm not complaining. But yah, KSP's paths will differ from real-universe theoretical performance by dozens of meters per second and by flying right you can use this to your advantage.

Edited November 17, 2014 by PLAD

[Red Iron Crown]

Hmm... We clearly are in disagreement about how conic patches work.

My model is that each body gets a sphere of influence. Within that sphere (unless the craft is in a child sphere), we completely ignore all other bodies. This means we're solving a 2-body problem and the solution is a conic section. To compute where the spacecraft is compared to the parent of its SoI (e.g. Kerbin), we just add two conics: that of the spacecraft around its body (e.g. Mun), and that of the body around its parent (e.g. Mun around Kerbin). When a spacecraft changes SoI, we know its speed and position relative to the new SoI body, so we can compute a new conic patch, repeat until you get bored (in KSP, that defaults to 3 patches).

What's your model? You mentioned a constant gravitational field to represent the parent body, and you mention acceleration at SoI boundaries, both of which seem to be contrary to my model.

To my mind, the patched conic approximation is this: Within a sphere of influence, the gravitational influence of all external bodies is equal in both magnitude and direction at all points within that sphere.

This is a useful approximation because, as you say, it allows all other bodies to be ignored for maneuvers within that SoI and use simple conic sections for trajectories in a frame of reference centered on the SoI. When viewed from Kerbin's frame, though, everything in the Mun's SoI is experiencing the same acceleration from the Kerbin's gravity.

When viewed from a Kerbin-centered frame of reference, there is a change in acceleration from gravity when changing SoIs, an instantaneous "jerk". This happens for two reasons. The first is that the Mun's gravity is added when entering its SoI or subtracted when leaving it. The second is that the acceleration from Kerbin's gravity changes; inside Mun's SoI this is calculated using the center of the Mun's position, outside Mun's SoI it is calculated from the ship's actual position.

Edit to add a diagram:

Yellow lines are the direction of Kerbin's gravity on objects in Mun's SoI, green lines are the direction of Kerbin's gravity on objects outside of it.

*All of the above is "to my understanding". I'm not a physicist or rocket scientist and may be totally wrong. Consult with a qualified rocket scientist before attempting any space travel.

Edited November 17, 2014 by Red Iron Crown

[Superfluous J]

This happens for two reasons. The first is that the Mun's gravity is added when entering its SoI or subtracted when leaving it. The second is that the acceleration from Kerbin's gravity changes; inside Mun's SoI this is calculated using the center of the Mun's position, outside Mun's SoI it is calculated from the ship's actual position.

(Bold is mine for emphasis)

I've programmed N-body simulators (simple ones, but many versions including on a graphing calculator back in the early 90s) and I can guarantee this is wrong. If your ship orbiting Mun received ANY pull from Kerbin it would never, ever be in a stable, perfectly elliptical orbit around Mun. It would be pulled into - at best - a Spirograph-like orbit and - at worst - it would get slowly tugged until it either was pulled from Mun's SOI or crashed into Mun.

The fact that your orbit around Mun is a stable ellipse means that Kerbin (and Sun) don't affect it. It's a 2-body solution.

Edited November 17, 2014 by 5thHorseman

[Red Iron Crown]

(Bold is mine for emphasis)

I've programmed N-body simulators (simple ones, but many versions including on a graphing calculator back in the early 90s) and I can guarantee this is wrong. If your ship orbiting Mun received ANY pull from Kerbin it would never, ever be in a stable, perfectly elliptical orbit around Mun. It would be pulled into - at best - a Spirograph-like orbit and - at worst - it would get slowly tugged until it either was pulled from Mun's SOI or crashed into Mun.

The fact that your orbit around Mun is a stable ellipse means that Kerbin (and Sun) don't affect it. It's a 2-body solution.

The first line of the paragraph you quoted was "When viewed from a Kerbin-centered frame of reference". Everything within Mun's SoI (including the Mun itself) is experiencing the same acceleration from Kerbin's gravity, so within a Mun-centered frame of reference it can be ignored and trajectories are simple conics.

Edit to add: In an n-body simulation there would not be a sudden discontinuous change in gravitational acceleration because there is no defined line where one body's influence is ignored or simplified, it is instead a smooth continuous change as the ship moves.

Edited November 17, 2014 by Red Iron Crown

[cantab]

My model is that each body gets a sphere of influence. Within that sphere (unless the craft is in a child sphere), we completely ignore all other bodies. This means we're solving a 2-body problem and the solution is a conic section. To compute where the spacecraft is compared to the parent of its SoI (e.g. Kerbin), we just add two conics: that of the spacecraft around its body (e.g. Mun), and that of the body around its parent (e.g. Mun around Kerbin). When a spacecraft changes SoI, we know its speed and position relative to the new SoI body, so we can compute a new conic patch, repeat until you get bored (in KSP, that defaults to 3 patches).

To expand, while the gravity of bodies other than the primary isn't directly calculated, it's implicitly taken into account by the movement of the SOI and everything in it.

And indeed, while KSP puts the celestials on simple Keplerian orbits, I see no reason patched conics couldn't be used with a more sophisticated orbital model such as VSOP87, meaning things like Venus's perturbation of Earth's orbit would be taken into account.

I usually like my hyperbolas a little less.. closed...

If Mun's influence had been working on the ship from infinity (or at least from Kerbin) I would have had to use about 245m/s to brake into that planned circular orbit instead of 209. So I'm not complaining. But yah, KSP's paths will differ from real-universe theoretical performance by dozens of meters per second and by flying right you can use this to your advantage.

I wonder if there isn't some truth in the KSP approximation here though. In real life a wide enough orbit round a primary, one that extends well beyond the primary's Hill Sphere, will not be stable and may well result in a single flyby at slightly less than escape speed.

[numerobis]

To my mind, the patched conic approximation is this: Within a sphere of influence, the gravitational influence of all external bodies is equal in both magnitude and direction at all points within that sphere.

This is a useful approximation because, as you say, it allows all other bodies to be ignored for maneuvers within that SoI and use simple conic sections for trajectories in a frame of reference centered on the SoI. When viewed from Kerbin's frame, though, everything in the Mun's SoI is experiencing the same acceleration from the Kerbin's gravity.

When viewed from a Kerbin-centered frame of reference, there is a change in acceleration from gravity when changing SoIs, an instantaneous "jerk". This happens for two reasons. The first is that the Mun's gravity is added when entering its SoI or subtracted when leaving it. The second is that the acceleration from Kerbin's gravity changes; inside Mun's SoI this is calculated using the center of the Mun's position, outside Mun's SoI it is calculated from the ship's actual position.

Edit to add a diagram:

https://dl.dropboxusercontent.com/u/61004449/ksp/misc/MunSoI2.png

Yellow lines are the direction of Kerbin's gravity on objects in Mun's SoI, green lines are the direction of Kerbin's gravity on objects outside of it.

*All of the above is "to my understanding". I'm not a physicist or rocket scientist and may be totally wrong. Consult with a qualified rocket scientist before attempting any space travel.

I'm fairly certain what you are describing is not what most people call patched conics, and that it's not what is implemented in KSP. The main reason I don't think this is patched conics is that the trajectories wouldn't be conics. I also suspect it doesn't lend itself to a nice solution, or we'd be using this system instead of patched conics -- it clearly provides a more accurate solution than simply ignoring the parent SoI.

At base in patched conics, there's no acceleration when you change SoI. You do change the reference point, so there might be approximation error when you switch, which as far as I know is all that's going on for KSP.

[Red Iron Crown]

I'm fairly certain what you are describing is not what most people call patched conics, and that it's not what is implemented in KSP. The main reason I don't think this is patched conics is that the trajectories wouldn't be conics. I also suspect it doesn't lend itself to a nice solution, or we'd be using this system instead of patched conics -- it clearly provides a more accurate solution than simply ignoring the parent SoI.

What I'm describing is what allows the gravity of the parent to be ignored within the SoI and the use of simple conics. The gravity of the parent is simplified to being constant everywhere in the SoI, accelerating the SoI and everything in it equally.

At base in patched conics, there's no acceleration when you change SoI. You do change the reference point, so there might be approximation error when you switch, which as far as I know is all that's going on for KSP.

Gravity is always accelerating a vessel in orbit that isn't thrusting (and usually vessels that are thrusting). That acceleration changes discontinuously at the SoI border, for the reasons I mentioned.