Skip to main content

Spacecraft Configuration

The Moonlander simulator is designed as a research-oriented testbed for descent guidance, control algorithms and propulsion system evaluation. Before starting a simulation run, users select a spacecraft configuration from a set of JSON-defined mission profiles. Each configuration defines the physical and propulsion-related parameters used by the C++ simulation backend.

Spacecraft selection interface

Figure 0 — Spacecraft Selection Interface.   Spacecraft configurations are selected before entering the cockpit. Each lander profile is defined externally and contains mass properties, propulsion data, tank definitions, controller-relevant limits and initial mission conditions.

The selection interface separates configuration management from the simulation engine. This allows new spacecraft variants, propulsion layouts or fuel tank architectures to be introduced without modifying the core simulation code.

If no spacecraft is selected explicitly, the first configuration defined in the JSON file is used as the default. This guarantees that the backend always receives a valid and reproducible initialization state.

Simulation Demonstration

The following demonstration shows the cockpit interface during a representative descent run. The interface is intended not only as a visual cockpit, but also as an engineering and analysis tool for evaluating landing controllers, propulsion behavior and vehicle state evolution. All displayed quantities are computed by the underlying C++ physics model and updated in real time.

Figure 1 — 1500 m Descent Demonstration.Representative descent from 1500 meters using an adaptive descent controller. The cockpit displays navigation state, fuel consumption, propulsion activity, controller output and spacecraft status in real time.

Research-Oriented Cockpit Interface

The cockpit interface has been restructured to support a more scientific workflow. Instead of only presenting a simplified landing animation, the interface now exposes the vehicle state, propulsion state and controller-relevant telemetry in a way that supports debugging, controller comparison and future data export.

NAV — Navigation State

The navigation section displays the lander's current kinematic state in the local navigation frame. The interface is prepared around the ENU convention: East, North and Up. This makes the displayed state directly usable for landing analysis, lateral drift evaluation and controller debugging.

FUEL — Propellant and Tank State

The fuel section has been extended from a single global fuel display to a dynamic tank-based representation. Each configured fuel tank can be displayed individually with its name, role, remaining propellant mass and fill ratio. A visual fill bar shows the remaining propellant relative to the tank capacity.

This supports spacecraft configurations with multiple tanks, such as separate main engine and RCS propellant reservoirs, and makes fuel usage easier to analyze during controller tests.

LANDING VIEW — 2.5D Situational Visualization

The landing visualization has been upgraded from a simple one-dimensional altitude display to a lightweight 2.5D situational view. It shows the lander in a local ENU frame using a side view for vertical motion and a top view for horizontal drift and target-relative motion.

The view includes trajectory history, velocity vectors, target reference and yaw indication. This provides a clearer interpretation of how the vehicle moves through space without requiring full 3D rendering.

ENGINE — Propulsion and Loads

The propulsion section displays thrust-related telemetry and vehicle loads. The interface is being prepared for more complex propulsion systems where multiple thrusters or tank connections may contribute to the resulting force and torque acting on the lander.

CONTROL — Autopilot and Controller Output

The cockpit reports whether the autopilot is active and displays controller output such as active mode information. This is especially relevant for testing different descent controllers and comparing their behavior under identical simulation conditions.

STATUS — Spacecraft State Machine

The status section reports discrete spacecraft states such as OPERATIONAL, LANDED, CRASHED or DESTROYED. These states provide a clear interpretation of the simulation outcome and can be used later for automated evaluation of landing performance.

Scientific Use Case

The simulator is intended to support the development and evaluation of lunar landing control strategies. The cockpit interface therefore focuses on telemetry visibility, reproducibility and system observability rather than visual realism alone.

Planned extensions include structured simulation data export, controller comparison workflows and plotting tools for post-run analysis. Relevant quantities include altitude, vertical velocity, lateral drift, fuel consumption, thrust commands, tank usage and final touchdown conditions.