Tool Description

The interplanetary transfer planner is a tool to give you an overview of transfer windows from a starting planet to a destination planet. In this case, transfer windows do not only include direct transfers from planet A to planet B, but also include transfers using swing-by at other planets as well.

The aim of this tool is to be accessible for people who don't have a lot of experience (if any) with interplanetary transfers using swing-bys. The only aspects of your transfer you really need to know are:

• The celestial system of your transfer (e.g. solar system or Kerbol system)
• Your starting and destination planet
• The time frame in which you want to launch
• The latest arrival date or the longest travel duration you desire
• Optionally (but recommended) $\Delta$ v-requirements for the transfer

If you are looking for a helping hand with the planning of efficient interplanetary transfers or you want to get started with interplanetary gravity assists, this might be the tool you are looking for.

Itinerary Calculator

When you first start the program you will be looking at the view of the Itinerary Calculator (see image below). From this view you will set the parameters for and initiate the analysis:

1. The celestial system of your transfer. Available systems are loaded on program startup. (More on the handling of celestial systems in the Celestial System section below.)
2. The body from which you plan on departing and the body you want to arrive at.
3. The time frame and transfer duration limits. These need to be in a specific format (YYYY-MM-DD for Real Solar System time and YYY-DDD for Kerbal time). (More on handling of time and dates in the Time section.)
4. The $\Delta$ v-constraints. The departure $\Delta$ v is the required change in speed you need at departure (duh!) and satellite $\Delta$ v is all the remaining $\Delta$ v-costs. The total is the sum of the departure and satellite $\Delta$ v. It is optional to set them to a lower value, but highly recommended to decrease calculation time and size of the results file. The final transfer type decides whether you have a fly-by at your destination, a capture burn or a circularization burn. While you can still change this option later, setting it now will help to filter out any unwanted paths and save calculation time/storage space. The required satellite $\Delta$ v is directly dependent on that selection. (The capture or circularization burn as well as the departure burn are currently set at 50km above the body's atmosphere or, if no atmosphere exists, the body's surface).
5. Select the bodies that may be part of the itinerary.
6. Get reference values for $\Delta$ v-costs and transfer duration in the form of a Hohmann transfer from departure to arrival body (assuming bodies' orbits as circular).

The time the calculation takes is dependent on how constraint the parameters are set. Meaning the more liberal these constraints are set, the longer the runtime. The initial constraints of the tool are way too high (definitely adjust max arrival date or max travel duration). For $\Delta$ v constraints, use a $\Delta$ v-map as a reference. In general you can expect runtimes between under a minute to up to a few hours. The analysis takes longer if it finds more transfer opportunities (this also applies to single departure dates).

To end the calculation prematurely, there are two options. If you press the 'End Calculation' button, the program will end the calculation it started and let you save the results it already reached. If you want to stop the analysis immediately, close the program (all results of the current analysis will be lost).

When the analysis is finished and if it found any transfers, you will then have the option to save the results in a .itins-file. This file is needed for the next step. If you do not save the results, they will be lost. (This is a binary file with its own format.)

(The analysis will btw use every CPU-Juice from every core it can get. This is expected, but should not slow down the PC considerably.)

Sequence Calculator

The same as the Itinerary Calculator with the difference that a fixed sequence of fly-bys will be set (in the marked area). The remaining functionalities are the same as the ones in the Itinerary Calculator. Using the Sequence Calculator instead of the Itinerary Calculator is considerably faster. Use this one if a sequence of fly-bys (e.g. the Voyager itinerary) is already known.

Porkchop Analyzer

In the porkchop analyzer (you probably won't analyze actual porkchop plots but I am bad at naming stuff) you will analyze the results from the Itinerary Calculator. For that, you load (1) the .itins-file and the analyzer will visualize the determined transfers by putting them on a plot (2) transfer duration against departure date with the required $\Delta$ v-costs being visualized as colors (cyan = good, pink = bad).

The shown transfers can be limited by the given filters (3) next to the plot (if the filters don't match the plot, update the filter). If you switch to the group selection (4), you can also see and/or limit the possible transfer sequences. (At this time you need to try and match the numbers with the bodies. I haven't found a clean solution for this yet. 1 could be Moho/Mercury, 3 could be Kerbin/Earth, etc.)

The most efficient transfer gets a red dot on the plot and is visualized below the plot (5). You can shift through the transfer steps and get some limited information on the departure/fly-by/arrival (.

The best found transfer can be stored in a .itin-file (again a binary file with a custom format) to use in the next step (7).

Transfer Planner

The Transfer Planner can be used to visualize and modify a transfer stored by the Porkchop Analyzer or the Transfer Planner itself. It can also be used to build an itinerary from the ground up or find some rough estimates on transfer windows.

1. System Setup:
You can load a system into the planner by selecting it from the drop-down menu. When an itinerary is loaded, its system is automatically loaded into the planner (not changing the drop-down menu). The orbits of the system's bodies can be visualized using the checkboxes next to their respective names

2. Time control:
The visualized state of the system is always the one at the date that is given. The date can be adjusted forwards or backwards in time by 10years/1year/1month/30days/1day. (1 month or 30 days depending on the time format.)

3. Itinerary editor:
From here you can go threw each step of the itinerary by using the arrow buttons. Some relevant parameters of the Departure/Fly-By/Arrival are shown in the bottom. The 'Transfer dv' is the dv-cost of the current step and the parameters given are respective to the step's celestial body (some info can be useful for a more thorough analysis using e.g. GMAT). The dv-cost of the last step is dependent on the whether a capture/circularization burn is done (selectable using 'Last Transfer'). There are several ways to edit the itinerary:

• Change the current step's celestial body by clicking on the body's button (the button between the arrows)
• Change the date of the current step by clicking on the date and changing the date using the time controls.
• Add a transfer after the current step or remove the current itinerary step
• Find a valid transfer to the current step from the step before (it might not find one)
• Find a valid itinerary; the date of the departure and the first fly-by are set (it will find one if you are lucky)

4. Load/Save Itinerary:
Load an itinerary stored previously by the Transfer Planner or the Porkchop Analyzer or store the current itinerary in a .itin-file.

5. System and Itinerary Visualizer:
This shows the current state of the system with the current itinerary. Each Departure/Fly-by/Arrival is drawn as a red cross. If a transfer trajectory is drawn in green, it means it is a viable transfer. If a transfer is drawn in red, this transfer is not possible, because the fly-by, the transfer starts at, either goes through the fly-by's body or the spacecraft would gain or lose energy inside the fly-by body's system.

Good to know

Time

The time format can be set in the settings tab. There are currently three formats to choose from:

1. ISO time (ISO8601; Format: YYYY-MM-DD; 1 year = 365 days (365.25 days); 1 day = 24 hours)
   Use this one only for the real solar system
2. Kerbal time (Format: YYY-DDD; 1 year = 426 days; 1 day = 6 hours)
3. ISO-like Kerbal time (Format: YYY-DDD; 1 year = 365 days; 1 day = 24 hours)

Celestial System

The celestial systems are stored in the Celestial_System folder. The program will load every system it can find in there at startup. At the moment you can only import your own celestial by creating a .cfg file for it. The format is important and should be followed:

[NAME OF THE SYSTEM]
system_property = x

[NAME OF CENTRAL BODY]
body_property = x

[NAME OF CHILD BODY1]
body_property = x

[NAME OF CHILD BODY2]
body_property = x

...

You can look at other system .cfg-files to see which properties are available. Not all properties are required but some are strictly needed for the system to be able to be loaded and for the calculator to create some usable results:

• For the celestial system:
  • number_of_bodies (the number of bodies in the system excluding the central body)
  • central_body (name of central body - this needs to be the same name as the first body)
• For the bodies:
  • gravitational_parameter
  • radius
  • The six orbital elements: semi_major_axis, eccentricity, inclination, raan, argument_of_periapsis and true_anomaly_ut0/mean_anomaly_ut0 (ut0 = t0; you can choose either true or mean anomaly)

Solar System using Ephemeris Data:
The id is only needed when the propagation_method is set to 'EPHEMERIDES'. In this case the ephemerides of the planets and celestial bodies of this system are retrieved from JPL's Horizon API using their respective IDs at startup (initial startup might take a few seconds). This obviously only works for the real solar system!

Limitations

• The calculator only uses 2-body physics - It works quite well, because the solar system is in 99% of the time a 2-body system, but the results should not be taken as a guarantee. The swing-bys are assumed to affect the spacecraft instantaneously in a single point.
• No deep space maneuvers - Deep space maneuvers introduce at least two more degrees of freedoms to the analysis, making transfers which use the extremely time consuming to determine.
• No resonance orbits - A transfer orbit from one planet to the next will never rotate above 360° of its true anomaly (waiting orbit). This might come in the future as it is relevant for transfers to Mercury or Moho.

Why this tool was created

After playing RP-1 for quite some time I wanted to step up my game regarding interplanetary transfers and recreate my own Voyager- or Cassini-Huygens-like transfers. Or more precisely, I wanted to try my luck with interplanetary transfers using swing-bys and gravity assists to get more efficient transfers. But the available tools I found were either useless (less efficient than direct transfers) and/or required me to guess a specific sequence of swing-bys. As the state of the solar system changes constantly, no transfer is like the other and a general perfect sequence does not exist.

Because just winging it and hoping for the best after launch is in most cases less efficient (and also not really realistic), I wanted to determine all my options for interplanetary transfers. For that purpose I started working on this calculator for finding transfer possibilities, using only my knowledge from years of playing KSP and using the knowledge I gained in Uni.