Help Shape the Future of Space Exploration

Join The Planetary Society Now  arrow.png

Join our eNewsletter for updates & action alerts

    Please leave this field empty
Blogs
Facebook Twitter Email RSS AddThis

Headshot of Emily Lakdawalla

Schiaparelli investigation update; crash site in color from HiRISE

Posted By Emily Lakdawalla

23-11-2016 11:28 CST

Topics: pretty pictures, pics of spacecraft in space, amateur image processing, mission status, ExoMars TGO, Mars, Mars Reconnaissance Orbiter

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.

Meanwhile, ExoMars Trace Gas Orbiter is operating its science instruments for the first time this week. I can't wait to see the first CASSIS images!

The two Mars Reconnaissance Orbiter HiRISE images of the landing site taken after the crash are now available in their calibrated form. Together they form a stereo pair covering the landing site.

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.

Schiaparelli backshell and parachute landing location from HiRISE in color

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.
Schiaparelli lander crash site from HiRISE in color

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.
Schiaparelli crash site (300% enlarged detail)

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.

 
See other posts from November 2016

 

Read more blog entries about: pretty pictures, pics of spacecraft in space, amateur image processing, mission status, ExoMars TGO, Mars, Mars Reconnaissance Orbiter

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?

Bern: 11/24/2016 04:46 CST

Totally agree with previous comment that is truly appalling software writing not to check your value hasnt gone below zero.

Haruki Chou: 11/24/2016 07:39 CST

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.

Leave a Comment:

You must be logged in to submit a comment. Log in now.

Space in Images

Pretty pictures and
awe-inspiring science.

See More

Join The Planetary Society

Let’s explore the cosmos together!

Become a Member

Connect With Us

Facebook, Twitter, YouTube and more…
Continue the conversation with our online community!