State machines
Jump to navigation
Jump to search
| 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.