IMU saturation is an expected condition, especially in this type of extreme real-world environment. It's absolutely normal to temporarily saturate IMU sensors on drones during hard landings for example and saturation values are generally clear in the documentation. A large part of the difficulty in position and attitude estimators is in rejecting glitching or erroneous data.
From the description (specifically that the duration of the saturation was an issue), it would sound like the position estimator (most likely a kalman filter) did not reject or distrust saturation values properly and converged on a bad solution. It appears that any strategy in place to (for example) reset the estimator state if it diverged from more reliable sensors (such as the radar altimeter), failed or were not included. It would also appear that the case where the IMU saturated during descent for over 1 second was not properly tested, as they were able to reproduce the issue in simulation.
This must be disappointing for the ESA but at least it was found now 'in beta' rather than in the relatively more important next lander.
Whilst incredibly disappointing for ESA, this is unfortunately not their first IMU-failure rodeo.
An Ariane 5 launch back in 1996 [0] suffered a catstrophic failure after the inertial reference units gave bad data, and the flight control computer accepted it as gospel.
It is sad that they might have lost another platform due to a lack of appropriate range / saturation checking, especially as there was a radar altimeter onboard telling them they weren't underground.
Ariane is built by Airbus, Schiaparelli was built by Thales Alenia, two completely independent companies. Not sure why there's supposed to be a correlation, other than both were contracted by ESA.
Yes I'm aware of how ESA works and who built what. But I would have hoped the common connection would have greater instilled the need for checking for these sorts of errors, if the Schiaparelli incident is as blutack theorised.
I hesitate to speculate but the book I read that talked of Kalman filters and two people I know who messed with them said they are opaque and tricky to get right[1]. Hard to understand what the filter constants mean, and buggy software implementations 'sort of work' then break.
Nonsense, Kalman filters are well understood and widely used in spacecraft attitude dynamics and control systems. In fact, I'd argue that a Kalman filter is industry standard for that work. It's typical on teams doing GNC (guidance, navigation, and control) to have a PhD or two in control theory to make sure you get things right.
Most aerospace engineers with a GNC background know a lot about Kalmam filters.
IMU saturation is an expected condition, especially in this type of extreme real-world environment. It's absolutely normal to temporarily saturate IMU sensors on drones during hard landings for example and saturation values are generally clear in the documentation. A large part of the difficulty in position and attitude estimators is in rejecting glitching or erroneous data.
From the description (specifically that the duration of the saturation was an issue), it would sound like the position estimator (most likely a kalman filter) did not reject or distrust saturation values properly and converged on a bad solution. It appears that any strategy in place to (for example) reset the estimator state if it diverged from more reliable sensors (such as the radar altimeter), failed or were not included. It would also appear that the case where the IMU saturated during descent for over 1 second was not properly tested, as they were able to reproduce the issue in simulation.
This must be disappointing for the ESA but at least it was found now 'in beta' rather than in the relatively more important next lander.