ExoMars - Schiaparelli landing Options

[stevesliva]

ESA has told us that they have simulated the fault and it matches what happened. OK.... but...
The problem is that the 'glitch' makes as much sense as the Italian Space Agency's story a few days ago.
And there is a very good reason for that. We have no insight into the EDL software design used by the ESA designers and programmers
As an RTOS programmer for decades (VxWorks, also used by MER, Pathfinder, Odyssey, etc) , sanity checks are part of the landscape.
For example: when the craft is at an altitude of 4 Km and in the next second it thinks it is 'on the ground', one of the background sanity checks would have said 'we just accelerated to 14 Million KM/hr -- ignore the readings, wait until they get back in 'range', and do it again. ....

Ariane V initial launch? It would have failed your sanity checks. Nonetheless he software commanded a wild course correction. I just don't know how many layers of "wait and see" you're supposed to put in there though. Ariane V may well have had plenty of "wait and see" but not amount of it was going to undo the overflow. You can reject a certain amount of garbage data, but eventually that might be all you have left.

[siravan]

There is a limit of the number of such sanity checks you can explicitly implement in a control system. You get a huge number of rules because you need to consider different combinations of inputs. Instead, since the time of Apollo, most (all?) s/c control systems have used Kalman filter or one of its descendants. The basic idea is that each piece of input comes with a measure of its accuracy that affects how it is incorporated into a state vector. It seems that for Schiaparelli, the control system assigned a higher accuracy to IMU inputs than to the radar readings and therefore rejects radar inputs in favor of the wrong state vector generated from IMU.

[nogal]

ESA has just announced that the Schiaparelli landing investigation has been completed. A report summary can be downloaded from this page.

Here is an excerpt:

Around three minutes after atmospheric entry the parachute deployed, but the module experienced unexpected high rotation rates. This resulted in a brief 'saturation' – where the expected measurement range is exceeded – of the Inertial Measurement Unit, which measures the lander's rotation rate.

The saturation resulted in a large attitude estimation error by the guidance, navigation and control system software. The incorrect attitude estimate, when combined with the later radar measurements, resulted in the computer calculating that it was below ground level.

This resulted in the early release of the parachute and back-shell, a brief firing of the thrusters for only 3 sec instead of 30 sec, and the activation of the on-ground system as if Schiaparelli had landed. The surface science package returned one housekeeping data packet before the signal was lost.

Fernando

[mcaplinger]

A report summary can be downloaded from this page.

Wow. Basically there were several issues, but there was one parameter that was supposed to be 15 msec and was set to some unstated larger value and nobody caught it.

It should be borne in mind that if the persistence time of the IMU saturation flag would have been 15
ms the landing would probably have been successful, in which case the other root causes would
probably never have been identified.

That's gotta hurt.

[Explorer1]

It always does. Just like Mars Observer and the metric mixup, or Galileo and the HGA, or Genesis accelerators being upside down, or (for ESA) the Huygens Channel A. Nothing to do but live with it and learn from mistakes.

[mcaplinger]

Just like Mars Observer and the metric mixup...

That's Mars Climate Orbiter. The Mars Observer problem was a lot more subtle (as was the Galileo problem.)

[Explorer1]

Oops, yes. Looking at the report, I note that they used the observations Oppy took of its heat shield during their analysis. Good use of ground truth and previous experience to build on for the future.
Also from page 18, for something this thread discussed:

SIB members confirmed that the cancelled subsonic High Altitude Drop Test would not have revealed the underestimated supersonic dynamic behaviour of the parachute at Mach 2

[PDP8E]

As mentioned upstream in the thread, a few overriding sanity checks can and should be layered on top of the real-time Kalman NAV computer in an EXEC manner.
(underlines are mine)

(ESA) Recommendation 05 – Robust and reliable sanity checks shall be implemented in the on-board S/W to
increase the robustness of the design, which could be, but not limited to :
- Check on attitude
- Check on altitude sign (altitude cannot be negative).
- Check on vertical acceleration during terminal descent and landing (cannot be higher than gravity).
- Check altitude magnitude change (it cannot change from 3.7 Km to a negative value in one second).
- Check wrt pre-flight timeline (altitude or acceleration profile vs time) to check consistency of measurements

Let's get this done and see a working 2020 lander on the surface of Mars!