Mars Lander Simulation Showcase

This repository is a documentation-only portfolio showcase for a Mars Lander simulation project. It describes the engineering work, design approach, testing process, and outcomes without publishing the underlying implementation.

This project was developed using teaching software supplied by the University of Cambridge Department of Engineering. The original software licence prohibits publication of modified source code in order to preserve the integrity of the exercise for future students. Consequently, the source code is not included in this repository. This repository documents my individual contributions, engineering approach, testing process, and project outcomes.

Source-Code Availability

The source code is intentionally not published. The local project inspected for this showcase contains teaching software with a licence restriction against publishing modified source code. To respect that restriction, this repository contains no C or C++ source files, headers, compiled binaries, project files, build files, dependency files, or archives from the original project.

Project Summary

The Mars Lander simulation models the motion of a lander around and onto a Mars-like planetary surface. The supplied framework provides a graphical OpenGL simulator, scenario selection, flight instrumentation, lander dynamics, and baseline teaching infrastructure. My work focused on extending the simulation with terrain-aware physics and landing behaviour so that the lander interacts with a non-uniform spherical terrain model rather than a simple uniform-radius planet.

Engineering Problem

The key engineering challenge was making the simulation internally consistent when the planet surface is no longer smooth and uniform. Once terrain varies with latitude and longitude, several systems must agree with each other:

• The rendered terrain must correspond to the physics surface.
• Altitude must be measured relative to local terrain height, not just radial distance from a fixed sphere.
• Landing and crash detection must account for local surface shape.
• Control logic must respond to realistic descent conditions.
• Testing must cover seams, poles, descent cases, and discrepancies between visual and physical terrain.

Personal Contributions

Based on inspection of the local project, the following contribution claims are supported:

• Terrain-generation system using a spherical height-map representation.
• Terrain-aware altitude estimation.
• Bilinear interpolation for terrain sampling.
• Terrain surface-normal and slope calculations.
• Coordinate conversion between world position and latitude/longitude style terrain queries.
• Terrain-aware descent control and autopilot experimentation.
• Landing and crash detection behaviour integrated with terrain-aware altitude and velocity checks.
• Testing and debug helpers for terrain seams, poles, interpolation behaviour, rendered-terrain consistency, and multiple descent scenarios.
• Investigation of discrepancies between rendered terrain and physics calculations.

These claims are described at a high level only. Exact algorithms, constants, formulas, source structure, and implementation details are omitted to avoid revealing protected assessed solution material.

Main Technical Concepts

• C++
• OpenGL-based simulation and visualization
• Physics simulation
• Numerical integration
• Control systems and autopilot behaviour
• Procedural terrain generation
• Spherical coordinate systems
• Terrain sampling and interpolation
• Collision, landing, and crash detection
• Debugging and regression-style validation

High-Level System Architecture

flowchart TD
    A["Scenario setup"] --> B["Lander state"]
    B --> C["Dynamics update"]
    C --> D["Terrain-aware altitude and surface queries"]
    D --> E["Landing and crash checks"]
    D --> F["Autopilot / control response"]
    C --> G["OpenGL visualization"]
    G --> H["Flight instruments and terrain view"]

The simulation loop combines scenario state, dynamics, terrain queries, control decisions, and rendering. My contribution sits primarily where the physics and control systems query terrain information and where terrain generation must remain consistent with the visual surface.

Development Process

The development process appears to have followed an incremental simulation-engineering workflow:

1. Understand the supplied simulator framework and existing dynamics.
2. Add a spherical terrain representation.
3. Connect terrain sampling to altitude, landing, and rendering behaviour.
4. Add interpolation and surface queries to reduce mismatch between visual and physical terrain.
5. Improve control and landing behaviour across multiple scenarios.
6. Add debug outputs and regression-style checks for terrain edge cases.

Testing Approach

Testing evidence in the local project supports the following test categories:

• Multiple descent and orbital scenarios.
• Terrain seam and pole continuity checks.
• Bilinear interpolation and derivative-style consistency checks.
• Comparison between rendered terrain peaks and physics terrain queries.
• Landing/crash status checks using terrain-aware altitude and velocity conditions.
• Terrain-aware descent-control and autopilot experimentation during descent scenarios.

Detailed numeric results require confirmation from the project owner before being presented publicly.

Results and Lessons Learned

The project demonstrates how small changes to a simulation model can cascade through rendering, physics, and control systems. Replacing a uniform surface with generated terrain requires consistent coordinate systems, careful interpolation, and targeted tests for edge cases such as seams and poles.

Key lessons:

• Visual correctness and physics correctness must be validated together.
• Terrain-aware altitude is essential for meaningful landing behaviour.
• Spherical coordinate systems introduce edge cases that planar assumptions can hide.
• Debug instrumentation is valuable when comparing rendered geometry with simulation queries.
• Autopilot behaviour depends strongly on the accuracy of the state estimates it receives.

Known Limitations

• The source code cannot be published because of the teaching-software licence restriction.
• No safe screenshots or videos were found as standalone assets in the local project folder.
• Public numeric performance claims are not included until confirmed from logs or rerun demonstrations.
• The showcase does not prove production readiness; it documents an educational engineering simulation project.

Future Improvements

• Capture clean screenshots of the running simulator that do not show source code, private paths, usernames, or IDE windows.
• Record a short demonstration video of terrain-aware descent and landing behaviour.
• Add a small results table after confirmed test runs.
• Add annotated architecture diagrams that remain conceptual and do not reveal implementation details.
• Include reflections on specific debugging cases once wording has been reviewed for assessment-solution safety.

Skills Demonstrated

• Simulation debugging
• C++ engineering in an existing codebase
• OpenGL visualization concepts
• Physics and numerical modelling
• Control-system reasoning
• Coordinate-system modelling
• Terrain representation and interpolation
• Test design for edge cases
• Technical communication under licensing constraints

Screenshots and Video Demonstrations

Media should be added only if it is captured from the running simulation and does not reveal source code or private information.

Suggested safe media:

• Simulator overview showing lander, Mars surface, and instruments.
• Terrain close-up showing non-uniform surface.
• Descent sequence with terrain-aware altitude.
• Successful landing or crash outcome screen.
• Short video of scenario setup, descent, and final outcome.

See assets/README.md for capture instructions.

Built With

• c++
• glsl
• opengl