1.1.3. Scenario Coordination

The scenario coordination service can be used to trigger and arbitrate various interactive subroutines of the apartment, aka scenarios. Scenarios can be executed by sending TaskState objects to the following scope: SCOPE_SCENARIO=/coordination/request/scenario/<ID> (for examples see Task Arbitration), or by using the Button Infrastructure. The scenario coordination internally uses the Allocation Service for the arbitration of parallel interactions and only executes a scenario if it can allocate all needed resources.

Interactive scenarios are modeled as SCXML state-machines that can be generated with a set of domain-specific languages, executed with an rsb-aware executor (see related components) and vizualized with the State Engine Viewer which is part of the coordination. For each scenario, there is a configuration file that specifies default runtime parameters and needed resources.

1.1.3.2. Available scenarios

Currently, the following scenarios can be triggered:

ID Requested routine/scenario Involved components
cleanup kitchen interaction (offer drink, then clean) Dialog Manager (DM)
email remember e-mail address (associate with id-card) Long Term Memory
fsmt run all fsm tests jenkins
lastname remember last name (associate with id-card) Long Term Memory
learnface remember a person’s face (learn face model) face id
mekagrasp tell meka bot to perform grasping demonstration meka robot
mekaintro call meka bot to introduce the apartment meka robot
register register new id-card, store given name in ltm Long Term Memory
reset reset apartment (legacy, use default scene) -

1.1.3.3. Scenario specification

Scenarios are specified as SCXML files that can described in MPS. A set of domain-specific languages that cover SCXML, plantUML, and RSB is used to generate files that are then executed by the rsb-scxml-engine. For development using the DSLs, an IDE used to be available but is not usable at the moment. Instead, the set of languages has to be opened in MPS prior to opening the coordination model. An archive containing the correct versions can be found here.

1.1.3.4. Scenario configuration

All available scenarios are read from a configuration file that resides inside the main coordination repository. If you want to add a new scenario, you have to create a new Ini file containing an optional [resources] and a [parameters] section. These files are evaluated at runtime and trigger the SCXML state-machine specified in the parameters section after the resources have been allocated sucessfully. Additional variables can be specified as parameters and are fed into the datamodel of the SCXML file before execution. Please refer to Resource specification for an overview of allowed values for the [resources] section.The following default values for scenario resources are taken into account but can be overridden:

[resources]
; these are the default values for scenario resources
policy=PRESERVE
priority=HIGH
initiator=HUMAN
duration=600000
ids=/coordination/request/scenario/<ID>
description="scenario: <ID>"

[parameters]
; default (filenames are case-sensitive and start with a capital letter)
scxml=<ID>.xml
; the following are not default values but parameter examples
feedback=true
location=Kitchen
example=".rst.dialog.DialogManagerCommand:{command:RESET_INTERACTION}"

Inside the [parameters] section, a state-machine that should be executed can be specified using the scxml key. Furthermore, arbitrary key/value pairs can be specified to be stored inside the SCXML data model. Values are evaluated as numbers, booleans, or RST data types. Additionally, these parameters can be overridden by using a Dictionary as the TaskState payload when requesting a scenario.

Some scenarios have a feedback parameter that enables text-to-speech output at /home/<location>/saytask/SAY in case the scenario has not been triggered verbally via the Dialog Manager (DM). Also, some scenarios use the location field to trigger a virtual keyboard by calling /home/<location>/virtualkeyboard/command or set a location’s illumination using /home/locationlight/(power|preset). Details can be found in the respective SCXML files.

1.1.3.5. Execution properties

An ABORTED signal is sent to the execution engine if allocated resources are lost, the state-machine should enter a final state with the name TaskState::Aborted as soon as possible. In total, there are are the following special states that are evaluated by the scenario coordination that resemble the TaskState communication pattern (cf. Task Arbitration):

State Meaning Properties
TaskState::Rejected Scenario execution refused final
TaskState::Accepted Scenario execution started -
TaskState::Completed Scenario finished successfully final
TaskState::Failed Scenario finished with an error final
TaskState::Aborted Scenario aborted externally (e.g., resources superseded) final