4 ms·

> seems like such a gross omission. Almost all space mission code only ever has the so-called 'happy path'. We rely on extremely tight mechanical and aerospace

> seems like such a gross omission. Almost all space mission code only ever has the so-called 'happy path'. We rely on extremely tight mechanical and aerospace engineering tolerances to achieve that happy path. The Hubble Space Telescope's primary mirror grinding was off by a matter of micrometres, and resulted in blurry images. Consider all the Mars rovers. Imagine some wind gust threw the descending module off course, or a retro-rocket failed because of vibrations. Writing code for space missions isn't like writing a CRUD app. Developers can't just teleport to a space probe millions to billions of kilometres away to rectify errors and debug running code on the fly. For the record, the 'failure path' for Apollo 11 was to get the US President to announce to the world that the two astronauts would likely be marooned on the Moon. Apollo 13 very nearly failed, too.

astrange 3y ago
If you write the failure path, then you also have to ensure it doesn't fire when there wasn't really a failure and do unnecessary heroics. Same reason you can't program a self driving car to save a person by sacrificing a squirrel. It's just going to run over the squirrel when it didn't need to.
ianburrell 3y ago
Apollo 1 landed on the "failure path". Neil Armstrong noticed that the target was a boulder field, took manual control, discovered his new spot had a crater, and finally found level ground. They had low fuel but not dangerously low. If Apollo 11 had followed the "happy path", they would have crashed and died. Hubble was also the "failure path". The main mirror was flawed and had to be corrected.
The_Colonel 3y ago
When saying "we", do you mean you write code for the space missions? Writing only happy path code as a standard practice in the space sector seems quite absurd. You won't ever achieve absolute precision and errors do happen, yet it seems like systems recover most of the time. Recently, the antenna of Voyager 2 got misaligned, but it is expected to recover from that. That was only the last problem it encountered over its very long mission - and it managed to recover from all of those so far!
- jvm___ 3y ago
  Voyager 2 is already recovered, they waited until it was at the best possible (but still wrong orientation) and just yelled at it so that it heard, even with it being misaligned.
  - stall84 3y ago
    Voyager's programming just brings joy to me to think about.. I mean it's the system as a whole (of course) .. but the fact that they've been capable of flying through the environments they have been, using points of light to align themselves, among other things.. for decades .. and recover from incidents.. is just something I marvel at.
  - jacobwilliamroy 3y ago
    Wow I can't believe I didn't hear about this. It was all over the news when they broke it, so I figured it would be just as widely reported when they fixed it. It's been almost 3 weeks.
    - SamBam 3y ago
      There was definitely a prominent NYTimes story when it was fixed, that's how I heard about it.
- abecedarius 3y ago
  There was a NASA project to start developing flight software that's smarter in this kind of way, the Remote Agent. It got an award after flying, but if they continued that line of research I haven't heard about it. https://ntrs.nasa.gov/api/citations/20000116204/downloads/20000116204.pdf https://ntrs.nasa.gov/api/citations/20000116204/downloads/20...
  - deleted 3y ago
    [deleted]
- numpad0 3y ago
  Trying to hand roll a super robust AI software usually backfires. Emergency mode triggers right in the middle of the happy path and ruins your uh, a day if you're lucky. They know that, even I kinda know that.
taneq 3y ago
That can't still be the case these days, can it? Extremely tight mechanical and engineering tolerances are very expensive compared with merely 'very very' tight tolerances, and I'd imagine the difference between the two can be bridged with more intelligent software in place of "gyroscope + clock + maybe PID loop"?
- bregma 3y ago
  The classic hardware engineering response of "we'll just fix it in software". Turns out fixing things in software is even more expensive because it's just so easy to make changes that a combinatoric number of changes sneak in.
  - taneq 3y ago
    Ohhhh yes. I've been on the receiving end of this one. Designing a system which can accommodate higher tolerances on some hardware components through software controls is one thing. Being handed a poorly performing piece of hardware and told to "just fix it in software" is quite another.
