automata v0.1.0 API Reference
Modules
The Automata.Server starts the individual Automata.AutomatonSupervisor's
under this Supervisor, which handles their lifecycle management.
A struct that keeps local information specific to the automaton for a world. It is received by formatters and contains the following fields
Runs as a child of Automata.AutomataSupervisor and supervises the
Automaton.AgentServer which is a delegate for lifecycle management of the user
agents and starts the agents under the Automata.AgentSupervisor.
A global Blackboard for knowledge representations
Raised to signal multiple automata errors which happened in a world.
Sets the World in motion, meta-manages world operations.
Classification hierarchy (Perception System) Once the stimulus from the world has been “sensed,” it can then be “perceived.” The distinction between sensing and perceiving is important. An agent, for example, may “sense” an acoustic event, but it is up to the perception system to recognize it as an instance of a specific type of acoustic event that has some meaning to the agent. A segment of agents may interpret an UtteranceDataRecord as just another noise, but one should classify the utterance as the word "hello”. Similarly with multicast, unicast, broadcast events. Thus, it is within the Perception System that each agent assigns a unique “meaning” to events in the world.
MMLC - Meta-MultiLevel Control
The World-Agent Division The Sensory System marks the single entry point into an agent from the World. All sensory input from the world must pass through the Sensory System before it can be processed by the rest of the agent's mind.
Automata.Server is a behavior which provides decentralized fault tolerance
lifecycle management for a collection of user-defined agents.
On application start, this supervisor process starts the
Automata.AutomataSupervisor and it's corresponding Server. It is started
with strategy :one_for_one to ensure that each Automata.AutomataSupervisor
is independently self-healing, thus providing fault tolerance.
Global utility decisioning First pass should prioritize automata based on global utility calculations Second pass should coordinate automata in achievement of some global goal
A World is made up of Agents (automata) which interpret & act based on global(all-agents) & local(per-agent) Obervations (from State Space Representations) and Events from the World.
A struct that keeps global information about all automata for the world. It is received by formatters and contains the following fields
This is the primary user boundary point control interface to the Automata
system. The automaton_config parameters flow from the root through the
supervision tree on startup and are interpreted by the Typology system to inject
the appropriate components into the user-defined agents.
Parses each individual agent config from the user and starts it under the AgentSupervisor.
Directly supervises the lifecycle of the user-defined agents (behavior trees).
The Automaton.AgentServer starts them under this process. It is the parent
and root of the user-defined composite, making it the boundary point between
the high level Automaton policy control system and the user defined control.
The “brain” of each agent implemented with Automata is organized into a collection of discrete systems that communicate through an internal blackboard.
Implements the Behavior Tree (BT) state space representation. Each tree is goal-oriented, i.e. associated with a distinct, high-level goal which it attempts to achieve.
An action is a leaf in the tree. It operates on the world as a component of a composite(control) node. Actions can alter the system configuration, returning one of three possible state values: Success, Failure, or Running. Conditions cannot alter the system configuration, returning one of two possible state values: Success, or Failure.
Agent is a function from percept sequences to actions Action Selection, Must be simple and fast Given a set of PerceptMemory objects(structs) that detail the perceived state of the world, the agent must decide which action(s) it is appropriate to perform. This process is known as Action Selection. There are three essential issues to be addressed when designing an Action Selection mechanism. First, what is the fundamental representation of action used by the system? Second, how does the system choose which actions to perform at a given instant? Many types of decision-making processes are possible here. Third, how can the choice of action be modified to allow the agent to learn from experience?
An Automaton.Types.BT.Behavior is an abstract interface for composites and components that can be activated, run, and deactivated. Actions(Execution Nodes) provide specific implementations of this interface. Branches in the tree can be thought of as high level behaviors, heirarchically combining smaller behaviors to provide more complex and interesting behaviors.
When a component behavior is complete and returns its status code, then the Composite it is a child of decides whether to continue through its children or whether to stop there and then and return a value.
Parallel Node When the execution of a parallel node starts, then the node’s children are executed in succession from left to right without waiting for a return status from any child before ticking the next one. It returns success if a given number of children M ∈ N return success, it returns failure when the children that return running and success are not enough to reach the given number, even if they would all return success. It returns running otherwise. The purpose of the parallel node is to model those tasks separable in independent sub-tasks performing non-conflicting actions (e.g. a multi object tracking can be performed using several cameras).
Selector Node (also known as Fallback)
Behavior for user-defined sequence actions. When the execution of a sequence node starts, then the node’s children are executed in succession from left to right, returning to its parent a status failure (or running) as soon as a child that returns failure (or running) is found. It returns success only when all the children return success. The purpose of the sequence node is to carry out the tasks that are defined by a strict sequence of sub-tasks, in which all have to succeed.
When a child behavior is complete and returns its status code the Composite decides whether to continue through its children or whether to stop there and then and return a value.
The CompositeServer is injected into the user-defined automaton and manages
the lifecycle of their children (the execution nodes), ie. starting, stopping, and handling messages.
All components are children of a composite.
High level automaton_config parsing policy for BT specific user configs.
Node utility decisioning First pass should prioritize composite 'selector' actions based on utility (a priority composite node)
Used for experimentation and QA testing until testing strategy devised.
When a DataRecord enters the Perception System, a new PerceptMemory is created, and as the DataRecord is pushed through the Percept Tree, each percept that registers a positive match adds its data to the new PerceptMemory.
A Tree of Percepts The Perception System takes the form of a Percept Tree. A Percept is an atomic classification and data extraction unit that models some aspect of the sensory inputs passed in by the Sensory System. Given a DataRecord it returns both a match probability (the BirdPercept will return the probability that a DataRecord represents the experience of seeing a bird) and, if the match is above a threshold, a piece of extracted data (such as body-space coordinates of the bird). The details of how the confidence is computed and what exact data is extracted are left to the individual percept. The percept structure might encapsulate a neural net or it might encapsulate a simple “if … then …else” clause. This freedom of form is one of the keys to making the Perception System extensible, since the system makes no assumptions about what a percept will detect, what type of data it will extract or how it will be implemented.