Creating and Editing a Repository

The simplest way to create an SAR is by writing a description of the slots that it should contain as a YAML file. An example of such a file now follows:

#First, invididual (non-grouped) Slots
singles:
  -
    name: Slot A
    description: 'This is a really important Slot'
    type_str: std_msgs/String
    is_shared: False
    is_latched: False
  -
    name: Second Slot
    description: 'This is used for the fundamental process of explanation'
    type_str: std_msgs/UInt8
    is_shared: False
    is_latched: False
  -
    name: Spam
    description: 'May contain Eggs'
    type_str: std_msgs/Float64
    is_shared: False
    is_latched: False
#Then, a description of Slot Groups
groups:
  -
    hosts: ['mpc01','mbot01'] #List of hostnames. If you leave this out or
                            #define it as [], that means that the Slot 
                            #will be instantiated for the ‘default
                            # group’ hosts
    representative: #this is the representative Slot
    name: Is It Raining
    description: 'This is a predicate that will be created both for 
      mpc01 and also for mbot01. That is, in your SAR, you will end up
      with two slots: [mpc01] Is It Raining, and [mbot01] Is It Raining'
    type_str: std_msgs/Bool
    is_shared: True
    is_latched: False

A special note regarding Slot groups: as shown above, these can be defined for a subset of agents, by listing out their respective hostnames in the ‘hosts’ attribute. That list can be omitted (or set to an empty list), in which case the representative Slot will be instantiated for a default list of hosts. The list of hosts of the “default group” is defined in the file ‘monarch_situational_awareness/config/default_group_hosts.yaml’.

If the SAR is modified dynamically (by adding Slots to it via the slot creation service during execution, for example), it is also possible to save the current state of the SAR into a YAML with the above format by using the list_slot_info service. Then you can load the saved configuration file back into the SAM the next time that it is initialized. For example:

$ rosservice call /list_slot_info > my_slot_config.yaml

shut down sam.launch, then:

$ roslaunch monarch_situational_awareness sam.launch repo:=$PWD/my_slot_config.yaml