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
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
  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

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

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.


This email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
Flightgear-devel mailing list

Reply via email to