Science

NASA picks Moon crew. The ML that got them there slaps.

NASA just named the next Artemis astronauts. But the selection process runs on terrain mapping ML that's genuinely wild engineering — the kind of stuff that would make your k8s cluster cry. Here's what's actually running under the hood.

NASA picks Moon crew. The ML that got them there slaps.

NASA named the next crew for the Artemis Moon programme this week. Cool, great, congrats to them. But here's the thing nobody's talking about: the machine learning stack that mapped their landing zones is some of the most interesting computer vision work happening anywhere right now.

Let me explain why you should care even if you've never written a line of aerospace code in your life.

The terrain mapping problem is basically your segmentation problem, but harder

Landing on the Moon sounds romantic. It's actually a data pipeline problem. NASA's Lunar Reconnaissance Orbiter has been dumping roughly 300TB of imaging data since 2009. Someone has to make sense of that.

The Lunar Terrain Vehicle and human landing system both need slope analysis, boulder density maps, and shadow depth estimates. You can't just eyeball a crater and go "yeah that looks fine". So they built ML models that classify surface features at roughly 1-meter resolution across the South Pole region.

The South Pole is where Artemis is landing. It's also where the sun sits permanently near the horizon, which means half your images are almost entirely shadows. Your model has to work in basically garbage lighting conditions.

Sound familiar? It should. It's the same problem you hit when you try to run object detection on user-uploaded phone photos taken in a dark bar. Except if you get it wrong, nobody dies in your case.

What they're actually running

The core workflow is built on convolutional neural networks trained on synthetic terrain data first, then fine-tuned on actual LRO imagery. The synthetic pre-training is the smart move here — you can generate infinite labeled craters in simulation before you ever touch real data.

NASA's SLOPE tool (Surface and LandscapE) processes elevation maps from the Lunar Orbiter Laser Altimeter. It's not glamorous. It's basically a giant raster processing job. But the ML layer on top is doing semantic segmentation to flag hazards — boulders above a certain height, slopes above 10 degrees, permanently shadowed regions where ice might make ground unstable.

They're also running ensemble models. Multiple predictions per patch, majority vote. Classic stuff. The kind of thing you'd do in a Kaggle competition. Except the stakes are somewhat different than winning a $1000 prize.

Back in 2021 I almost shipped terrain analysis code for a mapping startup

We had about $40k MRR and were pitching construction companies on automated site surveys. Our model was doing slope detection from drone imagery. We used FastAI on top of PyTorch, trained on maybe 8000 labeled images a contractor helped us annotate.

We got to 91% accuracy and thought we were done. Client ran it on a rainy-day dataset. Dropped to 67%. We hadn't trained on wet soil texture at all. Lost the contract. Cost us roughly $2400/month recurring.

NASA's not making that mistake. Their validation sets are specifically adversarial — worst-case lighting, worst-case sensor noise. That's the lesson.

Why this matters for stuff you're building

The techniques here aren't rocket science. Literally, they're just CV engineering done right. Synthetic data pre-training. Adversarial validation. Ensemble outputs for high-stakes predictions. Shadow-robust normalization before inference.

If you're building anything where your model's gonna see real-world distribution shift — medical images, satellite data, security cameras, industrial inspection — this is the playbook. NASA's using it to keep humans alive. You're probably using it to flag spam.

But same tools. Same failure modes. Different consequences if you skip the adversarial test set.

Ship carefully out there.

OPEN IN REEDL_ FEED →← Back to feed