Overview

This project solves the interplanetary route planning problem by computing transfer orbits between celestial bodies. It evaluates trajectories across launch windows, considers multiple intermediate refueling stops, and returns both fuel efficient and time optimal solutions. The system integrates real time ephemeris data from NASA JPL Horizons to ensure accurate planetary positions.

Dependencies

The following external libraries are required:

numpy: Numerical computation for vector operations

astropy: Astronomy utilities, specifically unit handling

poliastro: Astrodynamics library implementing Izzo's Lambert solver

requests: HTTP client for NASA Horizons API queries

Install dependencies:

pip install numpy astropy poliastro requests

Alternatively, create a virtual environment:

python3 -m venv venv

source venv/bin/activate # On Windows: venv\Scripts\activate

pip install numpy astropy poliastro requests

Compilation and Execution

The program accepts six positional arguments:

python main.py <ship_type> <payload_kg> <window_start> <window_end>

Arguments:

• origin - Starting celestial body (e.g., Earth, Mars)
• destination - Target celestial body
• ship_type - Spacecraft model identifier (see Ship Types section)
• payload_kg - Payload mass in kilograms
• window_start - Launch window start date (DDMMYYYY format)
• window_end - Launch window end date (DDMMYYYY format)

Example:

python main.py Earth Mars "Moonivan" 250 01012026 15012026

This computes Earth-to-Mars trajectories for "Moonivsn" carrying 250 kg between January 1-15, 2026.

Alternative way to run by the GUI: Just launch the gui.py from the home directory. You can use the same with any examples. This may take a bit to run as it is taking samples over 100 years and alaysing the correct output.

Output Format

The program outputs JSON containing two flight plans:

1. Efficient flight parameters - Minimizes total fuel consumption
2. Soonest arrival flight parameters - Minimizes total travel time

Each solution includes:

• Launch date and velocity vector
• Delta-v requirements for orbital insertion
• Intermediate stop details (arrival, refueling, relaunch vectors)
• Total fuel consumption
• Final arrival parameters

If no feasible trajectory exists within constraints, the output contains:

{ "Flight impossible": true }

Data Persistence

Successful route calculations are automatically saved to data/routes.json with timestamps and request parameters for later analysis.

Key Components

Lambert Solver (physics/lambert_solver.py)

Implements the solution to Lambert's problem using Poliastro's Izzo algorithm. Given two position vectors and a time-of-flight, computes the required velocity vectors for a transfer orbit. The solver evaluates multiple solution branches and selects the trajectory minimizing total delta-v.

Core functionality:

• lambert_solutions() - Returns all valid velocity vector pairs for given boundary conditions
• hyperbolic_dv_from_circular() - Calculates orbital insertion/escape delta-v from hyperbolic excess velocity
• compute_transfer() - Full transfer computation with escape and capture maneuvers

The gravitational parameter of the Sun (μ = 1.327 × 10¹¹ km³/s²) is used for heliocentric calculations.

Trajectory Computation (physics/trajectory.py)

Connects physical calculations to route planning by computing single-leg transfers between bodies. For each leg:

1. Retrieves planetary state vectors from NASA Horizons
2. Solves Lambert's problem for the departure-arrival pair
3. Calculates escape delta-v from departure body's parking orbit
4. Calculates capture delta-v into arrival body's parking orbit
5. Applies Tsiolkovsky rocket equation to determine fuel requirements
6. Validates against spacecraft fuel capacity constraints

The parking orbit assumption is a 12-hour circular orbit above each body's surface, representing orbital station infrastructure.

Best-First Search (planner/search.py)

Implements a priority queue-based search algorithm that explores the state space of multi-leg trajectories. The state representation includes current body, time, cumulative fuel usage, and visited bodies to prevent cycles.

Search mechanics:

• Two separate searches run in parallel: one optimizing fuel, one optimizing time
• Priority queue ordering determined by objective function
• Dominance pruning: states are discarded if dominated by cheaper/faster alternatives in the same time bucket
• Launch time sampling: evaluates departure opportunities at 24-hour intervals
• Time-of-flight sampling: considers transfer durations from 10 to 800 days

Refueling constraints:

• Refuel time calculated as 1 second per kilogram of fuel
• Relaunch window: between refuel completion and 3 days after arrival
• Evaluates relaunch opportunities at 0, 12, 24, 48, 72 hours post-arrival

The search terminates after exploring 2500 states or finding optimal routes.

Fuel consumption computed via:

Δm = m_final * (e^(Δv/I_sp) - 1)

where I_sp is specific impulse and Δv is total delta-v requirement.

NASA Horizons Integration (physics/nasa.py)

Queries JPL's HORIZONS ephemeris system for precise planetary positions and velocities. The API returns state vectors in the ecliptic reference frame centered on the solar system barycenter.

Request parameters:

• Reference plane: Ecliptic (invariable plane of the solar system)
• Output units: Kilometers and seconds
• Vector format: Cartesian state vectors (position and velocity)
• Coordinate center: Solar System Barycenter (500@10)

This ensures sub-kilometer accuracy for trajectory calculations across multi-year mission durations.

Algorithm Details

Search Space Exploration

The planner constructs a directed acyclic graph where:

• Nodes represent states (body, time, fuel consumed, path history)
• Edges represent single-leg transfers
• Edge weights are either fuel cost or time duration

States are expanded in priority order until reaching the destination. The search maintains two separate frontiers optimized for different objectives.

Dominance Pruning Strategy

To manage computational complexity, the algorithm partitions time into 2-day buckets. Within each bucket at each body, only the 6 Pareto-optimal states (by fuel and time) are retained. This bounds memory usage while preserving solution quality.

Constraint Handling

Hard constraints:

• Fuel capacity: Total mission fuel cannot exceed tank capacity
• Payload limits: Payload mass must not exceed ship specifications
• Physical feasibility: Parking orbits must be above planetary surfaces
• Temporal ordering: Arrival times must follow departure times

Soft constraints optimized:

• Minimize total delta-v (fuel objective)
• Minimize total mission duration (time objective)