Primary States

OBS OBS!

The navigation stack is being completely overhauled meaning this may not be accurate any more.

Introduction

The primary states module gathers action server states with more complex behavior than provided by the Behavior module, and states that do not use output modules, the old wandering, idle, and navigation_planning states are reimplemented here. The module provides emotional feedback to the controller while active, and can execute state changes in the Cyborg by publishing events. If behavioral outputs are needed, the Behavior module is also interfaced. A context diagram for the module is presented in Figure 9.1 (AB = Areg Babayan's masters thesis 2019).

Design

The module is designed as a single ROS node, providing states through a ROS action server. In order to save resources, all states are provided through the same action server, using the callback for the action server to execute the wanted function based on the action goal. The module connects to the controller module to get the emotional state of the Cyborg, provide emotional feedback, and register events leading to state changes. For states using output modules, Behavior is also interfaced. A class diagram for the module is seen in Figure 9.2 (AB).

Wandering Emotional State

Based on the wandering action server state previously implemented in the navigation module. The state activates a wandering behavior in the behavior module, and preempts itself when the emotional state of the Cyborg changes to something other than "bored", "curious", or "unconcerned".

Navigation Planning State

Based on the navigation_planning action server state previously implemented in the navigation module. The state executes when the Cyborg state machine receives a "navigationschedular" or "navigation_emotional" event. It checks the current emotional state of the Cyborg and selects how and where the Cyborg should move, before providing emotional feedback and initiating a state change.

Implementation

The module is implemented according to the class diagram presented in the previous section, ROS topics are used for communication with the controller and behavior module. The module provides its states as a single ROS action server that utilises StateMachine.action actions, and interfaces Behavior through an action client when needed:

Function	Description
`callback_server_primary_states`	Callback for the action server, checks the action goal and executes the corresponding function.
`emotional_callback`	Callback for the emotional state topic.
`create_and_send_behavior_goal`	Used to create and send action goals to the Behavior module.
`actionloop_check`	When executed, checks for preemption requests for the active state, and the executional status of the Behavior action server. Sets the terminal state of the action server according to the terminal state of the behavior server.
`wandering_emotional`	Activates wandering behavior in Behavior, preempts the state when the Cyborg is in the wrong mood.
`navigation_planning_state`	Based on the old `navigation_planning` state. Activated by either a navigationemotional or navigationschedular event. Checks the emotional state of the Cyborg, and decides and activates the next state. If the next state is `navigation_go_to`, the location is published on the `cyborg_behavior/command_location` topic for the Behavior module, before the state change is executed.
`change_state`	Executes a state change by publishing events on the corresponding topic.
`send_emotion`	Used for publishing emotional feedback to the controller, by publishing a EmotionalFeedback message on the corresponding topic.

How to implement new states

New states are implemented as standard Python functions and then added to the callback function callbackserverprimary_states in order to make them available. An example is given:

def example_state(self):
  ### Implement state behavior here ###
  self.create_and_send_behavior_goal(behavior = "example_behavior")
  while not rospy.is_shutdown():

    ### Implement state  executional checks here ###
    if self.actionloop_check() == True:
      return
    
    self.RATE_ACTIONLOOP.sleep()

  # set terminal goal status in case of shutdown
  self.server_primary_states.set_aborted()

A state with name "example_state" is defined on line 1.
State behavior is implemented before the while loop.
On line 5 function create_and_send_behavior_goal is used to send action goal "example_behavior" to the behavior module.
Variable and state execution checks are added inside the action loop.
action_loop function is used to check the action goal state of the behavior module on line 10, terminating the loop on line 11 and ending the state if the behavior module is finished or has stopped for some reason.
The loop is suspended on line 13.
And the terminal goal status for the action server is set on line 15 in case the while-loop exits for some unexpected reason.

Page tree