State Machine Composer Design Notes

From Tekkotsu Wiki

Jump to: navigation, search

We will use the Model-View-Controller design pattern.

There are four models:

  1. A collection of enumerated types and their enumeration values, e.g., MapBuilder::RequestType_t
  2. A collection of node classes, and their prototypes and default argument values
  3. A collection of transition classes, their prototypes and default argument values, and their shorthand abbreviations, e.g., =C=>
  4. A collection of state machines, each consisting of a set of node and transition instances


Enumerated Types

Enumerated Types Model

Enumerated types are required for MapBuilder and Pilot requests, and are important for state signaling. The state composer tool will load a set of enumerated type definitions from a file on startup. Additional definitions may be included as part of a state machine definitions file, or loaded from a user-specified file.

Enumerated type definitions will be loaded and saved in XML format.

The components of an enumerated type are:

  1. Type name, e.g., MapBuilderRequestType_t
  2. Scope resolution prefix, e.g., MapBuilderRequest (omit the "::" scope operator at the end)
  3. Ordered list of enum elements, e.g., cameraMap, localMap, worldMap

Enumerated Types View

For initial development purposes, we can use a tree view to display all the enumerated types. The first level of nodes will be the types, and the second level will be the values. The standard tree view allows the user to open a node and see its children.

Enumerated Types Controller

For now all we need are the standard tree controls to open/close a node.

Node Class Definitions

Node Class Definitions Model

A node class can contain a state machine nested inside it. Therefore, a node class needs to be able to contain other node classes. It could also contain transition classes, although usually transition classes are defined globally.

The components of a node class definition are:

  1. Node class name
  2. Constructor argument list
  3. An ordered list of parent class constructor calls, from which parent classes are inferred
  4. A member variable and initializer list
  5. Zero or more method definitions
  6. An optional state machine instantiation (using the fourth kind of model)
  7. A flag to indicate if dummy copy constructor and assignment operators are desired (due to pointer member variables)
  8. User-specified text to be inserted into the class definition

Operations must be provided to edit each of these fields.

Node Class Definitions View

The view displays a list of all the node classes in the current context. At the global context, the tool should display all the state machines in the user's working directory. If he selects a node class, that becomes the current context, and the view displays all the node classes defined within it. This is usually as deep as things go; the typical robot behavior is just a parent state node with a bunch of other node classes defined and instantiated within it. But they can go deeper if required.

Transition Class Definitions

It's possible but rare for users to write their own transition classes. However, the system needs to know about the many built-in transition types, so we will have to create a representation for this information, similar to the information about built-in node classes.

State Machine Definition

A state machine is a collection of node and transition instances forming a directed graph. The nodes can instances either of built-in node classes or user-defined node classes. Transition instances have at least one source node and at least one target node, but they can also have more than one. The state machine is displayed in graph form, so we must also provide attributes to control the shape, size, color, and position of each node and transition instance.