6 ms·

> the erroneous information generated an estimated altitude that was negative – that is, below ground level. Kind of sad to see that computers nowadays still

> the erroneous information generated an estimated altitude that was negative – that is, below ground level. Kind of sad to see that computers nowadays still lack what we call common sense. I mean the machine received negative altimeter data but if it had been able to just look around, it could have seen that this data was erroneous. Hell, considering the descent profile was carefully prepared, the computer should also have noticed that it was way too early to reach the ground and should have concluded that something was wrong with the altitude measure.

ygra 10y ago
Well, common sense in a way would be enabled with assertions. But even if you know that you cannot be below ground, how would you recover? Your sensors clearly tell you that you're below ground, so what is the course of action? You have no way of knowing where you are, you just know that you don't know. It doesn't really change anything in the outcome. Sure, maybe you could go from altitude measurements to time measurements and most likely still leave a crater since it's not exact enough (there's a reason for the internal measurement instead of simpler ways, after all). It would also require you to anticipate the malfunction in which case you already know that things like that could happen, in which case you'd likely determine how it could happen and how to avoid it and continue having useful data. Sounds to me like a better solution than trying to recover without data.
- grondilu 10y ago
  From the article: > 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. It would have been better to do nothing, in the hope that the altimeter data will resume to reasonable values, especially since the article mentions that the error is not supposed to last long: > Its output was generally as predicted except for this event, which persisted for about one second – longer than would be expected.
- WalterBright 10y ago
  There are several ways. First off, ignore the erroneous data. Then, estimate the altitude by other methods. As you mentioned, one way would be to integrate time and velocity. All inputs and outputs should be run through sanity checks, with a plan for when they go wrong. Essentially, when you've got a system that can't be fixed, plan for failure of each and every component (in isolation).
  - homero 10y ago
    Cars do this, you can kill many sensors and an engine will still limp even with misfires. I guess consulting Bosch isn't an option tho
    - ethbro 10y ago
      Some cars do this. My friend's Honda literally stopped combustion when his battery died while driving (no, I have no idea how, but that was the diagnosis). In contrast, I've limped my Miata along on alternator-only when the battery wouldn't hold a charge. Note: feathering the gas at a stop with brakes and clutch depressed to keep your spark from dying is an "interesting" experience.
      - dotancohen 10y ago
        At a stop pull the tranny out of gear and activate the parking brake. More fun is driving a vehicle with no clutch: stalling at every stop and starting the motor in first gear, and shifting without clutching. I had to do that in my '83 280ZX in its last days.
      - dotancohen 10y ago
        At a stop pull the tranny out of gea and activate the parking brake. More fun is driving a vehicle with no clutch: stalling at every stop and starting the motor in first gear, and shifting without clutching. I had to do that in my '83 280ZX in its last days.
    - matheweis 10y ago
      Not necessarily very well; my cars' mass airflow sensor went out a few months back... the performance was all over the place and sudden engine stalls were frequent. You could kill the engine just by accelerating quickly when it was cold. ... and that was a single sensor out.
- acqq 10y ago
  > your sensors clearly tell you that you're below ground They weren't telling that. As far as I understood, the sensors were fully right, the software just hasn't expected the rotation to last "so long" -- the whole second, so it calculated the result wrong ("negative height") by incorrectly processing these multiple (in time) for their model unexpected inputs.
- blutack 10y ago
  For context, the lander did have a radar altimeter. A radar altimeter has maximum distance from ground above which it will not establish a lock. If radar altimeter had never had a lock, either the radar altimeter has faulted in a way you can't detect, or you are above the lock range for your radar altimeter. If the radar altimeter had locked, you have a very accurate measurement of height above ground.
  - moioci 10y ago
    That's the surprising thing, though: "its radar Doppler altimeter functioned correctly and the measurements were included in the guidance, navigation and control system. "
    - pbhjpbhj 10y ago
      And presumably mission time was in use too? Presumably they know to the (milli?)second when the lander should touchdown, at least from the point where the lander starts its descent. Time of flight send like a very strong, reliable signal?
- dean 10y ago
  Better to discard obviously bad data altogether. The system certainly should not act on that data, as seems to have been the case here.
  - mediocrejoker 10y ago
    I would argue that at 1700 km/h, even not acting is an action. The decision to do nothing is still a decision.
simosx 10y ago
It is an interesting problem and looks like a big extension to developing fault-tolerant software. That is, how do you develop fault-tolerant software and at the same time have logic that would reject some sensor readings if they deviate too much from up-to-now readings? How many readings would you reject in the hope that fresher readings would be better?
- grondilu 10y ago
  It's indeed a difficult problem and I'm not really surprised it's not solved by ESA even if they are probably extremely competent. I doubt anyone care about my opinion, but since you ask, I do notice that simulation seems to be a big part of their development. So I'm sure there has to be a way to use some kind of an evolutionary algorithm for creating descent procedures.
  - NikolaeVarius 10y ago
    I think this testing WAS that testing scenario to create better descent procedures
- baq 10y ago
  looks like a machine learning approach would be interesting to consider. not that i believe anybody will allow such an approach on a extraterrestial probe, but training a model to classify sensor data as trustworthy or not could lead to some advancement here and perhaps in other areas.
- dkbrk 10y ago
  Actually, the solution to this sort of problem is well understood: it's a combination of Bayesian probability theory and decision theory. First, you define a Bayesian model for the system. This includes discrete propositions such as "sensor X is not working" as well as things like a description how the craft's velocity, angular velocity and displacement at t0 can evolve to at t1, expressed as a continuous probability distribution. This takes into account the prior distribution for altitude. All sensor inputs have distributions -- generally gaussian -- describing what values they could read given the "actual" value they're supposed to be measuring if they're not broken and giving completely erroneous results. Feeding sensor inputs into this model as they're received to produces a posterior describing the craft's physical state probabilistically. Dimensions which are relevant only insofar as they affect knowledge of the craft's physical state (such as "sensor X is not working") are marginalised out. Secondly, you define a utility function. This function takes some definite physical state of the craft's and a possible control output, and describes how "good" the outcome of that is. Then you choose the control outputs that maximise the expected utility, integrated over the craft's posterior state distribution. If sensor X started giving results unlikely under the time evolution model, P(Sensor X is not working|inputs,control signals,prior information) would start to increase very rapidly. If, somewhow, this probability was only 0.5, but the sensor was showing results that the craft was below the ground, the decision process would "decide" that "if sensor X is telling the truth, firing the landing thrusters will not lead to successful mission completion; if sensor X is lying it is too early to fire the landing thrusters" and not fire the thrusters. In reality, such a situation is absurd because sensor X showing the craft below the ground would lead to an extremely high probability for "sensor X is not working". However, the point is that even under extremely pathological conditions decision theory will continue to give reasonable results. One important consequence to note is that the sensor readings and state estimate do not matter in themselves, only as inputs to the decision theory process. To answer your specific question: if sensor X is determined to be, with high probability, faulty, its inputs aren't "discarded" per se, but will have a very small contribution to the state estimate. If sensor X is only believed to be faulty with moderate probability, both possibilities are considered and the optimal decision will be made given the information available and utility function. For more information, I recommend reading chapters 13 and 14 of "Probability Theory: The Logic of Science" by E.T. Jaynes [0]. [0]: http://www.med.mcgill.ca/epidemiology/hanley/bios601/GaussianModel/JaynesProbabilityTheory.pdf http://www.med.mcgill.ca/epidemiology/hanley/bios601/Gaussia...
rsp1984 10y ago
It's a question of proper sensor fusion. The way it's typically done is with some form of bayesian prior + a robust estimator that can handle the case where your sensors give you disagreeing evidence of the true state. So you have a prediction function that takes as input your previous estimated state and some form of "common sense" that's hard-coded or learned and which outputs a prediction of the current state. Then you look at your current measurements and if one of it disagrees to much it gets downweighted or outright discarded. The updated estimate is then computed from the prediction and the current measurements.
- grondilu 10y ago
  Neat. There actually is a wikipedia entry about sensor fusion: https://en.wikipedia.org/wiki/Sensor_fusion https://en.wikipedia.org/wiki/Sensor_fusion TIL, thanks.
- redcalx 10y ago
  Indeed. I.e. have some probabilistic model of the 'world' and the probe's status within it (position, speed, rotation, etc). The sensor information then 'merely' informs that model, so e.g. if some sensor or piece of code says the probe has instantaneously jumped to a new location some distance away then the model can just disregard that as not conforming to anything like what was expected (the set of priors on how the probe moves, or essentially the laws of physics). Or... run the flight controller through a 'fuzzer' that throws lots of unexpected scenarios at it. To be honest I'm rather disappointed that a project at this level has succumbed to a bug like this. It's a few thousand dollars of additional dev effort versus the whole project failing; classic small certain initial cost versus large possible future cost (see Taleb's Antifragile, systemic failure of financial markets, etc.) Ho hum.
  - ansible 10y ago
    It's a few thousand dollars of additional dev effort versus the whole project failing; classic small certain initial cost versus large possible future cost... We in hindsight, now know that a little extra development could have avoided the problem. The trick is trying to figure out where to spend your limited resources as the project is going. There are lots of areas that might have caused problems. There may well be other flaws in the system that would also have caused a failure on descent.
