Trajectory Optimization Gym

Trajectory Optimization Gym#

A number of interplanetary trajectory optimization benchmarks are provided in pykep as User Defined Problems (UDPs), compatible with pygmo [BI20].

All gym problems are instantiated when importing pykep and can therefore be used directly. The full collection is referred to as the pykep gym and is intended as a consistent benchmark set for both evolutionary and gradient-based trajectory optimization methods.

MGA Problems#

The following problems are based on Multiple Gravity Assist (MGA) transcriptions.

gym.cassini1 = Cassini MGA direct tof encoding (Trajectory Optimisation Gym P1)#

MGA benchmark inspired by the historical Cassini-Huygens interplanetary transfer to Saturn. The trajectory combines inner-planet gravity assists to increase heliocentric energy before the final outer-planet leg. The fly-by sequence is E-VVEJ-S and reproduces the classic mission-design logic of chaining resonant planetary encounters to reduce propellant demand. The objective is the total \(\Delta V\), including launch excess \(\Delta V\), intermediate maneuvers, and final Saturn orbit insertion (\(r_p = 108950\ \mathrm{km}\), \(e = 0.98\)).

gym.cassini1_a = Cassini MGA alpha tof encoding (Trajectory Optimisation Gym P2)#

Same physical problem as cassini1, but using alpha time-of-flight encoding. This encoding is useful when per-leg time-of-flight bounds are not known a priori. It introduces an additional decision variable for total time-of-flight, making it convenient for multi-objective formulations where total mission duration is an explicit objective.

gym.cassini1_n = Cassini1 MGA eta tof encoding (Trajectory Optimisation Gym P3)#

Same physical problem as cassini1, but using eta time-of-flight encoding. As with the alpha variant, this parametrization is useful when direct, per-leg time-of-flight bounds are not available a priori.

MGA-1DSM Problems#

The following benchmarks are MGA problems with one Deep Space Maneuver (DSM) per leg.

gym.cassini2 = Cassini MGA-1DSM direct tof encoding (Trajectory Optimisation Gym P11)#

MGA-1DSM benchmark inspired by the Cassini transfer to Saturn. Compared to cassini1, one DSM is allowed on each leg, and launch \(\Delta V\) is modeled as a bounded quantity rather than being directly minimized. This shifts more optimization freedom to in-flight control decisions, making the benchmark representative of preliminary design studies where launch capability is preallocated and cruise shaping is critical.

gym.rosetta = Rosetta (Trajectory Optimisation Gym P10)#

MGA-1DSM benchmark inspired by Rosetta’s transfer to comet 67P/Churyumov-Gerasimenko. The fly-by sequence is E-EMEE-comet. The objective is rendezvous (position and velocity matching at arrival) while minimizing total maneuver \(\Delta V\); launch \(\Delta V\) is bounded. The instance captures a key challenge of small-body rendezvous missions: constructing a long, weakly forced transfer that arrives with low relative velocity after multiple inner-Solar-System gravity assists.

gym.eve_mga1dsm = Earth-Venus-Earth mga-1dsm (Trajectory Optimisation Gym P7-9)#

Compact MGA-1DSM benchmark for algorithm testing. The planetary sequence is E-V-E. The objective is Earth rendezvous (position and velocity matching) with minimum total maneuver \(\Delta V\); launch \(\Delta V\) is bounded. Despite its compact size, this benchmark preserves the main coupling patterns of larger MGA-1DSM problems and is therefore useful for rapid solver prototyping, tuning, and regression testing.

gym.eve_mga1dsm_a = Earth-Venus-Earth mga-1dsm (Trajectory Optimisation Gym P7-9)#

Same physical problem as eve_mga1dsm, with alpha time-of-flight encoding (see cassini1_a).

gym.eve_mga1dsm_n = Earth-Venus-Earth mga-1dsm (Trajectory Optimisation Gym P7-9)#

