Space

Schiaparelli Mars lander crashed because it thought it was below ground

Artist impression of the Schiaparelli module before deploying its  parachute
Artist impression of the Schiaparelli module before deploying its  parachute
View 1 Image
Artist impression of the Schiaparelli module before deploying its  parachute
1/1
Artist impression of the Schiaparelli module before deploying its  parachute

ESA has identified the malfunction that caused the unmanned ExoMars Schiaparelli Mars lander to jettison its parachute and shut down its landing engines prematurely, causing it to crash and explode on the surface of the Red Planet. According to the space agency, it was due to the navigation system being overloaded, so it not only thought it was on the ground, but beneath it.

Since the loss of the Schiaparelli probe on October 19, ESA has been carrying out an extensive investigation of the accident to identify the causes. This is intended not only a postmortem, but also as a way of improving design and procedures for the ESA/Roscosmos ExoMars 2020 mission, which will aim to place a rover on Mars. As part of this inquiry, the space agency has been studying the telemetry data sent from Schiaparelli to the Trace Gas Orbiter (TGO) mothership, which entered Mars orbit on the same day.

According to the investigators, separation from the TGO, approach to Mars, and atmospheric entry went as planned with the parachute deploying at an altitude of 12 km (75 mi) and a speed of 1,730 km/h (1,075 mph), while the heat shield jettisoned at an altitude of 7.8 km (4.9 mi).

During the parachute descent, the navigation system's radar Doppler altimeter kept an accurate track of altitude, but the Inertial Measurement Unit (IMU), which tracks the rotation rate of the lander as it descends, measured a too high rotation for about one second. This "saturated" the IMU by going beyond its measurement parameters and caused the navigation system to misinterpret its data and conclude that the lander was not only on the ground, but below ground level.

Due to this mix up, Schiaparelli jettisoned its parachute 3.7 km (2.3 mi) above the surface and fired its thrusters for three or four seconds instead of the planned 30. The end result was that the probe dropped 2,000 to 4,000 m (6,500 to 13,000 ft) before it hit the ground. ESA says these conclusions have been verified by computer simulations. But there was an ironic twist in Schiaparelli's last moments.

In an interview with the BBC World Service, an ESA spokesman said telemetry indicated that during the last seconds as it plummeted, the lander activated its weather station and started transmitting images back to mission control on Earth. He went on to say the data could still be in the probe's computer banks – assuming that they survived the crash and explosion.

"This is still a very preliminary conclusion of our technical investigations," says David Parker, ESA's Director of Human Spaceflight and Robotic Exploration. "The full picture will be provided in early 2017 by the future report of an external independent inquiry board, which is now being set up, as requested by ESA's Director General, under the chairmanship of ESA's Inspector General. But we will have learned much from Schiaparelli that will directly contribute to the second ExoMars mission being developed with our international partners for launch in 2020."

Source: ESA

13 comments
robf228
The sentence "This 'saturated' the IMU by going beyond its measurement parameters and caused the navigation system to misinterpret its data and conclude that the lander was not only on the ground, but below ground level." is computer talk for saying that they overflowed a signed integer in the control program and suddenly went from the maximum positive number to the maximum negative number. Control system programmers often use integers instead of floating point as integer math is much faster, but does have consequences when you don't allow for the full range of values. They are trying to save face with the above explanation instead of saying it was a stupid programming error. I've seen the same thing in industrial systems control programming.
KrisMclean
The old twelve-oh-two alarm strikes again but no Neil Armstrong to take over this time.
Deres
This is madness. First, in normal languages, we can say that this is a bug ... The program was insufficiently protected against an internal failure. Secondly, this is very similar to the bug in ARIANE 501 that lead to its destruction ...
Fritz
Now it´s below ground - Measurement data are right now ;)
Aross
Testing, Testing, Testing. This is obviously another example of arrogance by the software development team not doing enough and a wide enough range of testing.
Rocky Stefano
You don't let one component decide the entire fate of a system. Any competent system designer will tell you that. This just points to failure on the QA team.
esar
You could probably cure world hunger with the money they just wasted smashing that thing into another planet, but it wouldn't be as sexy, would it.
rpark
...expensive glitch.
GlassHalfEmpty
@Rocky Stefano How's lack of backup components failure of QA team? Now, failure of that one component is on QA team, I give you that. -QA guy.
Grunchy
I'm sure there's a similar phenomenon behind Tesla cars going berserk on autopilot. Sometimes when your computer 'goes dead' (becomes overloaded) it's busy churning away on its memory, "garbage collecting". That's because it forgot to prioritize landing safely. In pilot training they teach you, most important thing is to always be flying the airplane.