simonh 10y ago
It's also not because the probe was constrained in terms of it's computing hardware. If you'd made the hardware a thousand times for powerful, it would have made zero difference to the 'smartness' of the software. Nor is it clear that applying the wonders of the modern AI age - Deep Blue, Watson, AphaGo, would help. They're massively optimized for the one task they're good at and completely useless at anything else. This is why I'm deeply pessimistic about achieving human level AI any time soon, even within the next 100 years. I'm 50 years old today. AI researchers back when I was born expected to have substantially solved AI as a problem by now, but we're still barely scratching the surface of a very big domain. This accident is a really good demonstration of the limitations of modern computer systems in terms of autonomous independent situational awareness.
- gonzo 10y ago
  Happy Birthday
anvandare 10y ago
But what do you do when there is a bug with the hardware clock, or with the image analysis software that recognizes how far the ground is? Or, supposing you installed a laser measurement tool to gauge distance-to-ground level, with the software interpreting that? You could of course have quorums - with the majority of the systems deciding which solution (still a while to go / imminent crash!) is the correct one, but what if you had a problem with that part? And that's just the problem of figuring out that there is a problem. >The first thing to do was to try to seal up the hole. This turned out to be impossible, because the ship’s sensors couldn’t see that there was a hole, and the supervisors, which should have said that the sensors weren’t working properly, weren’t working properly and kept saying that the sensors were fine. The ship could only deduce the existence of the hole from the fact that the robots had clearly fallen out of it, taking its spare brain-which would have enabled it to see the hole-with them. You could stack layer upon layer of fault detecting modules and supervising software and error and redundancy modules, but then you'd probably wind up with something like Dark Star's Bomb 20: >Unfortunately, Doolittle has mistakenly taught the bomb Cartesian doubt and, as a result, Bomb #20 determines that it can only trust itself and not external input. Convinced that only it exists, and that its sole purpose in life is to explode, Bomb #20 states "Let there be light," and promptly detonates.
- ethbro 10y ago
  There's some room between "sensor fusion is fragile enough that if a physical condition persists for an unexpected amount of time the craft is lost" and "all sensor faults can be handled." Notably, this obviously wasn't a failure case they programmed for. But it does seem a pretty fragile system to throw across the solar system in retrospect.
