I am still stuck on the formulation for targeting planetary ejection. I want to be able to target an arbitrary $v_\infty$ vector starting from a circular equatorial orbit. So far, this picture illustrates what I have so far:

For some vector $\vec{v}_\infty = [v_x v_y v_z]$ and ejection angle $\beta$, I want to be able to generate some maneuver to target this vector on a hyperbolic trajectory

Introduction

This issue comes as as result of an outstanding request from #5, creating a framework for representing mission plans.

The goal is to produce a system and representation that allows describing a multi-part mission between celestial bodies in KSP, including starting/ending/phasing orbits.

Sequence representation is done in the context of gravity assist trajectories.

Requirements

• Produce a system which can represent a sequence of destination celestial bodies
• Provision for intermediate phasing/resonant orbits
• Starting and ending points will be circular orbits of arbitrary orientation around a celestial body

(TODO)

Trajectorize is far enough along now that someone might actually want to use this thing for transfer window planning. Add a short docs site somewhere, showing off how to use the single_transfer module.

requirements-testing.txt should be eliminated in favour of adding optional dependencies in pyproject.toml.

Introduction

This comes as a result of #2 ; the current Lambert solver is basically a carbon copy of what's used in Curtis, but there are most certainly better options out there.

The two main goals for the solver moving forwards are the following:

1. Make the solver more robust, so as to get rid of the "banding" seen in the porkchop plots
2. Make the solver faster

Possibilities

Modifying "in-place"

The existing solver may be modifiable without many major changes to fulfill both performance goals

Pivoting to a new solver

There are a bunch of different implementations out there described in papers, which may be worth looking into both for better robustness as well as speed.