How are gravity assists conceived?

Question

So there are some very complex gravity assists out there. The Cassini mission, for instance, used a VVEJ (Venus Venus Earth Jupiter) gravity assist to make it to Saturn. Similar flybys have been done for other missions. While I understand how to make a simple Hohmann transfer orbit very well, I don't quite see how to even set up a relatively simple gravity assist. I would like to write a program that helps me to set this up, but I'm struggling even to understand the principle I should be aiming for.

Bonus question: Even more complex to me is ion drive missions such as Rosetta, which have ion drives AND use gravity assists. This seems even more complex to me, and I would like to better understand this.

Answer 1

First off, you need to know where all the bodies in the solar system are as a function of time. I would start by getting the SPICE toolkit from JPL, supported in C, Fortran, IDL, and MATLAB. You will also need the planetary and lunar ephemerides and the latest leap-second kernel. (The planetary kernel linked is good from 1550 AD to 2650 AD, and the leap second kernel linked includes the leap second added a few weeks ago. The planetary kernel includes the Sun, Pluto, and Earth's moon. There is more recent kernel with an updated orbit for Pluto, but the available one only spans 1950 to 2050.)

Second, you need to be able to do patched conic trajectories for rapid evaluation of gravity assist trajectories. You simply assume that there is only the Sun when traversing between planets to get, say, the arrival $\vec{V}_{\infty}$ at the planet (subtracting the heliocentric velocity vector from the planet velocity vector), and then assume that there is only the planet to use a simple equation to convert that to a departure $\vec{V}_{\infty}$ leaving the planet, adding the heliocentric velocity of the planet back in to propagate from there. As part of this, you will be converting between orbital elements and position/velocity, and back for every flyby and every propulsive maneuver.

Then play. Look at where the planets are and try things. Keep looking at where they are as time progresses.

Try going backwards -- Venus is especially effective due to its high mass and depth in the Sun's gravity well (Oberth effect), even though you have to go the "wrong way" when you are trying to get to the outer solar system. (This was an "a ha!" moment for Roger Diehl of JPL who discovered this approach in trying to figure out how to get Galileo to Jupiter without a Shuttle-Centaur after Challenger blew up. Venus was then used twice by Cassini.) You may want to add propulsive maneuvers to get you back to planets. Cassini had to do a large deep-space maneuver to lower its perihelion so it could get back to Venus a second time. It is interesting that both of Cassini's big propulsive maneuvers on the way to Saturn (launch and the DSM) reduced its heliocentric energy, even though the objective was to significantly increase its heliocentric energy in order to reach Saturn.

Important note: after developing a trajectory, verify that the flybys are above the surface and atmosphere of the bodies.

This will be good enough to discover trajectories. Try rediscovering the Grand Tour of the late 1970's as a first exercise.

If you need to really fly one of these trajectories, then you need to:

Third, be able to accurately numerically integrate trajectories in the gravity fields of the Sun and all of the planets, and integrate the approach/flyby/departure accurately instead of using the patched conic approximation. Then you can verify that you really have what you thought you had, and know with some confidence the $C_3$, the $\Delta V$'s, and the times required.

Answer 2

Background

How can I intuitively understand gravity assists?

From the frame of reference of the planet you're gaining the assist from you leave the sphere of influence (SOI) of the planet at the same speed as you entered it, just in a different direction (from an external frame of reference you've changed both speed and direction). In a simple case (no thrusting during the assist) this limits the planning parameters to your vector relative to the planet when entering the SOI: knowing your input vector allows you to compute the exit vector and slightly changing the angle you enter produces larger changes to the resulting angle when leaving the SOI.

Aim closer to the planet for a lower pass for a greater change in direction (and velocity from an external frame of reference), farther from the planet for a smaller change; aim ahead of the planet for a slower resulting external velocity, behind for a higher velocity: (image from this KSP tutorial)

Also note that to gain velocity from a gravity assist you have to change direction.

Planning Methods

If you're willing to freehand the assists (say you're playing KSP and are trying to get somewhere on the cheap) you can simply line up an encounter with a planet and tweak the parameters of the pass until you have an encounter with another planet lined up, then repeat until you get where you want to go. That requires a good interactive simulator and may or may not result in an acceptable mission duration, delta-v budget, etc, but it should get you there eventually.

If you want a more optimal solution you can teach a computer to do the above and have it just try all reasonable paths you have delta-v budget for in your target time frame. Actually, it seems that implementing a brute force algorithm for optimizing gravity assisted trajectories is a good start on a master's thesis at California Polytechnic State University. To quote the paper:

In order to plan out multiple gravity assisted trajectories, complex and robust computer simulations are required to filter through the continuum of possibilities and select trajectories that optimally satisfy the mission requirements. This paper discusses one such computer simulation which seeks to minimize the propulsive delta v requirements of a spacecraft for a trajectory between two specified planets utilizing a specified number of planetary flybys along the way.

And farther down:

The approach outlined in this report is referred to as a patched Lamberts problem and utilizes a brute force tactic. The underlying principle of this strategy involves breaking down a trajectory into separate segments or legs and analyzing each leg one at time with respect to the leg prior to it. Each leg is defined as an orbital trajectory between planet A and planet B, where planets A and B can be either the same planet or different ones.

From skimming the paper it sounds like you start with a range of launch times (determines what planets are in alignment for providing useful assists), then simulate the range of possible planetary encounters to determine how much energy you can gain/lose at each, then from the time of encounter figure out what time frame you'd be leaving the planet and repeat until you've found an encounter with your target planet. That actually sounds very much like automating my original suggestion of just playing with it manually in a simulator until it gets you there.

---

In terms of existing planning tools KSP Trajectory Optimization Tool claims to support gravity assists and you can change the planets by modifying a config file so in theory you can configure it for the real solar system values. I didn't try it (doesn't advertise linux support or I'd have been very tempted) but the KSP community is the only group I know of that does this type of mission planning for fun and provides tools and documentation online so I don't know where else you'd find a decent tool.