Sounds reasonable. Is the current height above terrain in the property tree someplace?
FWIW (and hopefully this doesn't mean major breakage) I've been considering some changes to the autopilot infrastructure to make it more flexible. For instance, we (or at least I) could really use a mode to hold speed with pitch, or hold pitch with elevator. And it would be nice to be able to support some of the more advanced FCS concepts that right now are only accessible to JSBSim models (things like yaw dampers, and other fly-by-wire type stuff.)
Regards,
Curt.
Let me share my thoughts about the autopilot:
* I would like to see the autopilot move from c++ code into the instrument configuration xml-files.
* The autopilot should get input from other instruments (airspeed indicator, altimeter, attitude indicator, etc.), and not from /position/altitude-ft, /velocities/..., etc. That way the wing-leveler would be unuseable if the attitude indicator was "broken". Failures in the underlying instruments and systems would affect the autopilot.
* A PID-controller that can be accessed from the instrument configuration files. This could be used to build the autopilot controller structure as an instrument. This means that one could build different autopilot instruments for different aircraft. The Cub for example might have a simple autopilot with only heading hold and altitude hold. And because the Cub does not have an attitude indicator instrument, a wing-leveler would not be available. And in addition the heading hold would not be allowed to use roll information.
-- Roy Vegard Ovesen
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
