In order for the FDMs to consistently and completely handle a reset request from FlightGear, there ought to be a specification that describes what is supposed to happen. Here's a first cut at what a specification for the reset function might say: 1) There MUST be separate functions to a) initialize cockpit controls, and b) initialize the FDM.
Controls_init includes things like yoke position, trim, engine controls, et cetera. This is crucial when one or more inputs are coming from the keyboard as opposed to from a joystick. The first time around, the caller MUST call both, but subsequently the caller MAY call FDM_init alone. FDM_init MUST behave the same on init and re-init. The rest of this spec is devoted to the FDM_init. 2) FDM_init MUST be "clean" and 100% reproducible. That means that the FDM MUST NOT remember anything from before the init. This includes systematically initializing (including re-initializing) anything in the property tree that it cares about, as well as any internal variables (including any cache values, history, rates, momenta, et cetera). 3a) The following properties "belong" to the FDM. The caller MAY specify any/all of these, and the FDM MUST respect them: -- latitude, longitude, and altitude; -- heading, pitch attitude, and bank angle; -- groundspeed. 3b) The following properties also "belong" to the FDM. The caller MAY specify them, but the FDM MAY choose to ignore what the caller says: -- yaw rate, pitch rate, and roll rate; -- slip angle and rate of climb. 4) If the caller specifies any other properties, the FDM MAY ignore them or MAY respect them. 5) The caller does NOT NEED to specify any of the properties mentioned in item 3. Assuming settings are passed via the property tree, the FDM MUST interpret each of the following as "unspecified": -- A property that is entirely absent from the property tree. -- A property that is set to nil. -- A property that is set to "". Remark: The key point here is that the spec MUST provide clear conventions for indicating which properties are in the unspecified state. In the case of floating-point variables _tied_ into the property tree, none of those conventions would work, which seems like a sufficient reason why these variables SHOULD NOT be tied. 6) The altitude, if unspecified, defaults to "ground level" at the specified lat/lon. The rest of the properties mentioned in item 3 should default to zero. (This is not a particularly useful default for the position, so for practical purposes the caller SHOULD always specify an initial lat/lon.) 7) Other than the properties mentioned in item 3, the FDM MUST NOT mess with any other properties. This includes cockpit controls and trim. Specifically, any auto_trim, auto_throttle, or gs_capture functions MUST NOT be bundled into the standard FDM_init. If the caller wants to invoke such functions separately, that's beyond the scope of this document. 8) The interface MUST use the following units: degrees for angular variables, knots(true) for groundspeed, and feet(true) for altitude. Remark: The key point here is that the spec MUST specify a clear choice of units. The units in item 8, as proposed above, are not so much a recommendation as a reflection of the existing interface, although that's undocumented and there could well be inconsistencies in the existing usage. Comments? ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