Gmo 10y ago
I don't know how altitude is calculated on Mars, but, for instance, there are some landing strips of Schiphol Airport (Amsterdam) that are below sea level and I expect an altimeter to give a negative value there. But this value is correct though ! Not everything is as easy as it seems.
- manarth 10y ago
  There are two known ways of calculating altitude on Mars: firstly by atmospheric pressure, with an arbitrary value of 6.105mb chosen (based on readings from Voyager). In 2001, a new definition was chosen, based around an ellipsoid (the Areoid) formed by imaginary sphere of the mean radius of the planet. The effect is that the intended landing site is at an altitude of -250m, and the lowest point on Mars is at an altitude of -8200m.
lmm 10y ago
> Kind of sad to see that computers nowadays still lack what we call common sense. I mean the machine received negative altimeter data but if it had been able to just look around, it could have seen that this data was erroneous. Hell, considering the descent profile was carefully prepared, the computer should also have noticed that it was way too early to reach the ground and should have concluded that something was wrong with the altitude measure. Well, computer vision is a different issue. Imagine you're a human sealed inside this thing, with no vision from the outside. You reach the point when the parachute's supposed to deploy, you feel something goes wrong - there's a big force, or it's in the wrong direction. Did the parachute rip off? Did it fail? You look at your two altimeters; one says that you're 3.5km up, one says that you're at almost ground level (that it's negative is a red herring I think - the probe knows the readings might be noisy and expects to handle that). What do you do?
- jobigoud 10y ago
  I would look at the trajectory of data points so far. Can't expect the altitude to jump by several kilometers in a few seconds. Unless the two altimeters were always disagreeing but that doesn't seem to have been the case here.
chewyfruitloop 10y ago
... or whoever wrote the code should have put boundary checks in to make sure a negative altitude was caught and handled properly

ygra 10y ago

Well, common sense in a way would be enabled with assertions. But even if you know that you cannot be below ground, how would you recover? Your sensors clearly tell you that you're below ground, so what is the course of action? You have no way of knowing where you are, you just know that you don't know. It doesn't really change anything in the outcome. Sure, maybe you could go from altitude measurements to time measurements and most likely still leave a crater since it's not exact enough (there's a reason for the internal measurement instead of simpler ways, after all). It would also require you to anticipate the malfunction in which case you already know that things like that could happen, in which case you'd likely determine how it could happen and how to avoid it and continue having useful data. Sounds to me like a better solution than trying to recover without data.

grondilu 10y ago
From the article: > 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. It would have been better to do nothing, in the hope that the altimeter data will resume to reasonable values, especially since the article mentions that the error is not supposed to last long: > Its output was generally as predicted except for this event, which persisted for about one second – longer than would be expected.
WalterBright 10y ago
There are several ways. First off, ignore the erroneous data. Then, estimate the altitude by other methods. As you mentioned, one way would be to integrate time and velocity. All inputs and outputs should be run through sanity checks, with a plan for when they go wrong. Essentially, when you've got a system that can't be fixed, plan for failure of each and every component (in isolation).
- homero 10y ago
  Cars do this, you can kill many sensors and an engine will still limp even with misfires. I guess consulting Bosch isn't an option tho
  - ethbro 10y ago
    Some cars do this. My friend's Honda literally stopped combustion when his battery died while driving (no, I have no idea how, but that was the diagnosis). In contrast, I've limped my Miata along on alternator-only when the battery wouldn't hold a charge. Note: feathering the gas at a stop with brakes and clutch depressed to keep your spark from dying is an "interesting" experience.
    - dotancohen 10y ago
      At a stop pull the tranny out of gear and activate the parking brake. More fun is driving a vehicle with no clutch: stalling at every stop and starting the motor in first gear, and shifting without clutching. I had to do that in my '83 280ZX in its last days.
    - dotancohen 10y ago
      At a stop pull the tranny out of gea and activate the parking brake. More fun is driving a vehicle with no clutch: stalling at every stop and starting the motor in first gear, and shifting without clutching. I had to do that in my '83 280ZX in its last days.
  - matheweis 10y ago
    Not necessarily very well; my cars' mass airflow sensor went out a few months back... the performance was all over the place and sudden engine stalls were frequent. You could kill the engine just by accelerating quickly when it was cold. ... and that was a single sensor out.
acqq 10y ago
> your sensors clearly tell you that you're below ground They weren't telling that. As far as I understood, the sensors were fully right, the software just hasn't expected the rotation to last "so long" -- the whole second, so it calculated the result wrong ("negative height") by incorrectly processing these multiple (in time) for their model unexpected inputs.
blutack 10y ago
For context, the lander did have a radar altimeter. A radar altimeter has maximum distance from ground above which it will not establish a lock. If radar altimeter had never had a lock, either the radar altimeter has faulted in a way you can't detect, or you are above the lock range for your radar altimeter. If the radar altimeter had locked, you have a very accurate measurement of height above ground.
- moioci 10y ago
  That's the surprising thing, though: "its radar Doppler altimeter functioned correctly and the measurements were included in the guidance, navigation and control system. "
  - pbhjpbhj 10y ago
    And presumably mission time was in use too? Presumably they know to the (milli?)second when the lander should touchdown, at least from the point where the lander starts its descent. Time of flight send like a very strong, reliable signal?
dean 10y ago
Better to discard obviously bad data altogether. The system certainly should not act on that data, as seems to have been the case here.
- mediocrejoker 10y ago
  I would argue that at 1700 km/h, even not acting is an action. The decision to do nothing is still a decision.

simosx 10y ago

It is an interesting problem and looks like a big extension to developing fault-tolerant software. That is, how do you develop fault-tolerant software and at the same time have logic that would reject some sensor readings if they deviate too much from up-to-now readings? How many readings would you reject in the hope that fresher readings would be better?

grondilu 10y ago
It's indeed a difficult problem and I'm not really surprised it's not solved by ESA even if they are probably extremely competent. I doubt anyone care about my opinion, but since you ask, I do notice that simulation seems to be a big part of their development. So I'm sure there has to be a way to use some kind of an evolutionary algorithm for creating descent procedures.
- NikolaeVarius 10y ago
  I think this testing WAS that testing scenario to create better descent procedures
baq 10y ago
looks like a machine learning approach would be interesting to consider. not that i believe anybody will allow such an approach on a extraterrestial probe, but training a model to classify sensor data as trustworthy or not could lead to some advancement here and perhaps in other areas.
dkbrk 10y ago
Actually, the solution to this sort of problem is well understood: it's a combination of Bayesian probability theory and decision theory. First, you define a Bayesian model for the system. This includes discrete propositions such as "sensor X is not working" as well as things like a description how the craft's velocity, angular velocity and displacement at t0 can evolve to at t1, expressed as a continuous probability distribution. This takes into account the prior distribution for altitude. All sensor inputs have distributions -- generally gaussian -- describing what values they could read given the "actual" value they're supposed to be measuring if they're not broken and giving completely erroneous results. Feeding sensor inputs into this model as they're received to produces a posterior describing the craft's physical state probabilistically. Dimensions which are relevant only insofar as they affect knowledge of the craft's physical state (such as "sensor X is not working") are marginalised out. Secondly, you define a utility function. This function takes some definite physical state of the craft's and a possible control output, and describes how "good" the outcome of that is. Then you choose the control outputs that maximise the expected utility, integrated over the craft's posterior state distribution. If sensor X started giving results unlikely under the time evolution model, P(Sensor X is not working|inputs,control signals,prior information) would start to increase very rapidly. If, somewhow, this probability was only 0.5, but the sensor was showing results that the craft was below the ground, the decision process would "decide" that "if sensor X is telling the truth, firing the landing thrusters will not lead to successful mission completion; if sensor X is lying it is too early to fire the landing thrusters" and not fire the thrusters. In reality, such a situation is absurd because sensor X showing the craft below the ground would lead to an extremely high probability for "sensor X is not working". However, the point is that even under extremely pathological conditions decision theory will continue to give reasonable results. One important consequence to note is that the sensor readings and state estimate do not matter in themselves, only as inputs to the decision theory process. To answer your specific question: if sensor X is determined to be, with high probability, faulty, its inputs aren't "discarded" per se, but will have a very small contribution to the state estimate. If sensor X is only believed to be faulty with moderate probability, both possibilities are considered and the optimal decision will be made given the information available and utility function. For more information, I recommend reading chapters 13 and 14 of "Probability Theory: The Logic of Science" by E.T. Jaynes [0]. [0]: http://www.med.mcgill.ca/epidemiology/hanley/bios601/GaussianModel/JaynesProbabilityTheory.pdf http://www.med.mcgill.ca/epidemiology/hanley/bios601/Gaussia...

rsp1984 10y ago

It's a question of proper sensor fusion. The way it's typically done is with some form of bayesian prior + a robust estimator that can handle the case where your sensors give you disagreeing evidence of the true state. So you have a prediction function that takes as input your previous estimated state and some form of "common sense" that's hard-coded or learned and which outputs a prediction of the current state. Then you look at your current measurements and if one of it disagrees to much it gets downweighted or outright discarded. The updated estimate is then computed from the prediction and the current measurements.

grondilu 10y ago
Neat. There actually is a wikipedia entry about sensor fusion: https://en.wikipedia.org/wiki/Sensor_fusion https://en.wikipedia.org/wiki/Sensor_fusion TIL, thanks.
redcalx 10y ago
Indeed. I.e. have some probabilistic model of the 'world' and the probe's status within it (position, speed, rotation, etc). The sensor information then 'merely' informs that model, so e.g. if some sensor or piece of code says the probe has instantaneously jumped to a new location some distance away then the model can just disregard that as not conforming to anything like what was expected (the set of priors on how the probe moves, or essentially the laws of physics). Or... run the flight controller through a 'fuzzer' that throws lots of unexpected scenarios at it. To be honest I'm rather disappointed that a project at this level has succumbed to a bug like this. It's a few thousand dollars of additional dev effort versus the whole project failing; classic small certain initial cost versus large possible future cost (see Taleb's Antifragile, systemic failure of financial markets, etc.) Ho hum.
- ansible 10y ago
  It's a few thousand dollars of additional dev effort versus the whole project failing; classic small certain initial cost versus large possible future cost... We in hindsight, now know that a little extra development could have avoided the problem. The trick is trying to figure out where to spend your limited resources as the project is going. There are lots of areas that might have caused problems. There may well be other flaws in the system that would also have caused a failure on descent.

simonh 10y ago

It's also not because the probe was constrained in terms of it's computing hardware. If you'd made the hardware a thousand times for powerful, it would have made zero difference to the 'smartness' of the software. Nor is it clear that applying the wonders of the modern AI age - Deep Blue, Watson, AphaGo, would help. They're massively optimized for the one task they're good at and completely useless at anything else. This is why I'm deeply pessimistic about achieving human level AI any time soon, even within the next 100 years. I'm 50 years old today. AI researchers back when I was born expected to have substantially solved AI as a problem by now, but we're still barely scratching the surface of a very big domain. This accident is a really good demonstration of the limitations of modern computer systems in terms of autonomous independent situational awareness.

gonzo 10y ago
Happy Birthday

anvandare 10y ago

But what do you do when there is a bug with the hardware clock, or with the image analysis software that recognizes how far the ground is? Or, supposing you installed a laser measurement tool to gauge distance-to-ground level, with the software interpreting that? You could of course have quorums - with the majority of the systems deciding which solution (still a while to go / imminent crash!) is the correct one, but what if you had a problem with that part? And that's just the problem of figuring out that there is a problem. >The first thing to do was to try to seal up the hole. This turned out to be impossible, because the ship’s sensors couldn’t see that there was a hole, and the supervisors, which should have said that the sensors weren’t working properly, weren’t working properly and kept saying that the sensors were fine. The ship could only deduce the existence of the hole from the fact that the robots had clearly fallen out of it, taking its spare brain-which would have enabled it to see the hole-with them. You could stack layer upon layer of fault detecting modules and supervising software and error and redundancy modules, but then you'd probably wind up with something like Dark Star's Bomb 20: >Unfortunately, Doolittle has mistakenly taught the bomb Cartesian doubt and, as a result, Bomb #20 determines that it can only trust itself and not external input. Convinced that only it exists, and that its sole purpose in life is to explode, Bomb #20 states "Let there be light," and promptly detonates.

ethbro 10y ago
There's some room between "sensor fusion is fragile enough that if a physical condition persists for an unexpected amount of time the craft is lost" and "all sensor faults can be handled." Notably, this obviously wasn't a failure case they programmed for. But it does seem a pretty fragile system to throw across the solar system in retrospect.

Gmo 10y ago

I don't know how altitude is calculated on Mars, but, for instance, there are some landing strips of Schiphol Airport (Amsterdam) that are below sea level and I expect an altimeter to give a negative value there. But this value is correct though ! Not everything is as easy as it seems.

manarth 10y ago
There are two known ways of calculating altitude on Mars: firstly by atmospheric pressure, with an arbitrary value of 6.105mb chosen (based on readings from Voyager). In 2001, a new definition was chosen, based around an ellipsoid (the Areoid) formed by imaginary sphere of the mean radius of the planet. The effect is that the intended landing site is at an altitude of -250m, and the lowest point on Mars is at an altitude of -8200m.

lmm 10y ago

> Kind of sad to see that computers nowadays still lack what we call common sense. I mean the machine received negative altimeter data but if it had been able to just look around, it could have seen that this data was erroneous. Hell, considering the descent profile was carefully prepared, the computer should also have noticed that it was way too early to reach the ground and should have concluded that something was wrong with the altitude measure. Well, computer vision is a different issue. Imagine you're a human sealed inside this thing, with no vision from the outside. You reach the point when the parachute's supposed to deploy, you feel something goes wrong - there's a big force, or it's in the wrong direction. Did the parachute rip off? Did it fail? You look at your two altimeters; one says that you're 3.5km up, one says that you're at almost ground level (that it's negative is a red herring I think - the probe knows the readings might be noisy and expects to handle that). What do you do?

jobigoud 10y ago
I would look at the trajectory of data points so far. Can't expect the altitude to jump by several kilometers in a few seconds. Unless the two altimeters were always disagreeing but that doesn't seem to have been the case here.

chewyfruitloop 10y ago

... or whoever wrote the code should have put boundary checks in to make sure a negative altitude was caught and handled properly