Equations for Gravity Assists?

[Space Mailman]

Hello! I’ve been playing KSP for a while now and have become quite confident in my abilities. Although, I’m still having trouble with gravity assists. Is there an equation of some sort that I can use to calculate my speed after the slingshot/brake?

Ex. Before assist craft is going x m/s, after the assist the craft is going y m/s

I also would like to know if there is an equation I can use that will tell me the orbital velocity at a certain altitude above a body.

Ex. At h meters with d degrees of inclination, the craft must be going x m/s to maintain a circular orbit

If you have any other useful equations that would be nice, thanks!

Edited December 6, 2017 by Nolen

[GoSlash27]

Nolen,
 Quick & dirty. I present it graphically because that's generally how I think mathematically. Ignore the bit about Ventry>= at the end; it's an erroneous conclusion.

Best,
-Slashy

Edited December 6, 2017 by GoSlash27

[Starman4308]

One of the most important equations involved:

v_soi = v_soi

The velocity you have entering the SOI of the body you're using for the slingshot is the velocity you have coming out... just in a different direction.

The amount of velocity you gain or lose with respect to the parent body, thus, is a function of how fast the assisting body is orbiting and the angle between your entry and exit vectors. I don't know the math for this, unfortunately, other than a quick theoretical maximum for the case of a perfect U-turn to accelerate yourself, in which case your exit velocity is 2*v_body-v_orig.

When it comes to calculating orbital velocities, the most useful equation I've seen is the vis-viva equation: v² = u*((2/r) - (1/a)), where u is the parent body's standard gravitational parameter, r is your current radius above the center of the parent body*, and a is the semi-major axis.

*Do remember that while KSP reports apoapsis and periapsis above the surface, vis-viva works on apoapsis and periapsis relative to the center of the body,

[Cpt Kerbalkrunch]

1 hour ago, GoSlash27 said:

Nolen,
 Quick & dirty. I present it graphically because that's generally how I think mathematically. Ignore the bit about Ventry>= at the end; it's an erroneous conclusion.

Best,
-Slashy

Uh, does that say get low and go fast? Cuz that's what I do. 

[GoSlash27]

21 minutes ago, Cpt Kerbalkrunch said:

Uh, does that say get low and go fast? Cuz that's what I do. 

Well... The lower you get, the more it'll bend your trajectory. So long as you leave the SoI more prograde than you entered, you will add velocity.

Best,
-Slashy

[Cpt Kerbalkrunch]

17 minutes ago, GoSlash27 said:

Well... The lower you get, the more it'll bend your trajectory. So long as you leave the SoI more prograde than you entered, you will add velocity.

Best,
-Slashy

Sorry to crack wise. I just like to be humorous. Truthfully, since accidentally discovering the secret of the free-capture at Jool (then witnessing the awesome power of Jool in the Retro-Solar Rescue), this subject is of great interest to me. However, I understand it conceptually rather than mathematically. I think of it (and the entire game really) in low-tech terms; which helps me to make sense of it. Equations like those in your diagram make me shudder. Sounds like that's exactly what the OP is looking for (in which I will be of zero help, obviously), but I would just add that a huge breakthrough for me was raising my patched conics limit. Raising it from the default 3 was (literally) a game-changer for me. It allowed me to watch the effect an encounter with another body's gravity would have on my orbit. Playing around with maneuver nodes and being able to see the resultant path has taught me a lot. I highly recommend it as a gravity-assist teaching tool, so-to-speak.

[OhioBob]

There's a lot of math here, but you can also take a look at this... http://www.braeunig.us/space/interpl.htm#gravassist

 

[Zhetaan]

4 hours ago, Nolen said:

Is there an equation of some sort that I can use to calculate my speed after the slingshot/brake?

Ex. Before assist craft is going x m/s, after the assist the craft is going y m/s

@OhioBob is one of our resident experts on this one (just look at his signature), so treasure that link.

4 hours ago, Nolen said:

I also would like to know if there is an equation I can use that will tell me the orbital velocity at a certain altitude above a body.

Ex. At h meters with d degrees of inclination, the craft must be going x m/s to maintain a circular orbit

You want the vis-viva equation, which is as follows:

v² = μ ( (2/r) - (1/a) )

where:

v = orbital velocity
μ = the standard gravitational parameter of the primary (that's the mass times the universal gravitational constant, which for Kerbin is 3.5315984×10¹² m³/s²)
r = the distance between the orbiting object and the primary's centre of mass (in KSP, current altitude plus primary radius, whick for Kerbin is 600 km)
a = the semimajor axis of the orbit (in KSP, this is equal to the periapsis plus the apoapsis plus the planetary diameter (for Kerbin, 1200 km) all divided by 2)

If you want a circular orbit, then the orbital radius is both r and a, so the equation becomes

v² = μ / r

Inclination doesn't matter; the equation relates the gravity and any lateral velocity (I would say horizontal velocity, but the value of horizontal keeps changing when you're in orbit) independently from a 3-d reference frame, which means that the solution can be fully represented in 2-dimensional space.  In real life, inclination can matter quite a lot because planets don't distribute the mass evenly and that causes perturbations (see Molniya orbits for an explanation and solution to part of that problem).

