On Sat, 9 Feb 2002 00:57:06 -0600, "Jon S. Berndt" <[EMAIL PROTECTED]> wrote:
>> WHAT??? >> >> Design maneuvering speed is "Va" and is simply and _only_ >> Va = Vs * sqrt(g load limit) >> >> You can be sure that an aircraft manufacturer would have a whole lot of >> patents if they had a method to recognize all the situations that can >> cause structural overloading and recover before these are reached. >> That would be the holy grail of FCS design, and of aerodynamic modelling! > >At 450+ knots a sudden full deflection elevator movement might not be so >good. (?) Additionally, a back and forth elevator motion at a particular >frequency might not be good at all. For one thing I know the F-16 (not a >modern commercial transport, but for example) has structural filters on >most/all aerosurfaces. This might have to do with the interaction between >the hinge moments, the servoactuator, and pilot inputs (etc.) so as to >prevent a divergent oscillation that might violate some structural >constraints - I can't remember exactly what it does, except that it >attenuates control inputs of a particular frequency. I am almost sure that >commercial transports limit some pilot actions to stay within structural >tolerances. > >In the case of the flight that crashed into the neighborhood in New York, >the particulars of that accident lead me to believe that given the sideslip >angle, and the yaw rate at rudder separation, the rudder command might have >been processed to eliminate the peak that stressed the rudder too far. I >could be wrong, but the thought occurred to me and I think it is plausible. >This particular accident did not appear to me to feature an obscure, >unpredictable causal manuever. > >Also, I don't think that all possible permutations of pilot actions that >overstress the aircraft need to be accounted for. Given my limited >understanding of neural networks (and from the demos I have seen at work) >this tactic might be effective in filtering out undesirable pilot inputs as >far as structural limit violations go. The problem with Neural Nets, as I understand it, is that they are regarded as non-predicatable. The only way to check that they perform correctly in all circumstances is to check all circumstances. The logic is effectively non-traceable (or regarded as such). This is why we don't use them at work (they have been suggested for matching historical data sets and modelling commanders decision making). In what would be regarded as safety-critical software the predictability and traceability of logic is important. This of course doesn't mean that such filtering can't be done, just that Neural Nets are probably not a starter. A classic example of control filtering for structural reasons that _is_ done is the A330/340 series. In the A330/340 the FCS reacts to wind bending due to gusts/turbulance by 'flying' the wing in the opposite direction. This reduces fatigue due to wing bending and allows a thinner, lighter, wing than would otherwise be necessary. http://fluid.power.net/techbriefs/papers/proc_gojny.pdf http://www.dfrc.nasa.gov/DTRS/1994/PDF/H-2002.pdf BTW, the A330 series might be a good 'data point' for JSBSim (and/or YASIM) as they would allow its 'envelope' to be expanded to cover high weight transport aircraft with complex FCS modes whilst preparing the way for a relatively simple (maybe!) move to the 4 engined A340. I'll follow this post up with a short 'paper' on wing loading and the points at which issues related to it might impact on FlightGear aircraft models. Rick -- David Farrent and Dougie O'Hara on the Cold War role of the ROC: 'What a world of sorrow is hidden in those few words - "[Post attack] crew changes would have been based on crew availability."' _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