- fidotron 3y ago
  Yeah, this reads like two people defining happy path subtly differently: one is saying the happy path is anything within acceptable strictly defined mission parameters and tolerances, the other thinks it is the sequence of steps that is expected to successfully execute the mission without ever encountering an exceptional situation (which is the conventional software view of the term), but there are exceptional situations which may be covered in the specification of the mission and so “on the happy path”. In the case the system strays outside mission success parameters then aborting could make sense. The question there looks to be if the success parameters were defined too narrowly - it sounds like an error in specification that prioritizes landing in the required area over the possibility of landing at all.

astrange 3y ago

If you write the failure path, then you also have to ensure it doesn't fire when there wasn't really a failure and do unnecessary heroics. Same reason you can't program a self driving car to save a person by sacrificing a squirrel. It's just going to run over the squirrel when it didn't need to.

ianburrell 3y ago

Apollo 1 landed on the "failure path". Neil Armstrong noticed that the target was a boulder field, took manual control, discovered his new spot had a crater, and finally found level ground. They had low fuel but not dangerously low. If Apollo 11 had followed the "happy path", they would have crashed and died. Hubble was also the "failure path". The main mirror was flawed and had to be corrected.

The_Colonel 3y ago

When saying "we", do you mean you write code for the space missions? Writing only happy path code as a standard practice in the space sector seems quite absurd. You won't ever achieve absolute precision and errors do happen, yet it seems like systems recover most of the time. Recently, the antenna of Voyager 2 got misaligned, but it is expected to recover from that. That was only the last problem it encountered over its very long mission - and it managed to recover from all of those so far!

jvm___ 3y ago
Voyager 2 is already recovered, they waited until it was at the best possible (but still wrong orientation) and just yelled at it so that it heard, even with it being misaligned.
- stall84 3y ago
  Voyager's programming just brings joy to me to think about.. I mean it's the system as a whole (of course) .. but the fact that they've been capable of flying through the environments they have been, using points of light to align themselves, among other things.. for decades .. and recover from incidents.. is just something I marvel at.
- jacobwilliamroy 3y ago
  Wow I can't believe I didn't hear about this. It was all over the news when they broke it, so I figured it would be just as widely reported when they fixed it. It's been almost 3 weeks.
  - SamBam 3y ago
    There was definitely a prominent NYTimes story when it was fixed, that's how I heard about it.
abecedarius 3y ago
There was a NASA project to start developing flight software that's smarter in this kind of way, the Remote Agent. It got an award after flying, but if they continued that line of research I haven't heard about it. https://ntrs.nasa.gov/api/citations/20000116204/downloads/20000116204.pdf https://ntrs.nasa.gov/api/citations/20000116204/downloads/20...
- deleted 3y ago
  [deleted]
numpad0 3y ago
Trying to hand roll a super robust AI software usually backfires. Emergency mode triggers right in the middle of the happy path and ruins your uh, a day if you're lucky. They know that, even I kinda know that.

taneq 3y ago

That can't still be the case these days, can it? Extremely tight mechanical and engineering tolerances are very expensive compared with merely 'very very' tight tolerances, and I'd imagine the difference between the two can be bridged with more intelligent software in place of "gyroscope + clock + maybe PID loop"?

bregma 3y ago
The classic hardware engineering response of "we'll just fix it in software". Turns out fixing things in software is even more expensive because it's just so easy to make changes that a combinatoric number of changes sneak in.
- taneq 3y ago
  Ohhhh yes. I've been on the receiving end of this one. Designing a system which can accommodate higher tolerances on some hardware components through software controls is one thing. Being handed a poorly performing piece of hardware and told to "just fix it in software" is quite another.
fidotron 3y ago
Yeah, this reads like two people defining happy path subtly differently: one is saying the happy path is anything within acceptable strictly defined mission parameters and tolerances, the other thinks it is the sequence of steps that is expected to successfully execute the mission without ever encountering an exceptional situation (which is the conventional software view of the term), but there are exceptional situations which may be covered in the specification of the mission and so “on the happy path”. In the case the system strays outside mission success parameters then aborting could make sense. The question there looks to be if the success parameters were defined too narrowly - it sounds like an error in specification that prioritizes landing in the required area over the possibility of landing at all.