Keep in mind that the orbital velocity at a given altitude for a circular orbit is going to be different from the orbital velocity for an elliptical or hyperbolic orbit; while the altitude of the craft at that point is the same, the orbital energy is different, and that is reflected in the interplay between potential and kinetic energy that occurs as the object moves between apoapsis and periapsis.  Specifying that the velocity is for a circular orbit at that altitude makes computation easier but it doesn't really help when you want to know about the elliptical and hyperbolic orbits that get you there in the first place.

[Space Mailman]

5 hours ago, Starman4308 said:

One of the most important equations involved:

v_soi = v_soi

The velocity you have entering the SOI of the body you're using for the slingshot is the velocity you have coming out... just in a different direction.

The amount of velocity you gain or lose with respect to the parent body, thus, is a function of how fast the assisting body is orbiting and the angle between your entry and exit vectors. I don't know the math for this, unfortunately, other than a quick theoretical maximum for the case of a perfect U-turn to accelerate yourself, in which case your exit velocity is 2*v_body-v_orig.

When it comes to calculating orbital velocities, the most useful equation I've seen is the vis-viva equation: v² = u*((2/r) - (1/a)), where u is the parent body's standard gravitational parameter, r is your current radius above the center of the parent body*, and a is the semi-major axis.

*Do remember that while KSP reports apoapsis and periapsis above the surface, vis-viva works on apoapsis and periapsis relative to the center of the body,

This was very helpful!

What is it that you mean by “KSP reports Apoapsis and Periapsis above the surface, vis-viva works on Apoapsis and Periapsis relative to the center of the body”? I’m assuming you mean that you mean that r in KSP would be the altitude above sea level while in reality r would be the distance from the body’s COM. Am I correct about this?

Thanks!

[Snark]

37 minutes ago, Nolen said:

What is it that you mean by “KSP reports Apoapsis and Periapsis above the surface, vis-viva works on Apoapsis and Periapsis relative to the center of the body”? I’m assuming you mean that you mean that r in KSP would be the altitude above sea level while in reality r would be the distance from the body’s COM. Am I correct about this?

Yes, exactly.  Basically any physics equation involving gravity that you ever see will always have all distances measured from the CoM.  Whereas KSP reports your Pe and Ap as your height above the surface.  For example, Kerbin has a radius of 600 km.  When KSP says "your Ap is 120 km", that means "120 km above the surface", so the actual radius you'd plug into any physics equation would need to be 720 km.

Physics equations only care about CoM.  They don't care about how high you are above the surface.

[regex]

59 minutes ago, Snark said:

Whereas KSP reports your Pe and Ap as your height above the surface.

Clarification: KSP reports your Pe and Ap as your height above "sea level" or some defined sphere on an airless body that can be considered "sea level" (IIRC, the lowest point on an airless body).

I wish it would report height above the surface, that'd make landing so much easier...

E: Although this makes it quite easy to "translate" KSP to physics COM. Just keep the radii handy.

Edited December 6, 2017 by regex

[OhioBob]

4 hours ago, regex said:

(IIRC, the lowest point on an airless body).

That's not necessarily the case unless the planet maker took special care to make sure it's the case.  It may be true for the stock bodies, though I don't know if anyone has ever verified that.  For non-stock planets, you can't assume the datum is located at the lowest point on the surface.  The elevation of the surface in relation to the datum depends on how the terrain is generated.  Placing the datum at the low point may require that the offset be manually adjusted.

[Zhetaan]

12 hours ago, OhioBob said:

It may be true for the stock bodies, though I don't know if anyone has ever verified that.

It is true for some stock bodies and not others.  The Minmus flats biomes are all the lowest point of Minmus's surface and all set at datum.  The Mun's lowest point is about 250 m below datum.  Moho's lowest point is--or was at one point--30 m above datum, and I don't know why.  I do know that all stock bodies with oceans have the datum set to the ocean surface, and the ocean is present everywhere that the terrain dips below datum, but that only accounts for three bodies.

Edited December 7, 2017 by Zhetaan

[OhioBob]

2 hours ago, Zhetaan said:

I do know that all stock bodies with oceans have the datum set to the ocean surface, and the ocean is present everywhere that the terrain dips below datum, but that only accounts for three bodies.

Oceans will always be at zero elevation because its the datum that defines the ocean surface.  (Though there are OceanHeight and OceanDepth parameters that I don't know what they do.  Perhaps if those are set to non-zero numbers it would change the elevation of the ocean surface.)  If the surface is generated entirely by a heightmap, and if the darkest color in the heightmap is pure black (0,0,0), then the lowest surface elevation will be zero.  If the darkest color in the heightmap is some shade of gray, then the lowest surface elevation will be >0.  If PQS mods are used to generate the surface, then the lowest point could be almost anything, positive or negative.  If the planet maker wants the low point to equal zero, then they have to find where the low point is, measure its elevation, and apply on offset to bring that point to zero.  I actually did that on an early version of GPP, but then one of the Kopernicus updates changed something that altered the elevations and messed it all up.