ESA: European Mars Lander Crash Caused By 1-Second Glitch (space.com)

An anonymous reader quotes a report from Space.com: The European Space Agency (ESA) on Nov. 23 said its Schiaparelli lander's crash landing on Mars on Oct. 19 followed an unexplained saturation of its inertial measurement unit (IMU), which delivered bad data to the lander's computer and forced a premature release of its parachute. Polluted by the IMU data, the lander's computer apparently thought it had either already landed or was just about to land. The parachute system was released, the braking thrusters were fired only briefly and the on-ground systems were activated. Instead of being on the ground, Schiaparelli was still 2.3 miles (3.7 kilometers) above the Mars surface. It crashed, but not before delivering what ESA officials say is a wealth of data on entry into the Mars atmosphere, the functioning and release of the heat shield and the deployment of the parachute -- all of which went according to plan. In its Nov. 23 statement, ESA said the saturation reading from Schiaparelli's inertial measurement unit lasted only a second but was enough to play havoc with the navigation system. ESA said the sequence of events "has been clearly reproduced in computer simulations of the control system's response to the erroneous information." ESA's director of human spaceflight and robotic exploration, David Parker, said in a statement that ExoMars teams are still sifting through the voluminous data harvest from the Schiaparelli mission, and that an external, independent board of inquiry, now being created, would release a final report in early 2017.

Comments

This never happened to me before...

[hyades1]

Man, if I had a nickel for every time some kind of sensory saturation forced a premature release...

Re:This never happened to me before...

[rsmith-mac]

Man, if I had a nickel for every time some kind of sensory saturation forced a premature release...

Then you'd still be broke. This is Slashdot; you're not fooling anyone.

Re:This never happened to me before...

[silentcoder]

He never said there was another person involved. He's just complaining about never managing to make it to the end of the pornhub clip.

Kalman filter

[little1973]

https://en.wikipedia.org/wiki/...

How in hell did they test their Kalman filter to allow such bad data to reach the decision logic? (I assume they used one.)

Re:Kalman filter

[gTsiros]

I find it more weird that *one* sensor misbehaving lead to the entire mission failing.

I have more robustness in my thrust measuring rig made of wood beams and zipties :|

They didn't learn the lesson

[LordHighExecutioner]

Overflows and bad data problems happened to ESA before.

Re:They didn't learn the lesson

[thegarbz]

To be fair, few people did. Multiple cases of overflows and bad data problems have occurred and still continue to occur not just in space programs around the world but in other industries too.

Filter or not

[evanh]

When the altitude stops changing for a whole second the filter is going to have to be a long one! And that ain't desirable for responsive control.

The real question is how could the sensory processor have overloaded in the first place? My money is on simple [b]code bloat[/b]. Ie: They used a bunch of generic libraries that use further libraries that use further libraries that use further libraries that use further libraries that use further libraries ...

Re:Filter or not

[Solandri]

Dynamic range. Sensors which can measure from 0 - 100 g's are not as sensitive in the 0-1 g range you may be more concerned about. So you instead opt for accelerometers which max out at 10 g's and try to deal with the periods of max acceleration in software.

A more elegant solution is to use both the sensitive accelerometer and an accelerometer with a greater max threshold. That way you keep the higher max limit without giving up low-gain sensitivity. But spacecraft tend to be both weight- and budget-constrained...

More troubling to me was that there wasn't some basic sanity checking going on. Like a calculation that says "3 seconds ago I was at 4 km high. Now I think I'm on the ground. Does it make sense that I could've traveled that far in that little time? No? Then the instruments saying I'm on the ground are probably wonky, and I should give other instruments a higher priority in calculating my altitude for a bit." Same way I write my code (and spreadsheets) to calculate important numbers two, three, or sometimes even four different ways to make sure they all agree before proceeding to act on it.

What the?

[NewtonsLaw]

So they didn't correlate the IMU data with ranging radar or even barometric altitude information so as to avoid this?

I know weight and volume are at a premium on such craft but a barometric sensor (even one capable of operating in Mars's rarefied atmosphere, is the size of a thumbnail and weighs just a fraction of a gram.

Sigh!

Re:What the?

[thegarbz]

even barometric altitude information

I'm interested to know how you calibrate your barometric altitude information, and even more so what vacuum followed by a sudden atmospheric entry will do to such a sensor.

If I'm going to take a guess I'd so no, an instrument capable in operating that range of pressures, temperatures, vibration, etc is not the size of a thumbnail weighing a gram.

Oops

[wonkey_monkey]

Should've used metric seconds.

Re:Ariane 5

[Anonymous Coward]

> ...control software spat an Ada stack trace over a line...

Eh, no. The failure of the INS's control software caused the INS to send diagnostic data (rather than sensor data) to the control systems, which then did what they _thought_ they were being commanded to do.

None of the code in the system was modified in flight.