Revision as of 18:03, 2 July 2020

Service definition (Tier 2)

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.

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
• Action: a "goal", a "response" and a "feedback" object

For more details, see [communication pattern] (and ROS2 for information related to ROS2 code generation).

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

ROS2 mapping

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 "AddRequest" does not appear in the .srv file, but its attributes (x,y)

Q_AddServiceDef : binds the Request->AddRequest, Response->SumReply, but the resulting .srv file looks like this

# query pattern - request
# attributes of request simple::srv::AddRequest
int16 x
int16 y
---
# attributes of response simple::srv::SumReply
int16 sum

Data Type / Communication object definition

Papyrus-for-Robotics allows the user to define his own communication objects and data types. Both have 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

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. The user can specify attributes along with their type and a comment which becomes part of the attribute's description. In order to obtain completion assistance, 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).