Github link

Multiple Gravity Assist Trajectory Planner for KSP

By Krafpy

Gravity assists are an efficient method to save fuel in interplanetary missions. Instead of making a direct transfer from the departure planet to the destination one, we can perform fly-by's of intermediate planets to let their gravitational pull deviate our inital trajectory, without the need to burn fuel.

This method is successfully used in real world missions, like the famous Cassini–Huygens mission.

Gravity assist maneuvers can be achieved manually in KSP (see Scott Manley's tutorial). However, unlike direct transfers, multiple gravity assist trajectories (MGA) are non trivial to calculate.

This tool allows planning MGA trajectories with the details of each maneuver needed, with consideration of orbits' inclinations and eccentricities. Check the How to use section below for instructions.
It does not guarantee fully feasible or reasonable trajectories. The reasons and details are explained in the Current issues section. For any questions or remarks, see the forum post.

Calculator

Flyby sequence configuration
Departure / Arrival parameters
km (above surface level)
km (above surface level)
days

Mouse drag: rotate - Double click: focus on body - Mouse wheel: zoom

Calculated trajectory

-- UT

-- UT

-- m/s

Maneuver details:

  • Date:-- MET
  • ΔV (m/s):
    prograde normal radial
    -- -- --

How to use

Use the calculator on the left hand side to configure the settings of the trajectory you are looking for. The trajectory determination is done through the two following steps:

  1. Determining the planetary sequence that the trajectory must follow.
  2. Calculating the optimal trajectory using that sequence.

The nomenclature and the configuration of the calculator is further described in the following paragraphs.

Planetary sequence

The flyby sequence is the sequence of bodies encountered during the mission's flight time. It starts with the departure body and ends with the destination body. All intermediate bodies of the sequence are used for gravity assist.
Sequences are represented using the first characters (at least two) of each body's name. For example, a mission going from Kerbin to Jool, with a first flyby of Eve followed by a flyby of Duna would be written: Ke-Ev-Du-Jo.

Interplanetary legs

Each planet-to-planet transfer is called a leg, and consists of 3 steps:

  1. An unpowered flight from the exit of the last encountered body's sphere of influence.
  2. A deep space maneuver (DSM) used to correct the path to aim at the next body in the sequence.
  3. An unpowered flight until entering the next body's sphere of influence.

Sequence generation

The first step of the trajectory planning consists of generating a planetary sequence. It will list a bunch of possible sequences considering a very simplified model of the solar system and swing-bys, without any phasing. Therefore there is no guarantee to have the most optimal sequence generated. But it tries to provide feasible sequences.

Alternatively, it is possible to set a custom sequence if no interesting sequences is proposed by the generator, or to define custom routes. The input text must be a valid sequence representation. The trajectory calculation step will choose the custom sequence first if it is defined.

For the sequence generator, the following settings must be defined:

  • The origin and destination body of the trajectory.
  • Max swing-bys: the maximum number of swing bys allowed. Setting this value to 0 will only provide direct transfer sequences (e.g. Ke-Du).
  • Max resonances: the maximum number of legs starting from and targeting the same body. For example the sequence Ke-Ev-Ev-Mo contains one resonance (Ev-Ev).
  • Max back legs: the maximum number of legs moving away from the destination body. More precisely: if the destination body's orbit has a larger radius than the origin body's orbit, then a leg going from a higher orbit to a lower orbit is considered a back leg. In the same way, if the destination body's orbit has a smaller radius than the origin body's orbit, then a leg going from a lower orbit to a higher one is considered a back leg.
    For example, in the sequence Ke-Ev-Ke-Mo, Ev-Ke is a back leg as it gets the spaceship on an orbit farther from Moho than the previous leg.
  • Max back spacing: the maximum gap between the exited and targeted body of a back leg. For example, setting this value to 0 would make the sequence Ke-Ev-Du-Mo forbidden, because Ev-Du is a back leg, and a planet with an orbit radius in between the ones of Eve and Duna exists (Kerbin), this back leg has a spacing of 1.

Trajectory calculation

Once the planetary sequence is selected, we must specify the departure and arrival conditions:

  • Earliest and latest departure date: the time range in which the departure date must stay.
  • Departure and destination altitude: the altitude of the parking orbit around the departure and destination body.
  • Max duration: if checked, forces the trajectory solver to try not to exceed the specified maximum duration (in number of days). Note that it may give a trajectory that exceeds the limit if it cannot find shorter ones.
  • No insertion burn: if checked, ignores circularization at the destination body and instead do a flyby at arrival.

The trajectory search step will then try to find a possible optimal trajectory given the sequence and the departure/arrival conditions.

The resulting trajectory will be displayed in the interactive 3D window, alongside with the details of each maneuver (ejection, DSMs and circularization) and flybys' information.

Ke-Ev-Jo-Ee example trajectory
An example of a Ke-Ev-Jo-Ee trajectory requiring 1693m/s of ΔV (with Eeloo circularization)

Current issues

As mentioned in the introduction, solving MGA trajectories is non trivial, and requires the use of iterative optimization methods which approximate the optimal solution. Thus this tool has no guarantee of giving the best trajectory, and therefore can propose different trajectories for the same input settings. It is recommended to search for several trajectories and then choose the best one. It is also advised to look for small launch windows (i.e close earliest and latest departure dates) to improve the search.

The computed trajectory itself may not be feasible in game because this tool may not consider some in game particularities. Therefore the maneuvers' details are more indicative and fine tunings are necessary.

For the Jool's system, since the SOIs of the satellites are large compared to the radius of their orbits, it is possible that a produced trajectory is not feasible because it intersects a satellites's SOI before reaching the final state of an arc.