7 ms·

It's very strange because, if would have been a glitch that would cause the program to halt unexpectadly, the engines would have remained running. But from the

It's very strange because, if would have been a glitch that would cause the program to halt unexpectadly, the engines would have remained running. But from the data, it actually entered into "on the ground" state initiating its exploratory procedure. But what kind of "on the ground" test condition could have made it to do that ? The fact that it was "designed to decelerate the craft for 30 seconds until it was metres off the ground" but instead it ran only 3, raises many questions. Not to say that there are zillions of ways to actually test that you are on the ground or not..

planteen 10y ago
> if would have been a glitch that would cause the program to halt unexpectadly, the engines would have remained running I don't know about that. I've worked on systems where there is some hardware with thruster duration that software is writing. So if software crashes, the thrusters stop. (But I have never worked on a lander). If software is running the control loop, things would get very bad if the engines kept running at their previous output levels for 27 seconds. Thrusters are never aligned perfectly, who knows what kind of rate the lander had, there may be wind pushing it, etc. If a thruster blindly kept running, the lander may have spun up, flipped over, etc.
- zer0gravity 10y ago
  Ok, good point. But the point that I wanted to make is that a software crash wouldn't explain why the lander behaved as if it was on the ground. So it's more probable that it reached the "on the ground" condition. If that condition was adequately programmed, the chances that some sensor glitch could have triggered it are quite low. So the probability is higher that it was either badly programmed or maybe someone flipped a bit somewhere ..
  - planteen 10y ago
    Yeah I agree, it seems like that between an accelerometer and gyro that it should be fairly clear when you reach the ground condition. Maybe a switches that engages when a lander legs are pressed or something similar as well.
tremon 10y ago
The lander didn't have sensors on its feet, so my guess is there may have been two conditions to check for "on the ground": either a vertical speed of 0m/s (gyroscope), or an altitude of 0m (radar). Given that the parachute was deployed at the correct time and its deployment was governed by air speed (to be deployed around 1mach), the gyroscopes were likely working correctly. The radar detection wasn't available until after deployment of the parachute (more specifically, after ejecting the heat shield, which occurred at the same time), so if the machine's decision was based on faulty input, the doppler radar is likely to blame. It is also possible that the sensors were working correctly, but the inputs were processed incorrectly. I'd expect that an issue like that could have been caught while testing the lander on earth... edit: it's also unlikely the engines would have kept firing after computer malfunction: there were multiple (9 iirc) thrusters all around the craft and they were fired independently using pulse-width modulation. This approach was intended to both slow down the descent and to stabilize its course/orientation.

planteen 10y ago

> if would have been a glitch that would cause the program to halt unexpectadly, the engines would have remained running I don't know about that. I've worked on systems where there is some hardware with thruster duration that software is writing. So if software crashes, the thrusters stop. (But I have never worked on a lander). If software is running the control loop, things would get very bad if the engines kept running at their previous output levels for 27 seconds. Thrusters are never aligned perfectly, who knows what kind of rate the lander had, there may be wind pushing it, etc. If a thruster blindly kept running, the lander may have spun up, flipped over, etc.

zer0gravity 10y ago
Ok, good point. But the point that I wanted to make is that a software crash wouldn't explain why the lander behaved as if it was on the ground. So it's more probable that it reached the "on the ground" condition. If that condition was adequately programmed, the chances that some sensor glitch could have triggered it are quite low. So the probability is higher that it was either badly programmed or maybe someone flipped a bit somewhere ..
- planteen 10y ago
  Yeah I agree, it seems like that between an accelerometer and gyro that it should be fairly clear when you reach the ground condition. Maybe a switches that engages when a lander legs are pressed or something similar as well.

tremon 10y ago

The lander didn't have sensors on its feet, so my guess is there may have been two conditions to check for "on the ground": either a vertical speed of 0m/s (gyroscope), or an altitude of 0m (radar). Given that the parachute was deployed at the correct time and its deployment was governed by air speed (to be deployed around 1mach), the gyroscopes were likely working correctly. The radar detection wasn't available until after deployment of the parachute (more specifically, after ejecting the heat shield, which occurred at the same time), so if the machine's decision was based on faulty input, the doppler radar is likely to blame. It is also possible that the sensors were working correctly, but the inputs were processed incorrectly. I'd expect that an issue like that could have been caught while testing the lander on earth... edit: it's also unlikely the engines would have kept firing after computer malfunction: there were multiple (9 iirc) thrusters all around the craft and they were fired independently using pulse-width modulation. This approach was intended to both slow down the descent and to stabilize its course/orientation.