|
|
|
|
|
|
by stevenhuang
1822 days ago
|
|
|
They expected the camera not to drop frames. Their optical flow system tracked time independent of actual frame time. Anyone who've done optical flow or even anything with video recording on embedded devices knows these are known failure modes, and should be handled properly. That is what's being discussed here, this is the failure mode in question. So yes, those experienced in optical flow and embedded control systems _would_ have handled this specific failure better. But none of us are saying any hobbyist could have trivially sent it to Mars. It should be obvious what we are specifically addressing: that this kind of error is not the sort that should happen in a properly thought out, bog standard real time system. > JPL tends toward having generalists And that's fine too, plus dumb mistakes always happen. So it shouldn't be much surprise when the "armchair quarterback" responses show up, and rightly point out the issues. It would be more crazy not to be incredulous. |
|
|
It isn't, actually. The comment I responded to, and the one it linked to, are broadly criticizing the sensor fusion/control loop implementation--the thing that saved Ingenuity after the optical flow subsystem started returning bad data. That's what's being discussed here, in the context of this subthread where I entered it.
The dropped frame thing is much more cut and dried, and it's obviously a bonehead mistake. It's also the kind of thing that's always going to happen, as you say. Many of the commenters here seem to be generally at odds with that reality--I don't believe the state of the art in software development has yet achieved guaranteed bug-free implementation of diverse real world applications, but you wouldn't think that from reading some of these comments (e.g. the one you linked above).