Same physical problem as eve_mga1dsm, with eta time-of-flight encoding (see cassini1_n).

gym.juice = Juice (Trajectory Optimization Gym P13-14)#

MGA-1DSM benchmark inspired by ESA’s JUICE transfer to Jupiter. The sequence is E-EVEME-J and includes an Ariane 5 launcher model from Kourou. The instance reflects the mission-design context of delivering a large science payload to the Jovian system through an energy-constrained, multi-assist trajectory with strict launch and cruise trade-offs.

gym.juice_mo = Juice (Trajectory Optimization Gym P13-14)#

Multi-objective variant of juice. It uses alpha encoding for time-of-flight variables (see cassini1_a) and includes total mission time-of-flight as a second objective. This formulation is aimed at constructing trade-off fronts between propellant usage and transfer duration in the same mission context.

gym.messenger = MGA_1DSM Trajectory#

MGA-1DSM benchmark inspired by the MESSENGER transfer to Mercury. The fly-by sequence is E-VVMeMeMe-Me (with the first Earth correction fly-by omitted because no launcher model is used). This benchmark is intentionally difficult: resonant Mercury fly-bys and multiple-revolution opportunities create a rugged optimization landscape and high sensitivity to time-of-flight choices. It is a representative stress test for global optimization methods in chemically propelled, gravity-assist-heavy inner-planet missions.

Multiple-Impulse Problems#

These benchmarks represent Earth-Moon transfer problems with a fixed number of impulses. They provide compact testbeds for studying how optimization difficulty scales with control dimensionality as the number of allowed impulses increases.

gym.em3imp = Earth-Mars 3 impulses (Trajectory Optimisation Gym P4)#
gym.em5imp = Earth-Mars 5 impulses (Trajectory Optimisation Gym P5)#
gym.em7imp = Earth-Mars 7 impulses (Trajectory Optimisation Gym P6)#

TOPS Problems#

The TOPS (Trajectory Optimisation Problems in Space) benchmarks [IHA+26] are a collection of low-thrust trajectory optimization problems specified in JSON format.

In pykep these datasets are available as dictionaries under: tops_twobody_json, tops_mee_json, tops_ss_json, and tops_cr3bp_json, corresponding to two-body Cartesian, two-body MEE, solar-sail, and CR3BP dynamics.

NLP transcriptions of selected TOPS instances are also provided as UDP classes in pykep.trajopt.gym.

All formulations use zero-order-hold control over a user-defined number of segments and a forward-backward shooting scheme ([IHA+26]). This induces nonlinear mismatch constraints; non-solar-sail variants also include throttle constraints. The resulting NLP size and difficulty can be tuned through nseg and the time-grid encoding (for example uniform or softmax).

Fixed Boundaries#

A first set of TOPS instances as NLPs is provided with fixed initial/final states and, in most cases, fixed time-of-flight. These benchmarks are suitable for controlled algorithm comparisons and as an entry point to the pykep gym. Non-solar-sail variants are built on zoh_point2point, while the solar-sail variant is built on zoh_ss_point2point.

class pykep.trajopt.gym.tops_twobody(prob_name, cut=0.5, nseg=10, time_encoding='uniform', inequalities_for_tc=True)#

Two-body problems from TOPS (Trajectory Optimisation Problems in Space).

Note

These instances have fixed end-points and (mostly) fixed time of flight, so they are not moving-end problems.

The TOPS benchmark problems, from Trajectory Optimisation Problems in Space, are low-thrust trajectory optimization problems described in json format. In this specific instance the spacecraft dynamics are modeled in Cartesian coordinates under two-body motion and. The transcription to a Non Linear Programming priblem (NLP) uses a forward-backward shooting scheme, which introduces highly nonlinear mismatch constraints, together with throttle constraints on the segment controls.

