At 2:15 he discusses how NASA was completely wrong about the surface of the asteroid based on their initial thermal inertia analysis. While I don't pretend to be an expert, it's stuff like this that really makes me doubt how much we really know about distant parts of the universe. This asteroid is so much closer to Earth than many galaxies and other objects scientists claim to know something about. Of course, science is all about being wrong, refining the model, trying again etc. but my default reaction to any claim made about age/size/composition/distance, is immediate skepticism for this reason.

Well, we're entering the golden age of space exploration right now, so let's see how that gap closes by the next decade or so.

"So they actually performed a software upgrade of on the spacecraft to give it optical navigation capabilities..."

God dammit. And here I have trouble getting software updates into a server I have full control over on Earth.

Sadly, most of us don't have the luxury of working in environment where (a) it's mandated that we set up a 1-for-1 test rig with the production infrastructure and (b) management will accept the answer "I need to test for all possible contingencies because failure is not an option."

(Most of us are writing code in an environment where failure is totally an option, as long as it's fast and restoration is quick ;) ).

Another part of the difficulty with updating servers is that updates are rather opaque. My own software on any given server is maybe 0.1% of all the software running on it (if even that). The other 99.9% is someone else's code: the operating system, the software runtime, the libraries, etc. So one doesn't really have a lot of insight into what is about to happen to the server without running a duplicate setup, which as you point out is pretty difficult to get right. I'm sure NASA has much more visibility into all the software that is running on their spacecraft.

While the abstractions is lesser for a spacecraft, I don't think any one is hand compiling or writing machine code directly. There will always be some abstraction layers.

While the requirement is there, often it falls through the cracks. A recent example is the wrong mapping of the Starliner thrusters. This wasn’t found until the simulator changed due to brownouts after it was already in orbit. Just by luck, the new simulator was of sufficient fidelity to catch the mapping error.

Had 1) they not missed the correct orbit due to a different issue and 2) not had to switch simulators it could have potentially collided with the space station.

So yes, the requirements are there but often not followed but luck was on our side

Then again NASA has a $22B budget.

The mission has a very small sliver of that budget. Trust me, there's no "NASA" that comes running when things go wrong: It's on the mission team to handle it.

Many large corporations have budgets in excess of that and still struggle with delivering solutions and software updates. Internally or externally.

Sure, but I was trying to cheer `moron4hire` up, who I assume has a lot fewer zeroes in their budget.

Yeah, I'm the only zero in the budget

Hell, I'd take a comma over some of those zeros!

And now optical navigation has been flight proven so it can be used on other missions.

Optical nav was flight proven a long time ago. For deep space (autonav, deep space 1), and for mars landers.

> Blowing a raspberry in the surface of the asteroid

Classic Manley

From TFV:

"In order to be able to perform the landing they needed to update their software to give it optical navigation abilities ..."

Imagine being part of the team that had to do that, fast, chop-chop, or else their billion dollar space mission would fail miserably.

"Oh, you only need us to implement vision. Ok, no biggie."

I assume it was more a case of "We have an algorithm that successfully lands the craft 80% of the time, but we would like it to be 99% of the time, so get to working on it..."

Usually its 99.7% percent of the time: three standard deviations.