Revision as of 11:24, 6 August 2020

Service definition principle

Defining a service in Papyrus for Robotics is defining a communication mean between components. A service is indeed a way to synchronize and exchange data between components. It is a generic mechanism, i.e. it is reusable between several components and it is not component-specific.

A service definition is based on a given communication pattern and on a set of associated Communication Objects. Service definitions reference one of the 4 communication patterns identified in RobMoSys. Depending on the communication pattern, a service definition needs to reference one or more communication objects, i.e. the object(s) that are exchanged by an interaction. This is outlined in the following for each pattern:

• Push: a single "message" element
• Send: a single "message" element
• Query: a "request" message and a corresponding "reply" message
• Event: a "message", a "parameter" and a "state" object

For more details on each pattern, see [communication patterns]. A new action/coordination pattern is currently under definition with a "goal", a "response" and a "feedback" object.

A Communication Object defines the data conveyed by a given service. Communication objects and data types have both a set of typed attributes. The only difference is that communication objects can directly be referenced from service definitions. In order to avoid duplicates, the palette of the diagram only enables the creation of the different data-type variants. At any moment, a data-type can be converted into a communication object and vice versa, as shown in the following dialog:

How to edit

We can create a service definition with Papyrus for Robotics in a specific service definition model. We use the palette to create a new service definition. The tool will prompt for the different communications objects. They are either already defined in another service definition model or edited in the service definition model itself.

It is recommended to use a textual editor for editing the data types. This editor is available via the F2 short-cut or inside the property view (the latter is recommended, since the editors directly in the diagram use a constraint area).

As shown below, Papyrus offers an xtext editor provided content assist (control-space) and validation. If the validation does not pass, the editor contents is stored in an annotation awaiting corrections. We can specify attributes along with their type and a comment which becomes part of the attribute's description. In order to obtain completion assistance, we write the prefix of package containing the type (but please note that this only covers models already loaded into the resource set - use the type selection attribute to load additional registered models).

A service definition from scratch

TO BE COMPLETED LATER

Position with respect to the robotics domain

A service definition is a tier-2 activity, i.e. an activity that is typically done by a domain expert. The objective is to define common service definitions usable across several projects and service definitions. These service definitions are typically structured in specific robotics domains such as mapping, planning, localization.

If ROS is targeted, the ROS message and service definitions that are shipped with a distribution are a de-facto standardization of these service definitions and available in Papyrus for Robotics as a set model libraries. However, it is sometimes necessary to define new service definitions. In case of ROS2, service definitions are mapped to the ROS2 counterpart:

• Push and Send: .msg file
• Query: .srv file

Please note, the contents of a communication object appears in the generated message file, not the object itself. For instance, in case of a Query, the CommunicationObject "multIn" does not appear in the QueryMultInMultOut.srv file, but its attributes (xval,yval), as shown below:

# query pattern - request
# attributes of request multIn
uint16 xval
uint16 yval
---
# attributes of response multOut
uint32 result
bool validity