[baybal2]

> Sensor fusion that incorporates visual information is outside of the typical classical controls sphere and is likely considered part of an advanced controls segment of the devices firmware as opposed to the bog standard deterministic controls algorithm.

Not so advanced as very correctly pointed out by https://news.ycombinator.com/item?id=27554949

Motor-attitude control loop cannot, and should not be "fused" with navigation layer, whether INS, or optical flow sensor.

The bog standard deterministic controls algorithm here is "bog standard superior." Computer vision/optical flow sensors have much lower precision than gyroscopes, and accelerometers, let alone aerospace grade ones.

[caconym_]

Do any of these commenters have experience designing small "helicopter" "drone" avionics systems using off-the-shelf hardware, as in Ingenuity? For instance, you mention "aerospace grade" inertial sensors, yet Ingenuity apparently uses COTS components in that role^[1].

There are smart people on HN, but unless they have actual professional experience designing similar vehicles, I'm inclined to give the JPL folks the benefit of the doubt. It's also worth considering that they are the only team that has ever flown such a vehicle on another planet, which imposes constraints that even other experts may not be familiar with; that they were working with a limited budget, and making heavy use of existing open-source code; and that, generally speaking, we weren't in the room.

On the other hand, maybe they really are incompetents whose avionics system is "designed wrong", and who do need these things explained to them so that they can learn faster, as the commenter you linked so delightfully put it. In that view, I guess their groundbreaking achievement is probably more dumb luck than anything else--maybe JPL should do some firing and hiring so that things don't turn out worse next time!

^[1] https://spectrum.ieee.org/automaton/aerospace/robotic-explor...

[stevenhuang]

Yes actually, any hobbyist who has done anything with drones and localization via optical flow positioning understands the problem.

The commentator is correct. And saying something is done wrong is not the same as saying someone is incompetent.

While I understand you're trying to point out hubris, you're swaying the other way and appealing to authority.

See also: https://news.ycombinator.com/item?id=27555761

[caconym_]

> While I understand you're trying to point out hubris, you're swaying the other way and appealing to authority.

I'm appealing to the fact that they sent the thing to Mars and flew it. If you think "any hobbyist" could have trivially done a better job, which seems to be essentially what you're saying, there isn't much for me to say to you other than that I strongly disagree. And if I'm supposed to be the one who's appealing to authority here, I'm not sure what everybody else thinks they're doing.

I expect JPL tends toward having generalists working on projects like this, and I expect they do have things to learn. Nothing in my comment contradicts any of that. But the level of armchair quarterbacking in here is crazy and IMO largely unjustified.

[stevenhuang]

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.

[caconym_]

> They expected the camera not to drop frames [...] That is what's being discussed here

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).