When merged into the navigation system, the erroneous information generated an estimated altitude that was negative – that is, below ground level.
I wonder if this was a sensor fusion problem or a pedestrian integer overflow. When merged into the navigation system, the erroneous information generated an estimated altitude that was negative – that is, below ground level.
I wonder if this was a sensor fusion problem or a pedestrian integer overflow.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.
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.
[0] https://en.wikipedia.org/wiki/Cluster_(spacecraft)#Launch_fa...
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.
https://www.thalesgroup.com/en/worldwide/aerospace/topaxyz-i...
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.
[1] Convinced me to use something else.
Most aerospace engineers with a GNC background know a lot about Kalmam filters.
Examples: http://www.techbriefs.com/component/content/article/ntb/webc...
Once the model is so simple, there are many ways to program it wrongly.
To compare, NASA's Mars Climate Orbiter
https://en.wikipedia.org/wiki/Mars_Climate_Orbiter
burned close to Mars in 1998 because the "ground based computer" programmed per contract by Lockheed used lbf·s values instead of agreed N·s values.
https://en.wikipedia.org/wiki/Pound_(force)
The values generated on the ground were 4.45 times bigger.
Space missions are risky.
But it's good that they made such an experiment before sending the whole rover, planned for 2020.