The control is represented with a zero-order hold over each segment, so the resulting NLP size and difficulty depend on the number of segments and on the selected time encoding. Different choices of nseg and time_encoding therefore provide a convenient way to regulate the dimensionality and complexity of the benchmark. The formulation is built on zoh_point2point, so the departure and arrival states are fixed and moving-end effects are not accounted for.

Construct a two-body TOPS instance from a predefined gym case.

Args:
prob_name (str): Name of the predefined gym problem case from the TOPS database

(two-body Cartesian dynamics). Available problem names can be found in the keys of tops_twobody_json. For example: 'P0', 'P1', 'P2', etc.

cut (float, optional): Cut parameter for the forward/backward split in the ZOH transcription.

Defaults to 0.5.

nseg (int, optional): Number of constant-control segments for the zero-order hold transcription.

Each segment contributes to the NLP dimensionality and complexity. Defaults to 10.

time_encoding (str, optional): Time-grid encoding scheme. Options are:

  • 'uniform': equally spaced segment boundaries over the total time of flight.

  • 'softmax': variable segment lengths controlled by softmax weights added to the decision vector.

Defaults to 'uniform'.

inequalities_for_tc (bool, optional): If True, throttle constraints and

boundary relative-velocity direction constraints are formulated as inequalities (|i_u|**2 - 1 <= 0), otherwise as equalities. Defaults to True.

class pykep.trajopt.gym.tops_mee(prob_name, cut=0.5, nseg=10, time_encoding='uniform', inequalities_for_tc=True)#

Mean equinoctial elements problems from TOPS.

Note

These instances have fixed end-points and (mostly) fixed time of flight, so they are not moving-end problems.

The TOPS benchmark problems, from Trajectory Optimisation Problems in Space, are low-thrust trajectory optimization problems transcribed into nonlinear programs by a direct method. In this instance the spacecraft dynamics are modeled in modified equinoctial elements under two-body motion. The transcription uses a forward-backward shooting scheme, which introduces highly nonlinear mismatch constraints, together with throttle constraints on the segment controls.

The control is represented with a zero-order hold over each segment, so the resulting NLP size and difficulty depend on the number of segments and on the selected time encoding. Different choices of nseg and time_encoding therefore provide a convenient way to regulate the dimensionality and complexity of the benchmark. The formulation is built on zoh_point2point, so the departure and arrival states are fixed and moving-end effects are not accounted for.

Construct a two-body MEE TOPS instance from a predefined gym case.

Args:
prob_name (str): Name of the predefined gym problem case from the TOPS database

(two-body dynamics in modified equinoctial elements). Available problem names can be found in the keys of tops_mee_json. For example: 'P0', 'P1', 'P2', etc.

cut (float, optional): Cut parameter for the forward/backward split in the ZOH transcription.

Defaults to 0.5.

nseg (int, optional): Number of constant-control segments for the zero-order hold transcription.

Each segment contributes to the NLP dimensionality and complexity. Defaults to 10.

time_encoding (str, optional): Time-grid encoding scheme. Options are:

  • 'uniform': equally spaced segment boundaries over the total time of flight.

  • 'softmax': variable segment lengths controlled by softmax weights added to the decision vector.

Defaults to 'uniform'.

inequalities_for_tc (bool, optional): If True, throttle constraints are

formulated as inequalities (|i_u|**2 - 1 <= 0), otherwise as equalities. Defaults to True.

class pykep.trajopt.gym.tops_ss(prob_name, cut=0.5, nseg=10, time_encoding='uniform')#

Solar sailing problems from TOPS.

Note

These instances have fixed end-points and (mostly) fixed time of flight, so they are not moving-end problems.

The TOPS benchmark problems, from Trajectory Optimisation Problems in Space, are low-thrust trajectory optimization problems transcribed into nonlinear programs by a direct method. In this instance the spacecraft is controlled by a solar sail and the transcription uses a forward-backward shooting scheme, which introduces highly nonlinear mismatch constraints.

