>The analysis reveals that the lander fully completed the entire planned deceleration process, slowing to the target speed of less than 1 m/s in a vertical position at an altitude of approximately 5 kms above the lunar surface.<p>Ouch.<p>What seemed to happened was<p>1. The probe descended normally.<p>2. Glided horizontally over a 3km deep cliff of a crater<p>3. Sensor suddenly gives large altitude change<p>4. Onboard computer sees the sensor value change is larger than expected, deduced the sensor is mis-reading, and filtered the (correct) value.<p>>as the lander was navigating to the planned landing site, the altitude measured by the onboard sensors rose sharply when it passed over a large cliff approximately 3 kms in elevation on the lunar surface, which was determined to be the rim of a crater. According to the analysis of the flight data, a larger-than-expected discrepancy occurred between the measured altitude value and the estimated altitude value set in advance. The onboard software determined in error that the cause of this discrepancy was an abnormal value reported by the sensor, and thereafter the altitude data measured by the sensor was intercepted. This filter function, designed to reject an altitude measurement having a large gap from the lander’s estimation, was included as a robust measure to maintain stable operation of the lander in the event of a hardware issue including an incorrect altitude measurement by the sensor.
Is there something like penetration testing for projects? i.e. a business unit that is working fulltime on identifying “what could possibly go wrong” in very complex projects.
>The most likely reason for the lander’s incorrect altitude estimation was that the software did not perform as expected.<p>"The software did not perform as expected" is now my official root cause analysis summary for all the things.