Hopefully they have upgraded software to just gracefully attempt a landing, and hopefully they won't be off course.
Hopefully they have upgraded software to just gracefully attempt a landing, and hopefully they won't be off course.
With new one, they did couple of things. Larger area to be selected for landing based on camera input. Escape sequence to more achievable points, if something like this happens again. They increased the tolerance from 10 degrees to 25 degrees and guessing fixed the bug in code. They also did some smoothening of the trajectory for different phases to make it more continuous. I think they also made other changes in engines among other things and a whole host of testing.
[1] https://www.kallmorris.com/columns/tyranny-of-the-rocket-equ...
I did like seeing the live images captured during descent, I also hope those get made into a video and posted online.
Looking forward to the rover deployment too.
While we think "this cannot ever happen" in a lot of cases it can, in ways you did not consider. Both for good and bad
Edit: here, at least, is a mention of the thing with her daughter in a Google Blog article: https://blog.google/products/maps/margaret-hamilton-apollo-1...
Turns out it just flew over a cliff edge that actually does that. Completely by accident.
It was in there.
A lot.
This can't even come from the software engineering, but must be some kind of managerial failure (e.g. we're short on time, but have to report great progress to my boss, so skip this scenario).
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.
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!
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.
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.
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.
This wouldn't be the first time that a mission failed due to embarrassing failures in basic software practices (eg Starliner's initial software bugs emerging from a lack of integrated testing).
Main difference is that you aren't triggering a billion overly sensitive nationalistic folks when you point out similar embarrassing errors in most other countries' programs. Eg the time NASA lost a probe due to miscommunicated units, the Apollo 1 disaster, the space shuttle disasters, or the tape around the wiring in Starliner, which was intended to be fire retardant actually turning out to be flammable...
Hell, Japan's Hakuto-R also failed because the software's error detection was buggy, and they openly admitted as much without any bluster about how no one but other people with experience writing code for space probes can criticize them.
What do you mean by "they haven't officially straight-up announced the issue." ? They did so - several times actually.
They've given out vague explanations such as a software glitch, while holding the detailed post-mortem back claiming the obviously absurd excuse of national security concerns.
This is counter to how they typically operate as well as how most other agencies/companies around the world operate these days, where they at least explain what went wrong. eg Hakuto-R's team explaining that their flight software thought the radar altimeter was malfunctioning when it wasn't, causing it to rely on the IMU and thus it thought the surface was much higher than it actually was.
Chairman S Somanath has given three main reasons that led to the crash-landing of the Vikram lander on September 6, 2019 just minutes before the touchdown.
The ISRO chairman said, “The primary issues were: One, we had five engines which were used to reduce the velocity (called retardation). These engines developed higher thrust. When such a higher thrust was happening, the errors on account of this differential were accumulated over some period. All the errors accumulated, which was slightly higher than what we expected.
When it (lander) started to turn very fast, its ability to turn was limited by the software because we never expected such high rates to come. This was the second issue.
The third reason for failure was the small site of 500m x 500m for landing of the lander.”
Rectifying those mistakes this time, the Isro chairman said, “This time we have kept an area of 4.2 km (along the track) x 2.5 km (width) for the landing site. So, it can land anywhere, so it doesn’t limit you to target a specific point.”
Somanath said “instead of a success-based design, Isro has this time opted for a failure-based design” and focused on what all can fail and how to protect it and ensure a successful landing.
“We looked at sensor failure, engine failure, algorithm failure, calculation failure. So, there are different failure scenarios calculated and programmed inside. We did new test beds for simulation, which was not there last time. This was to look at various failure scenarios,” he explained.
The ISRO chief said the Vikram now has additional solar panels on other surfaces to ensure that it generates power no matter how it lands.
Or, are you saying that it's expected that the mission did not count with this scenario, and that future missions don't need to account for that either?
Or some new ones I've heard kicked around:
- Gravy Seals - 101st Chairborn - Chair Force pilots
...And so on...
The latter two are just ribbing jokes about the Air Force, from the other branches usually. My old (Army) boss used to tell me to 'take off your air force gloves' if he ever saw me with my hands in my pockets.
"Chair Force" does sound like something they would say about armchair generals. No?
Hell, you can run a few thousand simulators for every scenario you can think of during descent, including lost of burner, propellant leak, etc, and then during the actual descent a chip get burnt because of a stray cosmic ray. There will still be somebody on HN call you out for cutting corner.