ROS Interfaces Description

At the current state of the CPSwarm project, most of the functionalities offered both by the Abstraction Library and by the Swarm Library are exposing common ROS interfaces:

• ROS Service: short running tasks, such as moving up and down an elevator or taking a photo from a camera, can be activated using services.
• ROS Action: for long running and computational expensive operations (e.g. moving to a specific position or letting a drone to take off), the ROS actionlib package is usually preferred.

In order to use all these functionalities inside a complex algorithm in the form of a Finite State Machine (as explained here), their APIs need to be correctly described. For this purpose, the SCXML standard has been adapted to describe both these interfaces to let the Code Generator produce the final algorithm code that, in this particular case, will be a ROS node containing a Finite State Machine implemented using the SMACH library. SMACH provides specific support to call services and actions from a State, respectively ServiceState and SimpleActionState. Therefore, the SCXML file has to contain all the information needed to correctly instantiate both these classes using the right parameters.

All the information needed by the Code Generator and how to format them inside the SCXML standard will be described in the following sections

ROS Service

As stated above, SMACH provides a state class that acts as a proxy to a ROS service. To correctly instantiate a ServiceState, the Code Generator needs the following data:

• service name
• service type
• service request generation policy (empty, fixed, userdata, callback)
• service response generation policy (userdata, callback)
• mappings

<state id="ServiceExample">
   <datamodel>
      <data id="invoke">
         <rosservice>
            <name>service_example</name>
            <srv>ServiceExample</srv>
            <request type="fixed">
               <param>"param_value"</param>
            </request>
            <response type="userdata">
               <var>variable_a</var>
            </response>
         </rosservice>
         <mappings>
            <x>state_userdata</x>
            <y>global_userdata</y>
         </mappings>
      </data>
   </datamodel>
   <invoke type="ROS_SERVICE" />
   .
   .
</state>

ROS Action

SMACH has specific support to call actions and provides a state class that acts as a proxy to an actionlib action. To correctly instantiate a SimpleActionState, the Code Generator needs the following data:

• action name
• action type
• action goal generation policy (empty, fixed, userdata, callback)
• action result generation policy (userdata, callback)
• mappings

<state id="ActionExample">
   <datamodel>
      <data id="invoke">
         <rosaction>
            <name>action_example</name>
            <action>ActionExample</action>
            <goal type="callback"/>
            <result type="empty"/>
         </rosaction>
         <mappings>
            <x>state_userdata</x>
            <y>global_userdata</y>
         </mappings>
      </data>
   </datamodel>
   <invoke type="ROS_ACTION" />
   .
   .
</state>