The control is represented with a zero-order hold over each segment, so the resulting NLP size and difficulty depend on the number of segments and on the selected time encoding. Different choices of nseg and time_encoding therefore provide a convenient way to regulate the dimensionality and complexity of the benchmark. Unlike the non solar-sail TOPS instances, this formulation does not include throttle constraints. The formulation is built on zoh_ss_point2point, so the departure and arrival states are fixed and moving-end effects are not accounted for.

Construct a solar-sailing TOPS instance from a predefined gym case.

Args:
prob_name (str): Name of the predefined gym problem case from the TOPS database

(solar sail dynamics). Available problem names can be found in the keys of tops_ss_json. For example: 'P0', 'P1', 'P2', etc.

cut (float, optional): Cut parameter for the forward/backward split in the ZOH transcription.

Defaults to 0.5.

nseg (int, optional): Number of constant-control segments for the zero-order hold transcription.

Each segment contributes to the NLP dimensionality and complexity. Defaults to 10.

time_encoding (str, optional): Time-grid encoding scheme. Options are:

  • 'uniform': equally spaced segment boundaries over the total time of flight.

  • 'softmax': variable segment lengths controlled by softmax weights added to the decision vector.

Defaults to 'uniform'.

class pykep.trajopt.gym.tops_cr3bp(prob_name, cut=0.5, nseg=60, time_encoding='uniform', inequalities_for_tc=False)#

CR3BP problems from TOPS.

Note

These instances have fixed end-points and (mostly) fixed time of flight, so they are not moving-end problems.

The TOPS benchmark problems, from Trajectory Optimisation Problems in Space, are low-thrust trajectory optimization problems transcribed into nonlinear programs by a direct method. In this instance the spacecraft dynamics are modeled in the circular restricted three-body problem. The transcription uses a forward-backward shooting scheme, which introduces highly nonlinear mismatch constraints.

The control is represented with a zero-order hold over each segment, so the resulting NLP size and difficulty depend on the number of segments and on the selected time encoding. Different choices of nseg and time_encoding therefore provide a convenient way to regulate the dimensionality and complexity of the benchmark. In this CR3BP formulation throttle constraints are not exposed as separate inequalities. The formulation is built on zoh_point2point, so the departure and arrival states are fixed and moving-end effects are not accounted for.

Construct a CR3BP TOPS instance from a predefined gym case.

Args:
prob_name (str): Name of the predefined gym problem case from the TOPS database

(circular restricted three-body problem dynamics). Available problem names can be found in the keys of tops_cr3bp_json. For example: 'P0', 'P1', 'P2', etc.

cut (float, optional): Cut parameter for the forward/backward split in the ZOH transcription.

Defaults to 0.5.

nseg (int, optional): Number of constant-control segments for the zero-order hold transcription.

Each segment contributes to the NLP dimensionality and complexity. CR3BP problems typically require more segments than two-body problems. Defaults to 60.

time_encoding (str, optional): Time-grid encoding scheme. Options are:

  • 'uniform': equally spaced segment boundaries over the total time of flight.

  • 'softmax': variable segment lengths controlled by softmax weights added to the decision vector.

Defaults to 'uniform'.

inequalities_for_tc (bool, optional): If True, throttle constraints are

formulated as inequalities (|i_u|**2 - 1 <= 0), otherwise as equalities. Defaults to False.

Moving Boundaries#

Moving-boundary NLP formulations extend the fixed-boundary setting by allowing departure and arrival epochs to vary, with endpoint states tied to planet ephemerides and optional relative-velocity constraints. This setup is closer to preliminary mission design use cases and introduces a harder optimization problem because boundary epochs become decision variables and two constraints are added to control the relative velocity at both endpoints.

In terms of base transcriptions, non-solar-sail variants are formulated on zoh_pl2pl, while solar-sail variants use zoh_ss_pl2pl.

Note

At the moment, only the fixed-boundary TOPS classes are exposed under pykep.trajopt.gym.