Andy Ross <[EMAIL PROTECTED]> said: > Jim Wilson wrote: > > That has nothing at all to do with what I said. We are controlling > > individual control surfaces. Period. I don't think we should have > > subclasses for each desired action/process. Only each control > > surface type. Roll control ends up being intrinsically part of > > aileron control is it not? > > I'm half with you. We certainly don't want separate subclasses for > every conceivable action, that's madness. But assuming a set number > of "standard" control surfaces isn't right either. A helicopter has > roll control yet no ailerons. The harrier has ailerons *and* roll > jets, with an autostabilizer that uses both depending on conditions. > > I'd strongly suggest an architecture where the autopilot specifies a > black box, with all input and output done via property nodes: > > > ../roll-rate -+ +-----------+ /controls/elevator > ../yaw-rate -+--> | Autopilot | --> /controls/ailerons > ../heading -+ +-----------+ /controls/... > > No control system assumptions in the C++ type system, and it's still > perfectly configurable. Just remap the input and output nodes > per-aircraft if you want, maybe via an override in the -set.xml file. >
Good point (as is Jon's) but in all such design cases there are tradeoffs. What I'm looking at is ease of configuration and that may be a reasonable tradeoff against the limitations of defining a standard set of control surface subclasses (i.e. having to add a special case for the harriers rather unique feature). It could also be possible to design in a way that allows both the complex approach to configuring generic controllers and a set of subclasses for simplified configuration of more standard aircraft. Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
