Stick the Landing

Stay on Target

I’ve recently spent a decent amount of time (in between move-prep and traveling) noodling on a new project that has lived in my head for a while: a moon lander visualization.

The new lunar lander page shows simple landing physics (basic gravity + thrust), along with some pre-planned burns over real lunar terrain data. This started off as a straightforward animation of a descent trajectory over a sphere where you use the arrow-keys and spacebar to thrust the lander in different directions on a descent trajectory, and ended up as an auto-burn-guidance planner with optional manual burn planning for a soft landing on a south pole crater built from 5-meter Lunar Reconaissance Orbiter (LRO) data. Classic.

This post might get a bit unwieldy, so here’s an overview: Map data first (DEM source, and mini-visual of the region we’re landing in), then lander guidance, which includes toy model, sim dynamics, auto burn-planning, and the simple search/optimization algorithm used in auto burn-planning.

Map Data

A really easy way to show terrain in a 3D plot or interactive visual is by using a Digital Elevation Map (DEM). At a super fundamental level, this is just a grid of values representing height/elevation of terrain per-pixel parameterized in some form of X/Y coordinate. For terrain, this could literally just be a lat-lon grid where the value in each grid cell is a height in meters. Thus, the size of the cells (i.e. size of lat/lon grid point spacing) determines the resolution of the map, since one pixel is used to plot each point.

For this visual, I tried using some pretty coarse data initially, like 100meter/pixel elevation maps. This obviously is not satisfying for actual landings, because we’re going to use a lander model that is smaller than 100meters in footprint. I started looking for the highest resolution data I could find, and eventually found some 5meter/pixel elevation data from the Laser Altimeter instrument aboard LRO (full source data here, described in Barker et al., Planetary & Space Science 203 (2021) 105119). The tiff image on that page contains DEM data for a +/-100km box surrounding the lunar south pole, with the pole itself at the center pixel.

I had claude-code read the tiff file into array data and plot it using threejs into an interactive viewer:

You can drag to orbit and scroll to zoom. Since we are looking at a pretty small slice of the surface, relative to the diameter of the moon, the terrain here is visualized as a curved mesh centered at the south pole. Its useful to mess around with this to get a rough sense of what real lunar terrain is like. This DEM gets shrunk a bit (down to a 36km window of detailed DEM data), and is used by the lander simulation we’re discussing next.

Lander Guidance

Lander Model

The lander model is a claude-code-generated glb file, intended to look like an arbitrary rocket with some legs. Properties are summarized in the table below.

$m_{\text{dry}}$	$2000$	kg
$m_f(0)$	$700$	kg
$T_{\max}$	$16$	kN
$I_{sp}$	$311$	s

Touchdown is triggered in the simulation by a circle encapsulating the landing legs intersecting the terrain. We sample 5 points on this circle and do a simple point intersection check to verify touchdown.

Dynamics

The simulation dynamics are pretty simple: spherical gravity and thrust act on the lander. The reference frame we’re using is moon-centered and inertial. There is no rotational attitude dynamics here, desired attitude is achieved instantaneously (but subject to kinematic rate-limiting) based on burn direction or user input. We paramaterize attitude in a local-vertical local-horizontal frame, derived from the position vector and a fixed nominal descent-plane normal $\hat n_0$ at each timestep:

$$\hat u_v=\frac{\mathbf r}{\lVert\mathbf r\rVert},\qquad \hat u_d=\frac{\hat n_0\times\hat u_v}{\lVert\hat n_0\times\hat u_v\rVert},\qquad \hat u_c=\hat u_v\times\hat u_d$$

Pitch $\theta$ is analogous to aircraft pitch, and points the thruster in the orbital descent plane, while yaw $\psi$ points the thruster out of the descent plane. We’re ignoring roll since this does not really matter for the burn placement and simplified simulation here. Roll is most relevant if you want to add attitude constraints like “crew must be able to see the lunar surface” or “roll to hit some specific thermal attitude.”

$$\hat u(\theta,\psi)=\cos\psi\,\bigl(\cos\theta\,\hat u_v+\sin\theta\,\hat u_d\bigr)+\sin\psi\,\hat u_c$$

Throttle $\tau$ represents fraction of max thrust applied, and total mass $m=m_{\text{dry}}+m_f$. The overall equations of motion are

$$\dot{\mathbf r}=\mathbf v,\qquad \dot{\mathbf v}=-\frac{\mu}{\lVert\mathbf r\rVert^{3}}\,\mathbf r +\frac{\tau\,T_{\max}}{m}\,\hat u(\theta,\psi),\qquad \dot m_f=-\frac{\tau\,T_{\max}}{I_{sp}\,g_0}$$

subject to bounded throttle and slew rates, since attitude is a rate-limited kinematic input:

$$\tau\in[0,1],\qquad \lvert\dot\theta\rvert\le\dot\theta_{\max},\qquad \lvert\dot\psi\rvert\le\dot\psi_{\max}$$

The landing gate looks at position over pad, lateral velocity, and the following off-vertical angle:

$$\phi_{\text{tilt}}=\arccos\!\left(\cos\theta\cos\psi\right)$$

symbol	value
$\mu$	$4.9028695\times10^{12}$	m³/s²
$R_{\text{moon}}$	$1{,}737{,}400$	m
$\dot\theta_{\max}$	$1.2$	rad/s
$\dot\psi_{\max}$	$0.35$	rad/s

The auto-planner

The simulation contains a simple onboard auto-burn-planner to populate a default set of burns that lands the spacecraft at an arbitrary target zone. We’re adopting a two-burn descent approach, parameterised by two constant-attitude, full-throttle arcs separated by a ballistic coast.

