Lunar Terrain Assistant

• 

  An image that somewhat represents the final ui of the project.

Inspiration

In 2035, a fragile lunar outpost must grow into a living city—without GPS, roads, or second chances. Every wrong turn costs time, power, and safety. I set out to build the routing brain that turns raw lunar maps into safe, energy-efficient paths for rovers and crews.

What it does

Fuses terrain data (slope, roughness, illumination, hazards) into a single, normalized cost map. Enforces mission constraints (max slope, darkness limits, no-go zones). Plans routes fast using A* (octile heuristic), returning an explainable path plus metrics (distance, cost proxy, nodes expanded).

How I built it

I designed the backend around three clear modules, matching operator workflow: io – Loaders for .npz and imagery; strict 2D shape checks; NaN/Inf sanitization; layer normalization so everything composes cleanly. planner – Cost fusion (weighted slope/roughness/illumination/hazards), constraint handling (soft/hard), A* with octile distance, and a metrics suite. service – FastAPI endpoint (/plan) that clamps inputs, runs the planner, and returns JSON including optional path_pixels for exact image overlays.

Challenges I ran into

Data quality & alignment – Reconciling mixed resolutions; guaranteeing identical shapes across layers; masking bad values without crashes. Explainability – Turning fused costs into outputs operators can trust; designing fields/flags for clear, debuggable reasoning. Image <-> grid mapping – Robustly converting grid paths to image pixel space (path -> path_pixels) for precise overlays.

Accomplishments that I proud of

A clean, testable architecture (io / planner / service) that made the system reliable and easy to extend. Rock-solid loaders that prevent shape mismatches and numeric edge-case failures. Constraint-aware planning with clear metrics and explainable outputs suitable for mission ops.

What I learned

Geospatial normalization is everything: consistent shapes/units unlock stable planning. Explainability drives trust: exposing dominant cost factors makes decisions defensible. APIs beat monoliths: a small, stable /plan contract let me iterate quickly and support any frontend. Plus, I deepened my web/service fundamentals (FastAPI, CORS, robust error handling) to better serve the backend.

What's next for Lunar Terrain Assistant

A variety of ideas, such as: Energy & vehicle models: Convert cost to Wh/m with slope/weight/load curves; surface “Estimated Energy” for each route. Dynamic replanning: Live updates when hazards/no-go areas change; smooth route transitions in the UI. Layer controls & legend: Toggle slope/roughness/shadow/hazards and color the route by the dominant driver and so on.

Built With

• python