"Curtis L. Olson" <[EMAIL PROTECTED]> said: <snip>
> So that's what I've come up with so far. Am I completely nuts? Any > suggestions? I have no formal education in control theory, so what I know > has been gleaned from here and there so I probably don't know much of the > correct terminology and there are certainly tricks and things that I'm not > aware of. > > I'm hoping to do a good job of roughing in the flexible xml structure and > interfacing to flightgear, then get some help on the control theory side > from the experts. > This looks really good. I need to study what you are doing a little more carefully. But I'm wondering, is it possible that this could get over-abstracted? (is that a word?) I'm trying to think of an aileron controller that would not be interested in roll. Maybe backing up just a tadd would make sense? These are all controllers for ailerons, elevators, rudders, etc. A small and easily definable set which is ideal for subclassing. Maybe we could have a subclass for each of these controls rather than trying to abstract a generic controller class. Then these could have both generic and unique properties that are somewhat easier to configure. The xml for the AP configuration would include a controller-type property that would imply certain characteristics (such as integrating roll limits in the aileron controller). It will also be important not to have more than one controller for a given type active at any one time. If you want to test the limits of either concept, try getting the 747 to intercept an ILS and hold it. If you can do that, you can do anything. I would be interested in participating in this. Would it make sense to commit it as "newnewauto.???" or something with a temporary config flag? Best, Jim _______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
