Schiaparelli investigation update; crash site in color from HiRISE

ESA issued an update on the Schiaparelli landing investigation today, identifying a problem reading from an inertial measurement unit as the proximate cause of the crash. The landing had proceeded nominally through the deployment of the parachute and release of the heat shield, but then the problem with the gyroscope made Schiaparelli think it had already landed. ESA's statement elaborates:

As Schiaparelli descended under its parachute, its radar Doppler altimeter functioned correctly and the measurements were included in the guidance, navigation and control system. However, saturation – maximum measurement – of the Inertial Measurement Unit (IMU) had occurred shortly after the parachute deployment. The IMU measures the rotation rates of the vehicle. Its output was generally as predicted except for this event, which persisted for about one second – longer than would be expected.

When merged into the navigation system, the erroneous information generated an estimated altitude that was negative – that is, below ground level. This in turn successively triggered a premature release of the parachute and the backshell, a brief firing of the braking thrusters and finally activation of the on-ground systems as if Schiaparelli had already landed. In reality, the vehicle was still at an altitude of around 3.7 km.

This behaviour has been clearly reproduced in computer simulations of the control system’s response to the erroneous information.

The two have been converted into an anaglyph, but I looked at it and couldn't deduce much except that the landing site is flat.

I worked with the second image in order to produce high-resolution color views of the lander and parachute. Usually, when you work with HiRISE data, it's best to work with map-projected images because then north is up and the scale is fixed and known. But map projection, like any other rotation and scaling operation on digital images, blurs the original data somewhat. So when you're interested with features on the scale of individual pixels, it's worth it to work with the "non-map" data, which represents the pixels as they came off the camera detector. Here is the best I could do at revealing detail at the Schiaparelli landing site. You can see the impact crater that it made. I measure it at 11 pixels across -- as the original data have a resolution of 27.8 centimeters per pixel, that's just about exactly 3 meters.

NASA / JPL / UA / Emily Lakdawalla

Schiaparelli backshell and parachute landing location from HiRISE in color

The parachute and backshell as seen on November 1, 2016, about two weeks after the crash. The parachute is bright white and slightly folded; the conical shape of the backshell is visible. Image scale is 27.8 cm/pixel; the whole image is 234 meters square. Inset at lower left shows the same image enlarged by a factor of 5, preserving original HiRISE pixels.

NASA / JPL / UA / Emily Lakdawalla

Schiaparelli lander crash site from HiRISE in color

The landing site as seen on November 1, 2016, about two weeks after the crash. Color and grayscale data have been combined to emphasize the shape of the impact crater, dark ejecta from the impact/explosion, and bright fragments of the lander. Image scale is 27.8 cm/pixel; the whole image is 234 meters square.

NASA / JPL / UA / Emily Lakdawalla

Schiaparelli crash site (300% enlarged detail)

Original HiRISE data has been enlarged with nearest-neighbor sampling, so individual pixel edges are still visible. Original pixels are 27.8 centimeters across.

Comments:

gmalone: 11/23/2016 05:11 CST

Seems that a 'reality check' software function could prevent some future events like what happened to Schiaparelli. Such a function would've instantly concluded that you don't go from a high'ish altitude to below ground in 1 second, thus check again! Also, trapping negative altitude (i.e. below ground) could've been another trigger to check altitude again. Another method could be to have a nominal descent profile that is compared with instrument readings. A sudden major deviation from the profile would, like above, trigger the reality-check function. Deploying the landing thrusters, legs and configuration 1 second after being at 3.7km altitude should not have been an easy possibility with adequate software logic, no?

How can saturation (maximum measurement) of the Inertial Measurement Unit (IMU), which measures the rotation rates of the vehicle, be indicative of a negative altitude?
How can a high rotation rate of the vehicle be interpreted as having landed?

Torbjörn Larsson: 11/27/2016 05:29 CST

@Haruki Chou: I wouldn't know the details, but the IMU data was not in itself indicative of a negative altitude, how could saturation indicate anything else than precisely that? However the feed forward of that data - feed forward apparently because any saturation event was erroneously believed to be shorter - was interpreted as negative altitude by other software. "When merged into the navigation system, the erroneous information generated an estimated altitude ...".
I agree with previous suggestions, but would add that a time based filter or any filter at all could be improved based on the observed outcome.
Since many space projects can now be reprogrammed on the fly, this shouldn't be a huge problem to fix with years remaining before use.

Torbjörn Larsson: 11/27/2016 05:47 CST

On another tack, it is curious how a problem recognized in old scifi continues to hunt us. To my knowledge Heinlein wrote at least one early story where "gyros has tumbled" saturation caused a problem.
Speaking of gyros/navigation vs software, I remember someone seemingly in the know discussing how engineer use of vector algebra inserted extraneous singularities that could be avoided instead of trapped. The suggestion was to try using quaternions, which are continuous over a sphere as opposed to diverse vector based mappings. You could likely finesse software with tricks like that for decades...

rdkelly: 11/27/2016 10:40 CST

What folk *should* have learned by now: it's *hard* to make everything work perfectly when a bazillion miles from home. Science sensors you just record - What You See is What You Get. But sensors related to spacecraft function or health should always be reality-checked.There should be a Plan B for any faliled sensor. Where possible, mission-critical sensors (landing !) should have backups.

Tim: 11/28/2016 05:37 CST

We now know why this incident happened, which is a good thing, but this is the same landing system that the European Space Agency wants to use to put the ExoMars rover on the surface of Mars. Another error like this one would lead to a disastrous and expensive mistake.
Before the ExoMars rover is sent to Mars, I'd like to see a second Schiaparelli trial lander sent to Mars to test out this landing technology before it's used for the really important mission.

Les: 11/29/2016 03:14 CST

What puzzles me is the way the parachute and the back-shell end up together, given that they're from opposite ends of the craft and, surely, the parachute must drift more, even in the tenuous Martian atmosphere?

Josh P: 11/29/2016 09:09 CST

I wonder if it would help if they did some "citizen science" and actually released all the source code so us professional programmers can do some code reviews and help find issues in the code before it goes into space!? Good idea or bad idea?

Tim: 11/29/2016 03:55 CST

@Josh P, I think that's a good and constructive idea because the way that open source software and operating systems are administered means that anyone can identify and report coding bugs for fixing so there are more people to help out and solve things (this post comes from a Linux and LibreOffice user).
In other news, the European Space Agency's The Trace Gas Orbiter has returned some good initial black and white photographs of the surface of Mars. Europe does orbiters rather well but landers are a different matter...(so far).

aeropapa17: 12/03/2016 04:39 CST

Opening up the software to the public could have some real benefits but also a serious drawback: It could take a huge amount of time to review the suggestions and pick out the good ones. I know, as a software developer, that when reviewing someone else's code, there are many many times that you spot a bug but it turns out to be correctly coded. The ESA would have to review an awful lot of "bug" reports which, in the end, turn out to be perfectly OK.
Certainly, the ESA will fix this particular bug and test the heck out of the fix but you can never anticipate them all in advance.