Congrats to all of the team at ISRO. Assuming the software development for these is non trivial; Its interesting that with the last mission(per Scott Manly) was designed to always select a spot(or more precisely a trajectory) and try hit it.
What made them make that decision? Was it like "lets be as precise as we can because we want to get to the spot X because X is special" and thus "Lets let the software always compensate for any errors to get to X". I am assuming that even at this point they tested the software for extreme conditions. It is most likely that once this assumption was made the Software was built that way, i.e: "Lets test the Software can always correct for any issues to get to X with feedback(like thrust)". It trades off Safety for Accuracy(to hit X).
This time the idea was "Lets select a trajectory to X" but this time "We will let the software prioritize safety(altitude, speed and heading) to be within norm once we start descending towards X". And additionally "Not make any corrections if we are somehow too far off X if it exceeds safety limits". It trades off Accuracy(to hit X) for Safety.
Complete wild-ass guess: safe landing spots are hard to find, they knew X to be a larger region safe to land in (so small errors wouldn't matter), and didn't at the time have the more complex subsystem to find safe landing spots (!= X) on the fly based on where the lander happens to go.
Scott Manly has a video on why he thinks the last one failed. It sounds like their landing software didn't have "oh crap, we're way off course, just land wherever". It only had the happy path of "fly to here and land", so when it switched to the landing phase it tried valiently (including flying upside down) to try to fly back to the landing zone, but the landing zone was much further than fuel supplies allowed.
Hopefully they have upgraded software to just gracefully attempt a landing, and hopefully they won't be off course.
Yes, this seems to be one of the issues. Here is a talk by ISRO Chairman S Somanath at Indian Institute of Science (IISc) about the same and what they added. He goes into details of what went wrong. These are based on my limited understanding. One of the thrusters had an issue and got activated for longer (or may be activation profile of thrusters at its extreme's were different from modeled). They had a narrow landing region selected as final position (even one possible point). So now their control system tried to correct this but the algorithm had a bug and that caused it to be further delayed. At this point the correction required, i.e; thrusters to be activated, was outside the tolerance levels. So finally ended up with 50m/s vertical speed. https://www.youtube.com/watch?v=fZ2sNRP1opY&t=1440s
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.
If anything they seem to have overcorrected for this. This landing path stopped with a near hover at around 800m, then a prolonged hover at 150m while the lander scoped the situation, then an extremely slow descent that allowed for corrections the whole way down. Very impressive.
Yes, it was a very conservative landing trajectory. But it is very, very difficult to get a hoverslam right the first time, or the second, or the third...
I did like seeing the live images captured during descent, I also hope those get made into a video and posted online.
If they have the fuel available, may as well be very conservative. Either burn the fuel on descent or have it sit in the tank forever on the lunar surface.
Could you elaborate how that applies here? Communication is out of the question - there's nothing the people on the ground can correct. And the lander apparently failed because it tried to navigate its way back to the designated landing site.
I really ought to dig up a reference for this, but there are strong echoes from the past here. Margaret Hamilton (who coined the term 'software engineering' and can be seen standing next to a tall pile of green bar printouts of the Apollo software) brought her daughter to work one weekend during the Apollo program and she (daughter) fiddled with the buttons and caused an error condition. Hamilton, based on this, argued that the software should account for the possibility of mistakes. Management's view was that the highly-trained astronauts wouldn't make mistakes. In time, Hamilton prevailed, and was proven correct.
The recent japanese lander had something like this happen a while back. The altitude radar noticed a sudden 2km drop in ground-level, and the system assumed it was broken and stopped using that data.
Turns out it just flew over a cliff edge that actually does that. Completely by accident.
In general software development it's usually not a problem if your program crashes, then you can fix the bug and run it again. If the thing that crashes is a lunar lander however, you should put a bit more effort into covering all the eventualities...
They also had an issue with the thrust gradient it could only do it increments in 20% which was too much of a change this one was finer which allowed for better control authority.
Incredibly Kerbal vibe. I think something like that happened to me when using MechJeb. (it even has a "land whenever" feature, which it was too late to use at that point)
That is just a testament to the incredible work of the Squad team. The Indian landing is not similar to Kerbal, rather, Kerbal is very very similar to the real experience. Amazing.
Not considering such a basic error condition seems like a gross omission.
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).
This is the software engineering version of "I am very badass", passing judgement on software at the cutting edge of science, while sitting at home writing React code.
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 code for something that flies into space is not nearly as easy as you think it is. Perhaps the next time you write a comment you could first develop the software which you're complaining about first. I'm sure it would be a trivial task for someone of your stature :)
You are saying "gross omission" like this is some Python script, like they are skipping the else clause for a condition. Imagine trying to land a plane that is flying at Mach 2, with no direct control, only a video feed with 4 seconds resolution, a bunch of sensors and a tank of fuel for retrograde burn to slow you down. Can you even fathom the number of scenarios that can happen. Your application may have 1 happy path and 2 sad path. Here you get only 1 happy path, a few not so happy path where your probe land sideway or just roll down a crater; and the rest of them are every other combinations of your probe's orientation and speed vector and collision location.
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.
That's probably why they haven't officially straight-up announced the issue.
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.
Especially impressive when taken into account that ISRO couldn't achieve the soft-landing with Chandrayaan-2 four years ago.
One of the big things they changed with this lander compared to Chandrayaan-2 was to increase the landing zone from 500mx500m to 4000mx4000m and adding more sensors and cameras to help the computer find a good landing site.
For those who didn't watch live, there was another hover phase (0 m/s descent) at 150m above the lunar surface before final commit.
The whole hover and look around thing was super impressive to me. That choice to spend mass on fuel for such maneuvers vs science instruments seems to always go to science in NASA debates and we end up with "either it will land here, or it will die." :-)
Great outcome and I look forward to the pictures sent back by the rover!
A very large number of missions to other planets have failed because they crashed on the planet. Thus anyone who is serious about getting a mission to a different planet will put a lot of effort into the landing system. The fuel burn is cheap compared to a crash landing on the moon (as Russia just had a couple days ago). The above is even at NASA, they have done a lot of complex landing systems over the years.
Most missions have several different scientific systems on board. If any one fails well the others still make the mission a partial success. If the landing system fails they all become a failure.
> was to increase the landing zone from 500mx500m to 4000mx4000m
Can you elaborate on this? Presumably it could land...anywhere on the moon, so what exactly does it mean to increase the landing zone? What determines where it can or can't land?
There is a target area we want to land in order to investigate certain terrain or other POI's near the target.
It obviously can't land on mountains and certain rocky or steep terrain. They know its limitations. These limitations determine where it can or can't land.
During target selection they will find an adaquet place on the surface that meets the criteria.
By increasing from 500m^2 to 4000m^2 they need to find a larger area that meets those same needs.
This also helps during the actual landing. It can aim anywhere inside that 4000m^2 area instead of being limited to just a 500m^2 area.
> It is of special interest to scientists because of the occurrence of water ice in permanently shadowed areas around it. The lunar south pole region features craters that are unique in that the near-constant sunlight does not reach their interior. Such craters are cold traps that contain a fossil record of hydrogen, water ice, and other volatiles dating from the early Solar System
Chandrayaan 3 landed at around 69 degrees south latitude which isn't far enough south to access the permanently shadowed craters where large ice deposits might occur (and the Pragyan rover uses solar panels for power).
I haven't read specific reasons for choosing that site, but we have never landed that far south, and it will be interesting to see what differences (if any) there are from the more central latitudes, which is a good enough reason on its own.
Moon undergoes extreme temperature fluctuations from day to night, resulting in boil off. There are spots on the South Pole that never see sunlight, so it’s our best bet for finding large deposits of water (as ice).
The ice would also be pretty close to the Moon's peaks of eternal light[1] where you don't have to have your solar panels spend half of every month in darkness. So basically where you'd want to live on the Moon if you had to pick somewhere.
It's 69° south, so it's not so much the south pole as the polar region. For reference, the major landmass of Antarctica starts around that point on Earth. McMurdo Station is at around 78° South.
Currently in a live server with others watching and it's a lot of fun. I happen to know many people working in the space industry, and a lot of great engineers come from India. Very happy and excited for India and its people. Goodluck!
If I read correctly, this is now the most watched live video on YouTube! Congratulations to India and the team on this fantastic feat of an achievement.
Congratulations to everyone involved. This is amazing. India has come so far in its space program. Leaps and bounds. It’s astonishing to witness. While SpaceX has the look - Chandrayaan has the function. Now get Jeb back home!!
Readit News
What made them make that decision? Was it like "lets be as precise as we can because we want to get to the spot X because X is special" and thus "Lets let the software always compensate for any errors to get to X". I am assuming that even at this point they tested the software for extreme conditions. It is most likely that once this assumption was made the Software was built that way, i.e: "Lets test the Software can always correct for any issues to get to X with feedback(like thrust)". It trades off Safety for Accuracy(to hit X).
This time the idea was "Lets select a trajectory to X" but this time "We will let the software prioritize safety(altitude, speed and heading) to be within norm once we start descending towards X". And additionally "Not make any corrections if we are somehow too far off X if it exceeds safety limits". It trades off Accuracy(to hit X) for Safety.
Video has captions
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.
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
Turns out it just flew over a cliff edge that actually does that. Completely by accident.
It was in there.
A lot.
Deleted Comment
Dead Comment
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.
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.
Deleted Comment
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.
One of the big things they changed with this lander compared to Chandrayaan-2 was to increase the landing zone from 500mx500m to 4000mx4000m and adding more sensors and cameras to help the computer find a good landing site.
For those who didn't watch live, there was another hover phase (0 m/s descent) at 150m above the lunar surface before final commit.
Great outcome and I look forward to the pictures sent back by the rover!
Most missions have several different scientific systems on board. If any one fails well the others still make the mission a partial success. If the landing system fails they all become a failure.
Can you elaborate on this? Presumably it could land...anywhere on the moon, so what exactly does it mean to increase the landing zone? What determines where it can or can't land?
It obviously can't land on mountains and certain rocky or steep terrain. They know its limitations. These limitations determine where it can or can't land.
During target selection they will find an adaquet place on the surface that meets the criteria.
By increasing from 500m^2 to 4000m^2 they need to find a larger area that meets those same needs.
This also helps during the actual landing. It can aim anywhere inside that 4000m^2 area instead of being limited to just a 500m^2 area.
I'm also curious
- Why the south pole of the moon? does it have an added significance vs other locations on the moon?
- Is a landing on the south pole more difficult to achieve? Seems so according to this article: https://www.reuters.com/science/why-are-space-agencies-racin...
> It is of special interest to scientists because of the occurrence of water ice in permanently shadowed areas around it. The lunar south pole region features craters that are unique in that the near-constant sunlight does not reach their interior. Such craters are cold traps that contain a fossil record of hydrogen, water ice, and other volatiles dating from the early Solar System
I haven't read specific reasons for choosing that site, but we have never landed that far south, and it will be interesting to see what differences (if any) there are from the more central latitudes, which is a good enough reason on its own.
https://en.wikipedia.org/wiki/Peak_of_eternal_light
Very well done, India. Respect!
The point was about we could be doing so much more with the resources we have. That is what I got out of it - and I agree.
edit: lets goo!!!
Which is disappointing. India should have their own video sharing/livestream platform.