Re:How the Boeing 737 Max disaster looks to a software Devel...
by amluto on Thursday April 18, 2019 @06:27PM
(#19695351)
PID controls do exactly what you are objecting to.
Re:How the Boeing 737 Max disaster looks to a software Devel...
by AWildC182 on Thursday April 18, 2019 @06:31PM
(#19695372)
It's more nuanced than that. My ramp functions technically have a += 1 somewhere in them. You just don't want to += a motor value directly or otherwise add to state out of a feedback loop. You can verify the PID function in simulation/unit test. It's much harder to unit test the motor/driver/controller on a stand.
Re:How the Boeing 737 Max disaster looks to a software Devel...
by jschwartzi on Thursday April 18, 2019 @07:28PM
(#19695679)
It seems like what you're really getting at is that when you have a control like this where there's a non-linearity in response for a linear change in input quantity, what you really want to do is instead have a non-linear change in input quantity so that there is a linear response. In that case, you would characterize the effect of the control on the response variable and arrive at a table of acceptable values. Then your +=1 becomes an increment of an index which returns the next-highest acceptable value and you no longer produce a non-linear change in the response.
Re:How the Boeing 737 Max disaster looks to a software Devel...
by kortilla on Thursday April 18, 2019 @07:56PM
(#19695849)
No, you’re missing the point a bit. It’s not about the magnitude of the response, it’s about the propensity for a feedback loop.
=+1 is shorthand for “ignore everything going on in the world and increase your value”. This is almost never what anyone actually wants so they try to spend a bunch of time guarding against calling that when it’s already at a maximum.
Instead, the safe thing to do is only assign to it from a function with a ceiling.
val = min(CEIL, val+1)
It’s way to easy to get runaways with =+1 even in serious systems like this one. Every time I see that in code I review where the value is some long-lived thing, I just confirm with the author that they don’t care if it overflows, because it’s probably gonna happen.
I learned this a long time ago by putting a robot through a door-frame at max speed.
Edit: To add to this in a way that might actually make it useful to someone, motor outputs should almost always be a continuous function of something rather than their own internal state. MCAS should have been coded as something like (vastly oversimplified)
if(AoA >= MAX_AOA) trimPosition = g(f(AoA, IAS), trimPosition, dt);//AoA/IAS dependent ramp function
else trimPosition = g(trimInput, trimPosition, dt);//ramp function
not
if(AoA >= MAX_AOA) trimPosition += 1;
Because the latter is very likely to result in a runaway even if you have bounds checking somewhere else. Worst case you don't have bounds checking and the position value/register value loops over and the tail just starts spazzing out, flapping up and down as fast as the motor will drive it.