> the lunar landing of the probe using image processing to guide the final approach

Anyone building precision weapons has gotten fairly good at this.

Weapons guidance systems get to be simpler in many ways.

If you've seen some of the Lunar or Martian landing videos, you'll notice that it's very hard to tell the scale. Especially on the Moon, the lack of atmosphere to disturb the surface makes it fractal-like, which probably really messes with the CV algorithm. It'd work fine when high up, but as you approach for landing, it would probably struggle, especially for, say, estimating how far away the surface is.

Don't they use radar altimeters to get altitude? You don't need to rely only on image processing. You can even pull off stereo using a single camera since you are moving and know the altitude at every point.

They definitely combine several sensors to get a proper height reading, but as we've seen with the American and Japanese landers, getting good readings from the sensors, properly accounting for all factors that might affect sensor readings and being able to properly handle sensor disagreements is quite challenging.

Better call my man... Kalman.

https://en.wikipedia.org/wiki/Kalman_filter

For distance during landing I would be thinking a spatially maximally distributed array of quartz-shielded, thermally-supported laser TOF sensors along nominal extremities, but that's just because they're familiar to me, small, power-efficient, highly linear, relatively accurate, and cheap. Unsure if the IC physics assumptions work in non-atmospheric conditions. Perhaps the output can be re-scaled to obtain cheap and accurate enough readings.

A non-dilettante with an actual physics degree would clearly be desirable ;)

The apollo guidance system was one of the first production deployments of Kalman filters. Here's the source code: https://github.com/chrislgarry/Apollo-11/blob/master/Luminar... (it was used for star navigation, not sure about the lander).

A kalman filter wouldn't account for say, the issue that hit the HAKUTO-R lander, where because the reading on the radar altimeter changed too rapidly, the computer assumed it was faulty, or the IM-1 lander, where they initially had a lot of trouble with altitude sensing (in part because they forgot to remove the covers from the laser rangefinders), managed to work around it, and then failed to fully sense and cancel out the lateral velocity, causing it to skid along the surface, snap a leg and tip over.

The first sounds like bad assumption (hard fault limit).

The second sounds like bad process leading to bad input, at which point it becomes garbage in, garbage out. The workaround was untested and insufficient.

While you are of course correct the filter will not fix these, none of these are the fault of the filter, they are all human process issues that are firmly out of scope.

LIDAR/RADAR performance weren't issues with last two attempts. SLIM had a thruster kaboom, IM-1 had human eye safety mechanism wired incorrectly.

This one seem to use scaled down Soyuz capsule as reentry vehicle. They must have reused a lot of proven hardware and software unlike those.

The problem with RADAR on the moon is there's an unknown amount of dust between you and the reflective surface.

Apparently cameras also have issues because the lack of atmosphere means everything is high contrast.

So basically, you don't actually know your altitude, and your visual systems may not be reliable.

It is a lot more difficult in space, since you don't have the atmosphere to steer for free and because fuel margins get very expensive. Being familiar with these image processing systems, I could see it being a significant challenge.

Here's an article on DIMES, the system JPL developed in the early 2000s to address the problem of estimating horizontal velocity for the Mars landers:

https://robotics.jpl.nasa.gov/media/documents/DIMES-ai-space...

Martian winds make this more important there than on the Moon. The DIMES system integrates radar, visual images, and IMUs. They did not have a dedicated Doppler radar for horizontal velocity, for technical and cost reasons it was not workable.

From the introduction:

> Some of the challenges were subtler — and one in particular was subtle enough that it wasn’t fully appreciated until mission development was well underway.

> This was the challenge of martian winds. How to detect and compensate for them? In the worst-case scenario, they could tip the vehicle over in the final stages of descent such that the powered thrust intended to eliminate downward velocity might actually drive the platform sideways and down into the surface beyond the safety envelope of the airbag cushions.

> This article tells the story of how this late-understood challenge was addressed successfully — and, as it turned out, critically, for Spirit.

The system was improved and re-fielded for the successor missions - I think it goes under the name LVS now. One reference appears to be here: https://www-robotics.jpl.nasa.gov/what-we-do/applications/la...

ALHAT/LVS problem seems to be the overly broad requirements, it's overengineered (hence the modularization in LVS) which led to long delays during the development. For comparison, Chang'e 3 TRN solution was dead simple, it was roughly speaking a webcam combined with the specific lighting angle during the landing. Then they iterated on it in subsequent missions, creating a decent system that was less dumb and restrictive than the original.

Interesting that its mostly image/ video processing, which isn't a 'traditional' guidance/control approach.