[njoubert]

I see no mention of "advanced control techniques"? Sounds like there is just a limit on roll/pitch angles and a limit on distance applied. Saying "advanced control techniques [for multirotors]" sets an expectation for something along the lines of Tedrake's Underactuated Control approaches: http://underactuated.mit.edu/

[idiotsecant]

Sensor fusion is part of the control system. 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. You need not gatekeep here, this is a real term.

[jessriedel]

I don't think this is gate keeping. Regardless of the terminology used within the field, the intended audience of this pop article will interpret "advanced" to mean actually unusual or at the cutting edge. Relying on the public's misinterpretation of jargon ought to be criticized.

[krisoft]

> ... intended audience of this pop article ...

Are we reading the same page? I see datasheets linked in the navbar, an article about an EtherCan box, and white papers about encoders. If any site is then certainly this one has a very specialist audience in mind.

Besides i believe what constitutes "advanced" gets wider rather than narrower when you move towards a less specialised audience. To the generic population even two stacked PID loops would qualify as "advanced" while practitioners would call that "conservative" or "old-fashioned".

[idiotsecant]

In the motion control and process control industries deterministic systems or SISO systems like PID are typically considered in what someone would just call 'controls'. Advanced process control is an actual industry three-letter acronym term relating to 'meta-controls' where the controller is itself controlled by an outside system like the supply chain or a plant tuning system, etc. This is the point I was trying to make - i'm not making a judgement call on what is or is not sufficiently 'advanced' only pointing out that this term has a meaning that the parent post I was replying to might not have understood.

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

[njoubert]

The article title is still misleading. The sensor fusion was the root cause of the malfunction, it was not the advanced control technique that was deployed to survive the anomaly.

[mrandish]

My understanding from reading an earlier explanation from JPL was that it appeared the issue wasn't so much from the missing frame itself but rather the software not being tolerant of the frame count being off.

IIRC, it seemed more like a missing test case or scenario in the software validation suite might have been the ultimate root cause.

[arbirk]

Agree. It's interesting that they don't treat the optical and gyroscopic systems as two separate sensors with the possibility to disregard one if it disagrees too much. A quick restart of the visual system would have been the most optimal solution #2020-hindsight

[afrodc_]

How would you know which one is wrong in this scenario?

[omeze]

This reminds me of the adage “ Never go to sea with two chronometers; take one or three” [1] to avoid this exact conundrum

[1] https://en.m.wikipedia.org/wiki/Triple_modular_redundancy#Ch...

[kortex]

Incidentally, I learned the hard way why you never run two instances of Consul (or any Raft powered stack), only 1 or 3. All sorts of wacky state can occur.

[arbirk]

You have the navigation system as a third ‘sensor’, but in this case the sensor with an abnormal spike could be disregarded

[xtiansimon]

> “You need not gatekeep here, this is a real term.”

Not my monkey; not my circus. But… is critique of terms “gatekeeping”? I understand this term in the context of ownership (ie. gatekeepers for books are publishers/printers who own the means of production.)

I greatly appreciate some level of debate of terms here on HN.

[shadowgovt]

I wish they had gone into more detail. Unfortunately, my experience is that, yes, such limiters do count as "advanced."

First time I got my hands on a working mounted arm, I was cautioned again and again the need to run any new program in low-speed mode first. Because the arm had no limiting logic and would cheerfully power-bomb its own base with all the force and torque its motors could muster if I told it to.

Preventing that is still considered an "advanced technique."