Source:
Report:
Introduction
The purpose of the behavior module is to serve as a common interface for the most used output modules, and in addition provide an easy way to make and execute new behavioral presets and simple states. The behavior module is intended to be interfaced in the same way as the action server states already implemented, to avoid heavy modifications to the controller module. In order to cover the role of a complete action server state for the Cyborg, the module must be able to exploit the emotional state of the Cyborg to choose which behavior to execute in the active state, and provide emotional feedback while doing so. It should also implement a way to change audible and visual modes in certain states, facilitating dynamic behavior while a state is active. A context diagram for the behavior module is seen in Figure 6.1 (AB). The figures have a notation behind then noting which thesis or report to find them in. AB = Areg Babayan, Masters thesis 2019.
Design
The behavior module is designed as a single ROS node, interfaced through the actionlib protocol, all communication with other modules is through ROS protocols. The module connects to the controller module to get the emotional state of the Cyborg, and to provide emotional feedback. The module also connects to the audio and visual modules in order to activate them. If the behavior incorporates navigation, the module activates a client for the navigation module.
The module has a database for behavioral presets where the parameters are loaded from, separate presets can be configured for each emotional state if one wishes to incorporate the emotional state of the Cyborg into the behavior. A behavioral preset defines commands for the audio, visual, navigation module, and emotional feedback. The preset also defines the completion trigger for the behavior, and if the behavior state is dynamic. The trigger can either be a duration, or completion of audio or navigation execution, callbacks are used in order to handle the executional feedback from these modules. When a behavior state is dynamic, it is possible to activate different behaviors in the same behavior state, this is done by publishing a command to the behavior module. The reasoning for including this option is that for states with relative long duration, for example a state where the Cyborg is following a long path, it can be restrictive to only be able to execute one type of visuals or audio. As most long lasting states are navigational states, the dynamic behavior commands are limited to only activating the audio or visual module. A class diagram for the modules action server Python class is presented in Figure 6.2 (AB).
Implementation
The behavior module is implemented as a single Python class BehaviorServer, instantiated by the ROS node cyborg_behavior. It provides behavior states through an action server, utilizing the StateMachine.action action file implemented in the controller module. Behavioral presets are saved in the modules launch file behavior.launch, which is accessed through the ROS parameter server. The form of a behavioral preset is as follows:
<rosparam param = "preset_name">
visual_mode: "visual_command"
playback: "playback_command"
utterance: "utterance"
navigation_order: #Can be "navigation_go_to", "navigation_wander" , or "navigation_dock".
location: "location"
dynamic: True #Omit if False. True if state permits behavioral changes while active.
completion_trigger: #Can be "navigation", "utterance", "playback", or "time xx" ,where xx is the duration in seconds.
timeout: #Set False to disable behavior timeout, set duration in seconds to configure, omit if default value is
used.Parameters not relevant for a preset can be omitted in the launch file when configuring new presets, default values are used by the module if it cant find certain parameters for the behavioral preset, as indicated in the example above. Comments and spaces have been added for readability, and are not part of an actual preset.
As seen in the class diagram presented in Figure 6.2 (AB), the behavior module uses ROS topics to connect to the other modules, callbacks are implements all subscribers. In addition, an action client is used to interface the navigation module, utilizing the Navigation.action action file implemented in the navigation module. For behaviors involving navigation to a specific location, there are multiple ways to supply the location. The location can be defined in the behavioral preset, it can be published on the /cyborg_behavior/command_location topic before activating the navigation state, or it can be sent with the action goal for the module, by supplying the location name in the "order" field of the StateMachine.action action message. The different options were included in order to facilitate less modifications to the old software structure. A simplified activity diagram for the behavior module is presented in Figure A.1 (AB).
A description of the functions in the module is given:
| Function | Description |
|---|---|
emotionalcallback | Callback for the subscriber to topic /cyborgcontroller/emotional_state. Updates the modules emotional state variable when a message is received. |
callback_command_location | Callback for subscriber to topic /cyborg_behavior/command_location. Updates the modules commandlocation_ variable when a message is received. |
server_behavior_callback | Callback for the /cyborg_behavior action server. When an action goal is received, the callback checks if the requested preset exists, first by appending the name of the behavioral state to the name, and then without if no preset for that particular emotional state is found. If no preset at all is found, the callback sets the server state as aborted and returns. If the name of the requested preset is found, the enter and execute_behavior functions are executed in sequence. |
enter | Executed by server_behavior_callback. Retrieves parameters for the behavioral presets and updates the corresponding variables in the module. If the preset involves navigation, an action client for the navigation modules action server is instantiated. |
execute_behavior | Executed by server_behavior_callback. Activates the different output modules, for the navigation module it sends navigation goal, while for the audio and visual module, commands are published on their respective topics. The function checks the behavior_finished variable to see if the behavior is finished, the state of the navigation server when it is used, and for preemption request from the module using the behavior action server. If navigation or the behavior server is preempted, a preemption command is sent to audio modules utilized in the current preset. When the behavior is finished, send_emotion is used to provide emotional feedback to the Cyborg controller. |
callback_dynamic_behavior | Callback for the topic /cyborg_behavior/dynamic_behavior, only active when the parameter for dynamic behavior is set. Parses message and activates the corresponding output modules. |
callback_navigation_done | Callback for the navigation module. Sets the behavior finished variable when called. |
change_behavior | Called by callback_dynamic_behavior when a behavior command is intercepted. Retrieves behavioral parameters for the audio and visual module and executes. |
callback_playback | Callback for topic /cyborg_audio/feedback_playback, handles feedback for audio playback and sets the behavior_finished variable accordingly. |
callback_text_to_speech | Callback for topic /cyborg_audio/feedback_text_to_speech, handles feedback for text to speech and sets the behaviorfinished_ variable accordingly. |
send_emotion | Publishes emotional feedback when executed. |
How to add new bahviour
New behavioral presets are configured by appending the desired preset to the behavior.launch file in the behavior module. Presets are added to the Cyborg state machine in the same way as other action server states, shown in the following code:
smach.StateMachine.add("<state name>",
Module("<preset name>", "cyborg_behavior", transitions, resources),
transitions, sm_remapping)Where <state name> and <preset name> is replaced by the chosen state and preset name, which usually are identical.