$$\mathbf p=\bigl[d_1,\ \theta_1,\ \psi_1,\ d_c,\ \theta_2,\ \psi_2,\ d_2\bigr]\in\mathbb R^{7}, \qquad T=d_1+d_c+d_2$$ $$\bigl(\tau,\theta,\psi\bigr)(t)= \begin{cases} (1,\ \theta_1,\ \psi_1) & t_0\le t<t_0+d_1\\[2pt] (0,\ 0,\ 0) & t_0+d_1\le t<t_0+d_1+d_c\\[2pt] (1,\ \theta_2,\ \psi_2) & t_0+d_1+d_c\le t<t_0+T \end{cases}$$

The target for burn planning is a handover box at $h^\star=150$ m AGL descending at $\dot h^\star=-8$ m/s, where simple closed-loop guidance takes over. Each candidate is scored on how close it gets, with the following cost on “closeness” in position and velocity to the handover target:

$$J(\mathbf p)= \left(\frac{h-h^\star}{25}\right)^{2} +\left(\frac{\lVert(s,c)\rVert}{50}\right)^{2} +\left(\frac{\dot h-\dot h^\star}{4}\right)^{2} +\left(\frac{\lVert(v_h,v_c)\rVert}{4}\right)^{2}$$

Running out of propellant and flying into the terrain are modeled as penalties. The ground penalty is set up to guide the solution towards being altitudes greater than 20m throughout flight, to provide buffer against hitting terrain.

$$\tilde J(\mathbf p)= \begin{cases} 10^{6} & m_f(T)\le 0\\[2pt] 10^{6}+\bigl(20-\min_t h(t)\bigr) & \min_t h(t)<20\ \mathrm{m}\\[2pt] J(\mathbf p) & \text{otherwise} \end{cases}$$

A candidate counts as feasible only if it arrives inside the box on every axis at once:

$$\mathcal B=\left\{ \begin{aligned} &\lvert h-h^\star\rvert<60\ \text{m}, \quad \lVert(s,c)\rVert<120\ \text{m},\\ &\lvert\dot h-\dot h^\star\rvert<6\ \text{m/s}, \quad \lVert(v_h,v_c)\rVert<6\ \text{m/s}, \quad m_f>0 \end{aligned} \right\}$$

Searching with Nelder–Mead

There is a lot of really interesting literature on solving the fuel optimal burn planning for descent guidance problem. The most famous papers and solutions in the public domain are generally tied to a direct technique known as ‘lossless convexification’ that is worth reading about. For this basic simulation where we’re making assumptions about number of burns and prescribing the shape of the solution, I’m using a simplex solver called Nelder-Mead.

Nelder-Mead is nice because there is no derivative calculation necessary, so we don’t need to worry about differentiability in our setup above. Every trajectory candidate is scored by running the simulation with a few hundred seconds of RK4 through a terrain lookup. The algorithm keeps eight guesses, representing vertices on the simplex. On each iteration, it finds the worst point/vertex, and steps it away from the rest: further away if that helped, back toward the “middle” of the 8 points if it didn’t, and if nothing helps, it pulls everything in around the best point so far. There is no promise the answer is globally optimal here, which is fine for this level of simple sim. Mathematically, each iterations possible actions look like this:

$$\bar{\mathbf x}=\frac1n\sum_i \mathbf x_i,\qquad \begin{aligned} \text{reflect}\quad &\mathbf x_r=\bar{\mathbf x}+\alpha(\bar{\mathbf x}-\mathbf x_{n+1})\\ \text{expand}\quad &\mathbf x_e=\bar{\mathbf x}+\gamma(\bar{\mathbf x}-\mathbf x_{n+1})\\ \text{contract}\quad &\mathbf x_c=\bar{\mathbf x}+\rho(\mathbf x_{n+1}-\bar{\mathbf x})\\ \text{shrink}\quad &\mathbf x_i\leftarrow \mathbf x_1+\sigma(\mathbf x_i-\mathbf x_1) \end{aligned}$$

with the standard coefficients $\alpha=1$, $\gamma=2$, $\rho=\tfrac12$, $\sigma=\tfrac12$, stopping once the simplex has collapsed to $\lvert f_{n+1}-f_1\rvert\le10^{-9}$ or after 220 iterations.

Among the candidates that survive the iterations, the winner is the one with most propelleant left:

$$\mathbf p^\star=\operatorname*{arg\,max}_{\mathbf p_k\in\mathcal F} m_f(T_k), \qquad \mathcal F=\{\mathbf p_k:\mathbf x(T_k)\in\mathcal B\}$$

Fly it

The simulator is at /lunar-lander/. Try messing around with manaul burns, and also try flying in keyboard-controlled “manual” mode, and see if you can hit the landing. There are two propagated trajectory lines leaving the lander: a blue line indicating where the lander is going if all thrusts stop instantaneously and the lander just propagates ballistically, and a green line indicating the lander’s trajectory on the current guidance/burn plan (with red arrows showing the direction of burns along the plan!). Its fun to mess around with the directions of potential burns, and see how that impacts the propagated lander trajectory. This is a neat way (in my opinion) to build some intuition on what burn directions and durations do to the actual physics of a descending vehicle in space.

All of the implementations here were done by claude, which was pretty neat to see. I provided guidance on what to solve and what the actual form of the dynamics and kinematics should be, and I reviewed the physics output from claude. This was a visual project I’ve wanted to do for a long time, so it was really cool to move quickly on it without getting caught up in web dev/visual details, and just focus on the physics, basic guidance, and map data. I’d like to add more advanced guidance planning to this at some point. In the meantime, don’t miss!