Ares-Route

Ares-Route
Jezero Crater highlighted in gray
Ares-Route pathfinding result across Jezero Crater, # 1
Ares-Route pathfinding result across Jezero Crater, # 2
Comparison between the direct path and the safer route generated by Ares-Route. Max slope of direct path is much higher, making it unsafe.
Mars 3D Interactive

Inspiration

The inspiration for Ares-Route came from NASA Space Apps and from thinking about how algorithms I had already learned, such as Dijkstra's algorithm and A*, could be applied to a real problem like rover navigation.

Most shortest-path examples use simple graphs or grids where moving between nodes has roughly the same cost. But on Mars, the shortest route is not necessarily the best route. A rover also has to consider terrain features such as steep slopes and obstacles.

That gave me the idea for Ares-Route: use real Martian terrain data and turn it into a graph that a pathfinding algorithm can use to find a more practical route.

What it does

Ares-Route is a Mars rover route planner that allows a user to select a starting point and destination on real Martian terrain and calculate a route between them.

The current version focuses on the Jezero Crater region and uses real HiRISE elevation data rather than a randomly generated or simulated map.

The terrain is converted into a grid of nodes. Each node represents a position on Mars and stores information such as its elevation. A* then searches through these nodes to find a route from the starting point to the destination.

For each node n, A* calculates:

$$ f(n) = g(n) + h(n) $$

where g(n) is the cost of the path travelled so far and h(n) is the estimated remaining distance to the destination.

Unlike Dijkstra's algorithm, which expands outward based only on the cost already travelled, A* also considers where the destination is. This helps guide the search toward the goal instead of exploring large parts of the terrain unnecessarily.

The cost of moving between two nodes also takes the terrain into account.

If two neighboring nodes have elevations z₁ and z₂, their elevation difference is:

$$ Δz = |z₂ - z₁| $$

If the horizontal distance between them is d, the slope angle can be estimated as:

$$ θ = tan⁻¹(Δz / d) $$

I can then increase the movement cost for steeper terrain:

$$ cost(u,v) = d(1 + λP(θ)) $$

Here, θ is the slope angle, P(θ) is the penalty applied to that slope, and λ controls how strongly slope affects the route.

That terrain cost becomes part of g(n), meaning a slightly longer but flatter path can have a lower total cost than a shorter path that crosses much steeper terrain.

How I built it

Ares-Route consists of three main parts: the frontend, terrain processing, and the routing algorithm.

The frontend was built using React and Vite. Cesium is used to display Mars as an interactive 3D globe and allows the user to interact with the Jezero Crater region and select locations for routing.

For the terrain data, I use a HiRISE Digital Terrain Model of Jezero Crater. The dataset contains real elevation values for the Martian surface.

Python scripts are used to process the original terrain files and extract the region needed by the route planner.

One of the most important parts of the project was converting the elevation raster into something A* could actually use.

I divide the terrain into a grid of nodes. Each node corresponds to a position in the elevation data and connects to nearby nodes. From the elevation difference and distance between neighboring nodes, I calculate the cost of travelling between them.

The backend routing algorithm is implemented in C++ using A*. A priority queue stores the nodes that still need to be explored, and the algorithm always continues from the node with the lowest estimated total cost.

Once the destination is reached, the algorithm reconstructs the route by following the parent of each node back toward the starting position.

The resulting path is then displayed directly on the Mars terrain in the frontend.

Challenges I ran into

One of the biggest challenges was figuring out how to convert an actual region of Mars into nodes that could be efficiently used by a graph algorithm.

The HiRISE data starts as a large elevation raster, not a graph. I had to decide how to sample that data, how far apart the nodes should be, which nodes should be connected, and how elevation differences should affect the cost of travelling between them.

Choosing the routing algorithm was another challenge.

Initially, I considered using Dijkstra's algorithm with terrain-based penalties added to the edge weights. That would work, but on a large terrain grid Dijkstra's algorithm can spend a lot of time exploring nodes that are far away from the destination.

A* made more sense because it still supports weighted movement costs while also using a heuristic to guide the search toward the destination. This let me keep the terrain penalties while making the search more focused.

Another difficult part was connecting all of the different coordinate systems.

The location selected on the Cesium globe has to correspond to the correct position inside the HiRISE terrain dataset. That required converting between geographic coordinates, the coordinate system used by the Mars dataset, and pixel rows and columns in the elevation raster.

Getting those systems to line up correctly was one of the more difficult parts of connecting the frontend to the backend.

Accomplishments that I'm proud of

One of my biggest accomplishments was getting A* to work on real Martian elevation data instead of a manually created or simulated grid.

The algorithm assigns higher costs to difficult terrain and can route around steep areas instead of simply following the shortest geometric path between the start and destination.

I was also able to get the route calculation to run in roughly 10–15 seconds for the regions I tested, even though the algorithm is searching through a large graph generated from real terrain data.

Another accomplishment was getting the entire system working together.

The project combines real HiRISE data, Python terrain preprocessing, graph generation, a C++ A* implementation, and a React/Cesium frontend.

Seeing the route produced by the algorithm appear directly over the actual Martian terrain was one of the most satisfying parts of the project.

What I learned

One of the biggest things I learned was that implementing A* itself is only one part of building a real route planner.

The harder problem is figuring out what the graph should actually represent.

Real terrain does not naturally come as nodes and edges. I had to decide how to convert millions of elevation measurements into a graph that was detailed enough to represent the terrain while still being efficient enough to search.

I also learned how important the cost function is.

A* does not automatically know that a steep hill is bad for a rover. That information has to be represented through the edge costs.

In my case, the total path cost can be thought of as the sum of all movement costs along the route:

$$ g(n) = Σ cost(u,v) $$

Each movement cost depends not only on distance, but also on the terrain between neighboring nodes.

I also learned a lot about working with Digital Terrain Models, coordinate transformations, Cesium, HiRISE datasets, and connecting geographic data to a traditional graph algorithm.

What's next for Ares-Route

One of the next features I want to add is terrain roughness.

Slope only measures how much elevation changes between points. A region could have a relatively small overall slope while still containing highly uneven or rocky terrain.

Adding a roughness penalty would allow Ares-Route to account for this.

Eventually, the terrain cost could combine several factors:

$$ cost(u,v) = distance + α × slope + β × roughness + γ × hazard $$

This would let the routing algorithm make more detailed decisions about which terrain is preferable.

I also want to expand Ares-Route beyond Jezero Crater.

Right now, the terrain dataset is fixed to one region. In the future, I want users to be able to select a landing site or region on Mars and load the corresponding terrain data automatically.

This would turn Ares-Route from a route planner for one section of Jezero into a more general system that could run the same terrain-processing and A* pipeline on different locations across Mars.

Longer term, I could also allow users to change the objective of the route, such as finding the shortest route, safest route, lowest-energy route, or a balance between multiple factors.