Motivation
The goal of this article is to build upon the Python codes, and results described in [3],[4], generalise the problem of finding DeltaV-optimal and (DeltaV,T) optimal trajectories, and make Python utilities available to the Orbiter Community, which can solve a variety of optimal Multiple Gravity Assist problems, and output the plan in a format, which directly translates into a TransX plan, based on the mathematics of [2]
PyKEP/PyGMO
PaGMO/PyGMO, are powerful C++/Python frameworks for performing single-, and multi-objective nonlinear optimisation. They provide a flexible framework for defining new problems in a way, so that a whole regiment of optimisation algorithms (and combination of these) can be applied on the problem, all this built upon the Generalised Island Model, for easy distribution of the problem to multi-CPU, and multi-machine clusters.
PyKEP is a library, to help in defining astronomical problems. It provides tools and utilities, to access planet parameters, ephemerides, and solve corresponding problems (like Lambert's problem).
Big thanks for the ESA Advanced Concepts team for sharing this great tool.
MGA and MGA-1DSM problems
A short intuitive (non-mathematical) definition comes of the MGA and MGA-1DSM problems.
For a more detailed and precise definition, please refer to [1]
MGA
In the MGA (stands for Multiple Gravity Assist) problem, you have a sequence of planetary bodies (p_1, p_2, ..., p_n), and you want to find an interplanetary trajectory, which starts from p_1, ends in p_n, encounters bodies p_i (i = 2..{n-1}), while minimising total deltaV.
A multi-objective definition would attempt to find optimal (deltaV, T) pair, where T is the total time of the journey.
The legs of the MGA problem are the parts of the trajectory separated by the planetary encounters.
In the MGA problem, the vessel is allowed to make a burn only at the beginning, and end of each leg, thus powered fly-byes are possible, but no Deep Space maneuver is allowed.
The decision vector of the problem is [t0, t_1, t_2, ..., t_n], where t_i is the time of encounter with the ith planetary body.
To solve a multi-leg problem like this, it is common practice to treat the legs individually. So for a given value of the decision vector, we have n-1 problems, which say: I want to leave p_i at t_i and arrive at p_{i+1} at time t_{i+1}. The resulting problem is called Lambert's problem, which given some restrictions employs a single solution, and we saw it's utilisation in the cited works of Keithth G.
Note: The scripts shared in [2] are basically solving the MGA problem, but instead of bounding on t0 and T, it requires a common bound on all the t_i.
MGA-1DSM
In the MGA-1DSM problem, the task is the same, however the vessel is allowed to make at most 1 Deep Space Maneuver during each leg.
The concepts and mathematics are discussed in detail in [1]. The basis of my problem implementations were mainly the ESA code, as well as Keithth G's code.
Overview of my contributions
The coding I've done can be located in this Github repository
The main script performs the following:
I found this approach beneficiary while tuning the algorithms, since seeing the best MGA and best multi-objective MGA_1DSM solution together gives us a hunch about how good our plan got to the truth.
Since if the travel time of the MGA plan is considerably higher than that of the MGA_1DSM plan, but the deltaV increase is moderate compared to the decrease of travel time, because the solutions of both MGA and MGA_1DSM are heavily clustered, we are probably in the good basin of low deltaV solutions.
But I'd like to note here the dimension of the MGA-1DSM problem is considerably higher, so both the iterations, both the convergence time are much longer. If you just want a quick plan, execute 5 rounds of MGA. If you feel it's too long, you can execute MGA-1DSM, but then you might want to go out for a coffee.
The main script to run, is OrbiterKEP.py, and the usage is something like this:
t0_min, t0_max: Bounds for the launch window, in ISO date format, e.g. '20160629T151758'
Notes about the current code
At the end of the execution, or when it is interrupted, the (so far) best MGA and MGA-1DSM solutions are both printed out, in the format which Keithth G layed down, and which can be directly inputted into TransX to fly the plan.
Sample execution
Output:
As you see, in this case the MGA-1DSM plan is just a very expensively obtained inferior version of the MGA plan. The DSMs are basically 0, an the deltaV we paid for 20 days shorter trip is way much. So for recreational use, I recommend the MGA only execution.
It's way faster, and the result is usually quite OK.
Possible areas of future research, to make more use of PyKEP/PyGMO (or other trajectory optimisation tools) in Orbiter
Author's notes
This article, and the corresponding code was created out of mere enthusiasm, and though I have some prior knowledge and experience with Global Optimisation, is completely empiric, and not in any way claims to be comparable with real-world trajectory planning (though it might be).
Any piece of code on Github are free to reproduce, modify, redistribute, in any way.
If you need a hand in you project where you'd use it, give me a note, I might be interested
This article would not exist without
- Advanced Concepts team of ESA creating the great tools PyKEP and PyGMO are, and making it available to the research community for free
- Keithth G bringing the tools to our attention.
Bibliography
[1] Izzo - Global Optimization and Space Pruning for
Spacecraft Trajectory Design
[2] PyKEP to TransX conversion
[3] Optimal Earth-Venus-Mercury transfer - PyKEP / PyGMO
[4] Earth to Jupiter on less than 2 m/s a day, the PyKEP way!
Update: 2016-05-30
The multi-objective parts of the script are not quite good yet, and also the performance is terrible. Porting of problem definitions to C++ is in progress, and also an update to allow for nice draw-up of Pareto fronts for the Multi-objective case, which visualises the trade-off very good.
The goal of this article is to build upon the Python codes, and results described in [3],[4], generalise the problem of finding DeltaV-optimal and (DeltaV,T) optimal trajectories, and make Python utilities available to the Orbiter Community, which can solve a variety of optimal Multiple Gravity Assist problems, and output the plan in a format, which directly translates into a TransX plan, based on the mathematics of [2]
PyKEP/PyGMO
PaGMO/PyGMO, are powerful C++/Python frameworks for performing single-, and multi-objective nonlinear optimisation. They provide a flexible framework for defining new problems in a way, so that a whole regiment of optimisation algorithms (and combination of these) can be applied on the problem, all this built upon the Generalised Island Model, for easy distribution of the problem to multi-CPU, and multi-machine clusters.
PyKEP is a library, to help in defining astronomical problems. It provides tools and utilities, to access planet parameters, ephemerides, and solve corresponding problems (like Lambert's problem).
Big thanks for the ESA Advanced Concepts team for sharing this great tool.
MGA and MGA-1DSM problems
A short intuitive (non-mathematical) definition comes of the MGA and MGA-1DSM problems.
For a more detailed and precise definition, please refer to [1]
MGA
In the MGA (stands for Multiple Gravity Assist) problem, you have a sequence of planetary bodies (p_1, p_2, ..., p_n), and you want to find an interplanetary trajectory, which starts from p_1, ends in p_n, encounters bodies p_i (i = 2..{n-1}), while minimising total deltaV.
A multi-objective definition would attempt to find optimal (deltaV, T) pair, where T is the total time of the journey.
The legs of the MGA problem are the parts of the trajectory separated by the planetary encounters.
In the MGA problem, the vessel is allowed to make a burn only at the beginning, and end of each leg, thus powered fly-byes are possible, but no Deep Space maneuver is allowed.
The decision vector of the problem is [t0, t_1, t_2, ..., t_n], where t_i is the time of encounter with the ith planetary body.
To solve a multi-leg problem like this, it is common practice to treat the legs individually. So for a given value of the decision vector, we have n-1 problems, which say: I want to leave p_i at t_i and arrive at p_{i+1} at time t_{i+1}. The resulting problem is called Lambert's problem, which given some restrictions employs a single solution, and we saw it's utilisation in the cited works of Keithth G.
Note: The scripts shared in [2] are basically solving the MGA problem, but instead of bounding on t0 and T, it requires a common bound on all the t_i.
MGA-1DSM
In the MGA-1DSM problem, the task is the same, however the vessel is allowed to make at most 1 Deep Space Maneuver during each leg.
The concepts and mathematics are discussed in detail in [1]. The basis of my problem implementations were mainly the ESA code, as well as Keithth G's code.
Overview of my contributions
The coding I've done can be located in this Github repository
The main script performs the following:
- Executes a given number of MGA rounds (single-objective), and keeps hold of the best MGA solution
- Execute a given number of MGA_1DSM rounds (multi-objective), and keeps hold of the best MGA-1DSM solution
I found this approach beneficiary while tuning the algorithms, since seeing the best MGA and best multi-objective MGA_1DSM solution together gives us a hunch about how good our plan got to the truth.
Since if the travel time of the MGA plan is considerably higher than that of the MGA_1DSM plan, but the deltaV increase is moderate compared to the decrease of travel time, because the solutions of both MGA and MGA_1DSM are heavily clustered, we are probably in the good basin of low deltaV solutions.
But I'd like to note here the dimension of the MGA-1DSM problem is considerably higher, so both the iterations, both the convergence time are much longer. If you just want a quick plan, execute 5 rounds of MGA. If you feel it's too long, you can execute MGA-1DSM, but then you might want to go out for a coffee.
The main script to run, is OrbiterKEP.py, and the usage is something like this:
Code:
OrbiterKEP.py <comma delimited planets> <t0_min,t0_max> <T_min, T_max> <max vinf> <n_mga> <n_mga_1dsm>t0_min, t0_max: Bounds for the launch window, in ISO date format, e.g. '20160629T151758'
- T_min, T_max: Bounds for the travel time in years
- max_vinf: Only or MGA_1DSM, bounds for the initial Hyperbolic Excess Velocity (depends on Launcher performance)
- n_mga: The number of MGA executions. The best solution is selected.
- n_mga_1dsm: The number of MGA_1DSM executions. The best solution is selected.
Notes about the current code
- The departure is assumed to happen from 300km circular orbit
- Arrival is assumed to happen to a 300km orbit, and fuel calculations assume that we circularise.
- The current state of the code reflects the results of quite some heuristic experimenting, and not scientifially fine-tuned. I have no idea of the statistical significance of the minimums found by the script, but they are fairly consistent.
- The outputted deltaVs are larger than the published minimums of some known problems, because I found that they include only capture and not circularisation at the end, and they sometimes omit the initial Vinf from the optimisation (i suppose because that depends on the Launcher, more than on the vessel.
At the end of the execution, or when it is interrupted, the (so far) best MGA and MGA-1DSM solutions are both printed out, in the format which Keithth G layed down, and which can be directly inputted into TransX to fly the plan.
Sample execution
Code:
python OrbiterKEP.py earth,jupiter,earth 20160529T000000,20200731T000000 0.1,4 10 1 1Output:
Code:
12882.99921
Done!! Best solution found is: 12.882999206 km / sec
16828.0437288
14500.6366084
14006.4646272
13924.0551128
13884.0113768
13852.7141831
13791.7759761
13763.0262554
13736.4288525
13684.9405694
13656.0140438
13644.4253897
13634.2810758
13634.0894901
13633.8290046
13626.7727111
13622.0974784
13617.9261942
13613.5450787
13606.7856869
13606.1563411
13605.9139066
13605.7153147
13605.4892069
13601.4990365
13601.2014242
13601.1011724
13600.3886857
13599.2203557
13598.8548067
13598.6778531
13598.6736536
13597.2842989
13597.1774475
13597.0142723
13596.9133169
13596.742478
13596.5965887
13596.3932734
13596.3331935
13596.3143379
Done!! Best solution found is: 13.5962557481 km / sec
Date of earth encounter: 2018-Jan-13 21:13:52.196100
Date of jupiter encounter: 2020-Jan-24 09:35:24.244445
Date of earth encounter: 2021-Dec-09 07:20:06.195060
Transfer time from earth to jupiter:740.51 days
Transfer time from jupiter to earth:684.91 days
Total mission duration: 1425.42 days
TransX escape plan - earth escape
--------------------------------------
MJD: 58131.8846
Prograde: 8927.602 m/s
Outward: -37.438 m/s
Plane: -154.875 m/s
Hyp. excess velocity: 8929.024 m/s
Earth escape burn: 6384.606 m/s
jupiter encounter
--------------------------------------
MJD: 58872.3996
Approach velocity: 7468.580 m/s
Departure velocity: 7468.580 m/s
Outward angle: -135.564 deg
Inclination: -1.454 deg
Turning angle: 82.924 deg
Periapsis altitude: 1087475.220 km
dV needed: 0.000 m/s
earth arrival
--------------------------------------
MJD: 59557.3056
Hyp. excess velocity: 9107.778 m/s
Orbit insertion burn 6498.394 m/s
Total fuel cost: 12882.999 m/s
Date of earth encounter: 2020-Apr-09 15:39:13.116140
Date of jupiter encounter: 2022-Mar-21 21:09:42.877770
Date of earth encounter: 2024-Feb-14 06:51:18.113795
Transfer time from earth to jupiter:711.23 days
Transfer time from jupiter to earth:694.4 days
Total mission duration: 1405.63 days
TransX escape plan - earth escape
--------------------------------------
MJD: 58948.6522
Prograde: 8484.038 m/s
Outward: 4974.500 m/s
Plane: 1418.920 m/s
Hyp. excess velocity: 9936.694 m/s
Earth escape burn: 7042.880 m/s
Deep Space Burn
--------------------------------------
MJD: 59659.5309
Prograde: 0.128 m/s
Outward: 0.258 m/s
Plane: -0.233 m/s
Hyp. excess velocity: 38538.945 m/s
DSM burn: 0.370 m/s
jupiter encounter
--------------------------------------
MJD: 59659.8817
Approach velocity: 7172.166 m/s
Departure velocity: 7172.166 m/s
Outward angle: -144.339 deg
Inclination: 2.690 deg
Turning angle: 68.305 deg
Periapsis altitude: 1852597.259 km
dV needed: 0.000 m/s
Deep Space Burn
--------------------------------------
MJD: 60354.2787
Prograde: -0.027 m/s
Outward: -0.096 m/s
Plane: -0.058 m/s
Hyp. excess velocity: 8863.420 m/s
DSM burn: 0.115 m/s
earth arrival
--------------------------------------
MJD: 60354.2856
Hyp. excess velocity: 9192.657 m/s
Orbit insertion burn 6552.891 m/s
Total fuel cost: 13596.256 m/sAs you see, in this case the MGA-1DSM plan is just a very expensively obtained inferior version of the MGA plan. The DSMs are basically 0, an the deltaV we paid for 20 days shorter trip is way much. So for recreational use, I recommend the MGA only execution.
It's way faster, and the result is usually quite OK.
Possible areas of future research, to make more use of PyKEP/PyGMO (or other trajectory optimisation tools) in Orbiter
- Possibly a plugin, which provides in-Orbiter ways to help in execution of the plan, by e.g. setting up TransX for each legs, by inputting velocities, angles, so that user only has to finalise the maneuver.
- Improve the performance of the scripts to the degree, where it is possible to do live execution using an MFD.
- Find better combination of algorithms to tackle the MGA and MGA-1DSM problems.
Author's notes
This article, and the corresponding code was created out of mere enthusiasm, and though I have some prior knowledge and experience with Global Optimisation, is completely empiric, and not in any way claims to be comparable with real-world trajectory planning (though it might be).
Any piece of code on Github are free to reproduce, modify, redistribute, in any way.
If you need a hand in you project where you'd use it, give me a note, I might be interested
This article would not exist without
- Advanced Concepts team of ESA creating the great tools PyKEP and PyGMO are, and making it available to the research community for free
- Keithth G bringing the tools to our attention.
Bibliography
[1] Izzo - Global Optimization and Space Pruning for
Spacecraft Trajectory Design
[2] PyKEP to TransX conversion
[3] Optimal Earth-Venus-Mercury transfer - PyKEP / PyGMO
[4] Earth to Jupiter on less than 2 m/s a day, the PyKEP way!
Update: 2016-05-30
The multi-objective parts of the script are not quite good yet, and also the performance is terrible. Porting of problem definitions to C++ is in progress, and also an update to allow for nice draw-up of Pareto fronts for the Multi-objective case, which visualises the trade-off very good.
Last edited:
