Logo

A Language for Interactive Cooperative Agents

View the Project on GitHub rapyuta-robotics/alica

Conditions

Conditions are just like behaviours, one of the four core concepts in the ALICA Framework, that encapsulate domain-specific code. Hence, the domain-independent ALICA Framework handles conditions as black-boxes. From the perspective of the framework, conditions can be true or false and the conditions must provide a method to determine their current truth value.

Further, the ALICA language distinguishes between three different kinds of conditions: pre-, runtime, and postconditions. A precondition must hold before something is done. The runtime condition must hold before and while something is done. And finally, the postcondition is only expected to hold after something has been done.

Please note the different semantics between postconditions and the other two conditions. While pre- and runtime conditions control the progress of an ALICA program, the postconditions have no influence on that at all. Their simple purpose is to allow the designer of an ALICA program to express what outcome is expected from a certain element. This, for example, allows the application of classic planning algorithms to the ALICA language. Since planning is currently not supported by the ALICA Framework, postconditions are not used at runtime.

Condition Context Semantics
Precondition Transition A transition can only be passed, if the precondition holds.
  Behaviour A behaviour can only start, if the precondition holds.
  Plan A plan can only start, if the precondition holds. The precondition is checked only after a complete task assignment is computed for the plan, because the precondition can refer to the task assignment.
Runtime Condition Behaviour A behaviour can only start and run, if the runtime condition holds. Therefore, a runtime condition is continually checked and the behaviour is stopped, if the runtime condition does not hold anymore.
  Plan A plan can only start and run, if the runtime condition holds. Therefore, a runtime condition is continually checked and the plan is aborted, if the runtime condition does not hold anymore. The runtime condition is checked only after a complete task assignment is computed for the plan, because the runtime condition can refer to the task assignment.
Postcondition Terminal State If an agent reaches a terminal state, the postcondition is expected to hold.
  Behaviour If a behaviour is successful, the postcondition is expected to hold.

Table 1: Overview of Conditions with their Contexts and Semantics in those Contexts

Table 1 gives a concise overview of all three condition types, together with the core concepts, where they are used and their corresponding semantics in these contexts.

NAV prev: Finite-State Machines top: Overview next: Entrypoints