State machines

From FlightGear wiki
Revision as of 16:15, 29 October 2020 by Johan G (talk | contribs) (Heading cleanup, use sentence case; + Related content: Source code, unfortunately I do not find any other documentation)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
State machine support for the Autopilot system
Started in 01/2013
Description supporting state machines in autopilot XML config files
Contributor(s) User:Zakalawe (since 01/2013),
Status Under active development as of 01/2013


XML autopilot modules already support stateful components, especially JK and RS flip-flops. The intention is to add explicit state-machine support, where a state machine component can be defined, with states and transitions between states.

Design

  • Each state will have a name, and a condition expression required to enable the state.
  • Each transition will have a name, and a condition expression required to transition into a new state. Transitions can also be conditional on the current active state.
  • Entering a state (firing a transition) can fire any number of binding expressions, as can leaving a state.
  • State machines will have a property indicating the current state. (And possibly an integer state index?)
  • A command will be defined to move a state machine to a new state - i.e explicitly fire a transition. This avoids creating signalling properties simply to fire transitions.
  • State-machines can also fire bindings on *any* state change. (This enables updating common properties or Nasal without repeating a rule on every state or transition)

Taken together, the above allows good re-use of transitions and states, to describe common auto-pilot and FMS logic.

As a particular specialisation of the above, will be an 'off-arm-active' state machine. This will be a state machine specialisation with three states, and fixed names, intended to model the common arm/engage pattern of many autopilot functions.

Benefits

  • Major benefit is moving imperative state logic from Nasal into XML. Ideally most autopilots could be created as a series of state machines (likely one for each control axis, plus some extras), some filters and components that perform computation, and small amounts of imperative Nasal within. In particular the amount of Nasal requiring to be evaluated each frame should greatly decrease.
  • Unlike Nasal, the state-machine states will be automatically serialised to the property tree, so there is a greater chance of sane behaviour with replays or over the network.

Implementation notes

  • We already have good support for conditional expressions, bindings and computational expressions in SimGear. The intention would be to build upon these so the syntax and logic is familiar to people.
  • Good inspector / debug support will help, as for the existing components. Especially, logging when state transitions occur, and when a transition becomes enabled or disabled.

Related content

Source code