Hacker News Reader

Comment by raverbashing | Hacker News Reader

Yeah you have no idea of what you're talking about. An aircraft is not like your PC where you just click "ok" to some spurious popup and everything is fine

Cognitive load is a factor in many accidents. You don't have the plane doing something stupid during a critical stage (like take-off) with the excuse that you can "just disable it".

If a plane has an issue in keeping a stable flight but instead wants to point up or down beyond flight limits it is defective.

Edit: https://twitter.com/SarahTaber_bww/status/110525655715412787...

View on HN

Isn't handling unexpected conditions the entire reason for having a pilot onboard?

If the pilot is not expected to detect and respond to something like a faulty sensor that causes an unwanted control surface movement, then why have the pilot onboard at all? Why not just let the plane fly itself?

Unexpected conditions is not to mean "the aircraft software design is stupid and will try to kill you".

Surely autopilot failure is a predictable fault regardless of the underlying cause?

There isn't one predictable manifestation of autopilot failure you can train over.

Oh please. Go read about some of the rudder hard-over failures the 737 suffered over the years. A pilot should be able to fly out of these things. I think unfortunately the children of the magenta line are the ones truly trying to kill us.

"Unexpected conditions" are different from "a plane that actively tries to commit suicide"

And if you think all pilots do is respond and detect to fault, I suggest you learn more about their duties on the cockpit.

The 37 max was designed to change stabilizer pitch in a key moment of unstable flight and that trim is not able to be overridden by elevator input. You have to disengage a thing a t a critical altitude when flaps 0 happens at only 1000’ or so agl on a system you didn’t know exsisted and only activates under a few uncommon parameters to counteract the large rotation moment that the forward engines give. You really don’t quite know what you are talking about. 1000’ per min vertical speed is not uncommon for a controlled descent.

While you seem to know what you're talking about, you're not very good at expressing it at all (lack of proper grammar doesn't help).

it was on mobile, sorry.

perhaps this is more clear:

The 37-max was designed to change the stabilizer to be more nose down in attitude in a key moment of unstable flight and that nose down stabilizer trim is not able to be overridden by elevator input on the yoke because of the design. To fix it, you have to disengage the runaway trimming of the stabilizer at a critical altitude when you disengage flaps at about 1000’ or so agl(above ground level) on a system you didn’t know existed. To further complicate this, it only activates under a few uncommon parameters(max thrust, high angle of attack, steep bank angle, flaps retracted, autopilot disengaged) to counteract the large rotation force that the forward engines give. 1000’ per min vertical speed is not uncommon for a controlled descent so you don't have much time to fix it. You really don’t quite know what you are talking about.

If the pilots don't have the cognitive load to take over manual control at any time, let alone react to the question of sensors that are returning impossibly divergent readings, surely they are already overloaded.

For that and other reasons I don't know if it's as difficult as you say; these sort of things are where very intelligent UX design can play a major role.

For impossibly divergent sensors as there were in this particular case, if the difference between divergent sensors is between a normal flying pattern and a crazy disastrous scenario, two things should happen— (1) both sensors should be considered untrustworthy and their use in automation should be suspended, and (2) the pilots should be asked the straightforward question "are you in a normal flying pattern" and if so, re-enable the sensor which fits this pattern.

Additionally/alternatively, they could fit a few off-the-shelf commodity accelerometers/gyros directly to the circuit board of the flight computers and use their readings exclusively to predict which "real" sensors is most likely correct. For example if one "real" sensor suddenly swings and the other one didn't, has there been any corresponding shift in the accelerometers? This would be a perfect candidate for machine learning with a few thousand hours of flight simulator data with simulated sensor failures based on known sensor failure modes.

> and (2) the pilots should be asked the straightforward question "are you in a normal flying pattern"

How do you do this when the pilots can't see outside?

I’m not saying that answering the question is mandatory. But if they’re cruising and everything seems fine, or if they’re mid takeoff and everything seems fine... probably the sensor which is indicating a nosediving is probably fine.

If they respond with “no” then they should be given maximal control of the aircraft with the computer not restricting control or making any large scale adjustments itself.

Reply on news.ycombinator.com