State machines: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Created page with "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 compo...")
 
(→‎Related content: + Property rule)
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
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.  
{{infobox subsystem
|name =State machine support for the Autopilot system
|started= 01/2013
|description = supporting state machines in autopilot XML config files
|status = Under active development as of 01/2013
|developers = [[User:Zakalawe]] (since 01/2013),
}}
 
 
XML autopilot modules already support stateful components, especially JK and RS [[Autopilot_Configuration_Reference#Flip_Flop|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 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.
* 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.  
* 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?)
* 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.
* 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)
* 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)


Line 16: Line 22:


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.
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 ==
=== Wiki articles ===
* [[Property rule]]
=== Source code ===
* {{simgear source|path=simgear/structure/StateMachine.hxx}}
* {{simgear source|path=simgear/structure/StateMachine.cxx}}
[[Category:Developer Plans]]

Latest revision as of 08:59, 30 October 2020

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

Wiki articles

Source code