Synthesis of Robotic System Controllers Using Robotic System Specification Language

Robotic System Specification Language (RSSL) stems from the embodied agent approach to robotic system design. It enables the specification of both the structure and activities of a multi-robot multi-agent robotic system. RSSL specification can be verified and automatically transformed by its compiler into a six-layered Robotic System Hierarchical Petri Net (RSHPN). RSHPN models the activities and structure of the designed robotic system. The automatically generated RSHPN is loaded into RSHPN Tool modeling RSHPNs and automatically generating the controller code. This approach was validated on several robotic systems. The use of RSSL and RSHPN facilitates the synthesis of robotic system controllers.


I. INTRODUCTION
A S the European SPARC project [1] indicates Model Driven Engineering (MDE) approach will play an important role in the design of robotic systems. It provides a toolchain composed of models, transformation mechanisms, and modeling languages (i.e. General Purpose (GPMLs) and Domain Specific (DSMLs) Modeling Languages). The MDE approach is ideal for the whole development process of complex, multi-domain systems, e.g. robotic systems. Unfortunately, MDE still faces many challenges [1], [2].
The majority of existing robotics MDE approaches use internal DSMLs (relying on the syntax and the execution semantics of their host languages) [2]. Internal DSLs are based on GPMLs, such as UML [3] (e.g. RobotML [4]), SysML [5], graphical DSMLs as used by SmartSoft [6]), and most popular in robotics Ecore (32 MDE approaches out of 63 analysed in [2] have used DSMLs based on Ecore. Internal DSMLs are bound to the execution context [7], i.e. translator, of the host language, which may result in a shift toward a platform-dependent model. In contrast to internal DSMLs, external DSMLs define their own syntax and semantics, thus typically rely on a fewer number of concepts, moreover directly associated with the application domain, and use simpler notation [8]. Manuscript  Another problem often encountered in robotic MDE is the lack of a holistic abstract view of the general robotic system. Many of the existing model-based approaches focus mainly on modeling specific subdomains and types of robot tasks [7]. 60% of MDE approaches out of 63 analysed in [2] focus on terrestrial robots and robotic arms, neglecting other robots, not to mention a holistic view of a robot in general. As a result, the designer has no guidance on how to build the system from components. But the robot model should represent an integrated system, not a set of components [9]. DSLs used in robotics focus mainly on the implementation phase of the design process (93% of the papers surveyed in [7]), and only to a negligible extent on system specification (only 14 of the papers surveyed in [7]). Those focused on specifying robotic systems, are limited to only certain parts of the system, as in the case of [10], where only a set of skills is considered. Out of 137 articles analysed in [7] only 5 concerned DSLs taking into account architectural patterns, i.e. the majority of MDE approaches in robotics: 1) does not clearly guide the developer in the design of a robotic system, and 2) does not separate specification from implementation, thus rendering the utilised architectural pattern obscure, as pointed out by [11]. 54 MDE approaches out of 63 considered in [2] does not foster decoupling between the modeling concepts and the implementation technology. Moreover, the lack of explicit separation of the specification and implementation phases implies: 1) inability to develop platform independent model of a robotic system; 2) difficult integration with other languages/tools; 3) reduction of possible reuse of the developed model. From all this, we conclude that it is necessary to develop an external DSML language to express the activity of the whole robotic system. Here we propose a language, i.e. RSSL, which uses the concepts from the field of robotics, i.e. the embodied agent approach [12], [13], and facilitates the determination of parameters necessary to obtain the holistic model of a robotic system based on parameterised (RSHPN) [13]. This paper is structured as follows. Section II presents the contribution, Section III introduces the robotic system architectural pattern and RSHPN meta-model. Section IV presents RSSL, Section V describes the developed tools, Section VI focuses on data translation, while Section VII describes the conducted experiments. Section VIII presents the discussion and Section IX draws conclusions.

II. CONTRIBUTION
In our latest works the activity of a whole robotic system was modeled using RSHPN (Fig. 1). This article is an extension of work [13], where a parametric RSHPN meta-model was proposed. Based on RSHPN meta-model and the provided This work is licensed under a Creative Commons Attribution 4.0 License. For more information, see https://creativecommons.org/licenses/by/4.0/ parameters the RSHPN model (modeling the activity of a whole robotic system) emerges. The main contribution of this paper is the developed RSSL language and its compiler. RSSL expresses the parameters for a parametric RSHPN meta-model. Based on the developed RSSL specification and the RSHPN meta-model, the RSSL compiler generates the RSHPN model ( Fig. 1) out of which the source code of the robotic system controller is generated. RSSL is a DSL facilitating the specification of multi-agent robotic systems RS. It is based on the concepts derived from robotics, in particular it uses the Embodied Agent Approach (EAA) [13], [14] (Section III). RSSL enables the specification of a robotic system in a multi-layered and modular manner. It first defines the specification of the system structure and then its activities. RSSL uses a context-free grammar [15]. However, the language compiler analyses context sensitive dependencies at the semantic analysis stage. Moreover, RSSL is target language independent. As the result of indirect translation (Section VI), the RSSL specification is transformed into: ROS based Python or C++ code.

III. EMBODIED AGENT APPROACH (EAA)
The methodology of designing multi-agent robotic control systems [13], [14], [16] uses a general robotic system metamodel separately describing system structure and activities.

A. Structure
A robotic system is composed of a set of embodied agents [12], [13], [16] (Fig. 2). An embodied agent a j ∈â (jname of the agent,â -a set of agents) consists of the following subsystems: control subsystem c j , real receptors R j,l ∈R j (lname of a real receptor), real effectors E j,h ∈Ê j (h -name of real effector), virtual effectors e j,n ∈ê j (n -name of virtual effector) and virtual receptors r j,k ∈r j (k -name of virtual receptor). Receptors R j,l gather data from the environment and deliver it, in the form aggregated by r j,k , to c j . Based on the received data and the task c T j,c that is to be executed, c j sends control commands, which are transformed by e j,n , into a form accepted by E j,h , in order to affect the environment. Each subsystem s j,v contains: internal memory s s j,v , set of input buffers xŝj,v and set of output buffers yŝj,v . Input and output buffers are used to communicate between subsystems through communication channels, i.e. ss j, (v,h) ∈ŝs j (channel between s j,v and s j ,h ). Virtual subsystems communicate only with their associated real subsystems and the control subsystem. Communication between agents occurs only between their control subsystems. Internal memory and buffers are labeled systematically in [13]. The symbol consists of a center letter indicating the type of the subsystem s, where s ∈ {c, e, r, E, R}; the left subscript denotes the buffer type: 1) x -input, 2) youtput and 3) no subscript -memory; left superscript defines the type of subsystem with which the buffer communicates; right superscript denotes the discrete time stamp i; right subscripts determine the names of: agent and subsystem.

B. Activity
The activity of a robotic system depends on the activities of its agents, while the activities of agents results from the activities of their subsystems. Each subsystem s j,v performs a task s T j,v which involves selecting one of the behaviours s B j,v,ω to be executed, where ω is behaviour designator. The behaviour is selected based on the satisfied initial condition s f σ j,v,α ∈ sf σ j,v (α -predicate designator) [14]. Each behaviour iteratively: 1) calculates the transition function s f σ j,v,ω ∈ sf j,v (Eq. (1)), takes as arguments the current data from the input buffers 2) transmits y s i+1 j,v to associated subsystems, 3) increments discrete time counter i, 4) receives data from the associated subsystems into x s i j,v , 5) checks terminal condition s f τ j,v,ξ ∈ sf τ j,v and error condition s f j,v,β ∈ sf j,v , where ξ and β are designators of those predicates. Behaviour iteration terminates when one of those conditions is fulfilled. In such a case the subsystem s j,v selects the next behaviour based on s T j,v . Each s f j,v,ω can be canonically decomposed into partial functions, and each partial function can be decomposed based on data availability into overloaded functions.
For a pair of communicating subsystems, the communication mode must be indicated. There are nine communication modes, three each for sending and receiving subsystem. These are: 1) non-blocking, 2) blocking, and 3) blocking mode with timeout. In non-blocking mode the subsystem does not wait for the other subsystem, but immediately resumes its activities, while in blocking mode it waits. A single parameterised Petri net structure covering all three communication modes is defined [13]. They are distinguished by the timeout parameter (i.e. 0 -non-blocking; ∞ -blocking; value > 0 -blocking with timeout).

C. RSHPN Meta-Model
The interaction of agents, subsystem tasks, behaviours, transition functions and communication modes is described by a single RSHPN H in Fig. 3. Such a net is a bipartite graph, in which nodes, i.e. places p (graphically represented by single circles) and pages P (double circles), alternate with transitions t (rectangles), all connected by directed arcs (arrows). The pages represent lower level HPNs (drawn as panels connected to their corresponding pages by dashed arrows). Each such network has one input place p in and one output place p out . Logical conditions C are associated with transitions, while operations O label places. A correctly constructed H network is safe, and therefore no more than one token (represented by a black circle) can exist at any of its places. The H network consists of the following layers (precise description is available in [13], [14]): 1) Multi-Agent Robotic System Layer: Defines a single net H representing the activities of each agent a j defined by individual pages P j (a page is a lower order Petri Net).
2) Agent Layer: Defines nets H j represented by pages P j . Each net describes the activities of an agent a j , which consists of several subsystems. The activities of each subsystem s j,v are represented by an individual page s P j,v .  (1), page s PB j,v,ω,snd (defining the communication mode of s f j,v when sending data from y s j,v ) and page s P B j,v,ω,rcv (defining the communication mode of s j,v when receiving data into x s j,v ), 5) Action Layer: defines 3 Petri nets (further decomposed into 2 layers [13], [14] j,v,ω -determining communication mode used by the sender and receiver, respectively. The meta-model H thus defined can be transformed into a model of any robotic system (after specifying Petri nets with variable structures and defining parameters from Table I).

A. Meta-Language
The RSSL grammar is expressed using EBNF. The RSSL symbols are consistent with the meta-language: 1) X -nonterminal symbol X, 2) X -terminal symbol X, 3) [ ] * -multiplicity from zero to infinity, 4) [ ] + -multiplicity from one to infinity, 5) [ ]? -either zero or one time, 6) | -alternative. RSSL keywords and parameters are terminal symbols. They are differentiated by using capital letters to express keywords and lowercase letters to write parameters. Non-terminal symbols use capital letters too, however they are enclosed within angle brackets. RSSL blocks are preceded by a keyword and followed by the same keyword prefixed by END_ (e.g. X defines a RSSL block starting with the terminal symbol X and finishing with END_X).

B. RSSL syntax
The simplified grammar of RSSL is presented in Fig. 4-7. The non-terminal symbols of the grammar represent the domain concepts which are expressed in the form of language blocks, e.g.: ROBOTIC_SYSTEM ; AGENT ; CS , VE and VR using SUBSYSTEM pattern;    SUBSYSTEM_TASK ; BEHAVIOUR ; CONDITION and TRANSITION_FUNCTION . Those blocks, presented in the form of syntax diagrams, define the RSSL language. Order of declaring the blocks associated with those non-terminal symbols is not enforced by RSSL. Non-terminal symbols defining partial functions and conditions contain code blocks CODE with code directly written in the target language (C++ or Python).
1) ROBOTIC_SYSTEM : (Left side of Fig. 4) -defines a robotic system RS with a non-empty set of agents (i.e.â) and a set of inter-agent channels (i.e.âa).
2) AGENT : (Right hand side of Fig. 4) -defines agent a j where j ≡ agent_id. It specifies the agent's name j, a single control subsystem (c j ), a set of virtual effectors (i.e.êj), a set of virtual receptors (i.e.rj), a set of intra-agent communication channelsâa j , i.e. channels utilised for communication between subsystems of a j , and if necessary the auxiliary files and data types.
3) CS , VE , VR : Use the same SUBSYSTEM pattern (left side of Fig. 5) to model the subsystem activity and structure. It specifies: 1) v -the subsystem name, 2) frequency at which behaviours of the subsystem iterate, 3) s T j,v -subsystem task (where j indicates the agent name), 4) sB j,v -a non-empty set of behaviours, 5) sf σ j,v -a set of initial conditions, 6) sf τ j,va non-empty set of terminal conditions, 7) sf j,v -a non-empty set of error conditions, 8) sf j,v -a non-empty set of transition functions, 9) s s j,v -an internal memory buffer, 10) xŝj,v , yŝj,v -sets of input and output buffers. All condition types are defined using CONDITION pattern (right-top of Fig. 6), while buffer types using BUFFER pattern (right-bottom of Fig. 6). 4) SUBSYSTEM_TASK : (Right hand side of Fig. 5) -defines the task s T j,v executed by a subsystem s j,v . The SUBSYSTEM_TASK block defines three different sets: 1) a set of nodes defined within NODES block, 2) a set of edges defined within EDGES block, and 3) a set of connections defined within CONNECTIONS block. The s T j,v in RSSL is a graph (with specified initial node) connecting alternately elements from the first two sets, i.e.: set of nodes defined in NODES block and a set of edges defined in EDGES block. The elements from different sets are connected with each other by a connection defined in the CONNECTION block (as presented in exemplary listing on right hand side of Fig. 9). Each node is associated with a single behaviour, while each edge with a single initial condition. A connection defines a switch between two behaviours when the condition associated with the edge is satisfied. As a result, s T j,v defines the subsystem s j,v activities by specifying how it switches between behaviours on the basis of initial conditions. 5) BEHAVIOUR : (Left side of Fig. 6) -defines a single s B j,v,ω or a set of behaviours sB j,v,ω (separated by semicolons) for s j,v . For each behaviour it specifies its name ω and three components defined within s j,v , i.e. 1) transition function s f j,v,γ ∈ sf j,v , 2) terminal condition s f τ j,v,ξ ∈ sf τ j,v and 3) error condition s f j,v,β ∈ sf j,v,β .   Fig. 7)defines a transition function s f j,v,γ , represented by (1), specified for s j,v , which is utilised as a parameter describing a behaviour s B j,v,ω ∈ sB j,v,ω . The transition function s f j,v,γ is composed of a set of partial functions (defined within PARTIAL_FUNCTION ). While PARTIAL_FUNCTION (right of Fig. 7) -defines a partial function s,s f j,v,γ,ψ , i.e. specifies: 1) the output buffer (based on which the canonical decomposition of transition function is done) to which the calculated data is inserted, 2) the partial function name, and 3) a sequence of input buffers (separated by a comma) being the arguments of the partial function. Decomposition of the partial function into overloaded functions is done by determining multiple PARTIAL_FUNCTION blocks defining overloaded functions with the same name, but with a different set of input buffers and different implementations. An overloaded function is needed to compute a new value for the output buffers based on the currently available data from a subset of the input buffers. Each partial function by default has access to the internal memory buffer s s j,v , thus it is not necessary to specify it within the function definition. While block INTRA_AGENT_CHANNEL defines communicating channel ss j, (v,h) ∈ŝs j between two subsystems, e.g. s j,v and s j,h , residing in the same agent a j .

V. DEVELOPED TOOLS
Two different tools to support the design of robotic systems were developed: 1) the RSSL compiler -verifies the correctness of the provided specification and transforms the RSSL specification into RSHPN specification, and 2) RSHPN Tool -used to load the RSHPN specification, extend it, and to generate controller code (both in C++ and Python). As the RSHPN Tool has already been presented in detail in [13], [14] and in the video [17], only the RSSL compiler is discussed below. The task of the RSSL compiler can be divided into two stages: 1) analysis of the supplied specification, and 2) generation of the RSHPN specification.

A. Analysis of the Specification
The aim of the first stage is to detect errors by performing: lexical, syntactic and semantic analysis. Since the context-free grammar of RSSL provides freedom to the designer to define blocks in a fairly arbitrary configuration, there is a need to equip the RSSL compiler with contextual correctness analysis assuring that: 1) there are no name collisions, 2) the referred concepts are already specified, 3) communication channels are correctly specified, 4) the multiplicity of the concepts used is correct etc.

B. RSHPN Generation
In the second stage the RSSL compiler transforms the RSSL specification into the RSHPN specification. Thus the parameters specified in Table I are retrieved from the RSSL specification and then two sets of XML files are generate, based on them and the RSHPN meta-model. One type of file expresses the structure of the Petri net, i.e. appropriately parameterised places, transitions, and edges (indicating the activity of the robotic system), and the other specifies the structure of the designed robotic system.

VI. DATA PROCESSING -TRANSLATION
The general scheme of generation of a RSHPN model and the translation of the model into target code is shown in Fig. 8. The data processing pipeline consists of two-phases: 1) RSHPN model generation based on a set of parameters provided by the RSSL specification and based on a general RSHPN meta-model, and 2) model-to-code transformation executed by RSHPN Tool [13]. Together they produce the target code, i.e.: 1) C++ ROS code [14], or 2) Python ROS code [13] -of a robotic system controller. The idea of extraction of parameters from the RSSL specification follows directly from Section IV-A. Fig. 9 illustrates how the parameters are extracted from the RSSL specification, while Fig. 10 shows how the corresponding RSHPN layers are generated from them. The detailed transformation between RSHPN model and controller code was presented in [13], [14].

VII. EXPERIMENTS
In order to verify the suitability of RSSL for the specification of robotic systems, several systems of different complexity were created, viz. 1) a real table-tennis-ball collecting robot with a variable controller structure [13] (Fig. 11(a), 2) simulation of a LWR4+ manipulator tracing circles [14] (Fig. 11(b), [17]), 3) simulation of the Velma robot transferring balls [13] ( Fig. 11(c) and video 1 ), and 4) a simulated and real Velma robot visually tracking an object (Fig. 11(d) and video: simulated 2 and real 3 ). The two first systems were created from scratch, while for  Fig. 9), (right) c H j3,cs (as c P j3,cs from H j3 ) based on specification (right Fig. 9). two others a higher control layer was specified to control already existing Velma robot controller [18], both real and simulated.
The controller for each of the above experiments was expressed as an RSSL specification and then converted into the RSHPN model. Then, using the RSHPN Tool (as shown in video [17] or in [13], [14]), the resulting RSHPN model was automatically transformed into the controller source code (either Python or C++). The number of parameters that need to be specified in order for the meta-model to be transformed into a model, and space limitation, do not allow these specifications to be presented here. Nevertheless, Fig. 12 shows an excerpt from the RSSL specification defining the structure (Fig. 13) of the table-tennis-ball collecting robotic system. The platform was equipped with omnidirectional wheels, electric motors, two cameras, four sonars, a microphone and a controlled ballsucking device. The robot performed the task autonomously or teleoperated (using voice commands). The result was a system consisting of six agents (a detailed description of the system activities is presented in [13]).

A. Complexity Comparison Between RSSL and RSHPN
Two equations were proposed to compare the complexity of the model expressed using RSHPN (2) to that expressed with RSSL (3). O model is examined by calculating a sum of: 1) all the necessary elements (places/ pages, transitions, and edges), and 2) the number of their parameters, needed to define RSHPN H. O model examines the total number of terminal symbols used to specify the robotic system using RSSL.
Although in each case different concepts are used the workload of specifying them is similar. For a fairly simple system, consisting of: 5 agents, each having exactly 5 subsystems, each containing exactly 5 behaviours, 5 input and 5 output buffers, the resulting RSHPN contains a total of 173409 elements, while RSSL specification contains 27188 terminal symbols. It is nearly 6 times less compared to the RSHPN size. This result has been obtained assuming: 1) | sf σ j,v | = | s B j,v |, and 2) each partial function is decomposed into two overloaded functions. Nevertheless, in addition to the symbols necessary to define the above parameters, the RSSL language syntax includes auxiliary terminal symbols increasing the readability of the specification, i.e.: commas, parentheses and semicolons. Ultimately, for | xŝj,v ≥ 14 the RSSL becomes more complex than RSHPN representation of the system. This is due to the proliferating number of auxiliary symbols 2 | xŝj,v | · (| xŝj,v | + 1) when 2 | xŝj,v | combinations of overloaded functions are considered. It is possible to reduce the complexity of the RSSL language syntax, e.g. by removing auxiliary symbols, but at the cost of reduced readability of the specification.

B. Comparison Between RSSL Specification and Automatically Generated Controller Code
An RSSL specification consists of intrinsic RSSL code and code blocks containing Python or C++ code. The latter contain invocations of library code or legacy software. The capability of combining the two types of code significantly simplifies the enhancement of preexisting systems, e.g. Velma. However, even in the case of designing a system from scratch the definition of transition functions and the diverse conditions is usually done using the underlying implementation language or an existing framework, e.g. ROS. The use of RSSL does not force the developer to posses excessive ROS or programming skills. The user-defined code can be just a simple list of consecutively executed instructions. Due to this, the developer can concentrate mainly on determining the structure and the activities of the robotic system, treating the programming aspects as of secondary importance. Table II shows the significant benefits of RSSL language. Several conclusions can be drawn from it. The more complex the structure of the system under development, the proportionally more controller code is generated (excluding user-defined code). This is particularly evident in the first (17 times benefit) and last experiment (8.63 times benefit). In the case of the third experiment for which only a single subsystem was generated, the benefit is the smallest, i.e. 6.85 times.
The more complex the robotic system, the more code needs to be defined within the code blocks in RSSL specification. In the first and third experiment the relation between user-defined code (Python/C++) and intrinsic RSSL code is 9.86 and 4.98 respectively. This is because both experiments used additional external systems, tools and libraries. Therefore, it was necessary to define additional code in INCLUDE blocks. Furthermore, for both experiments it was necessary to define many overloaded functions which significantly increased size of the user-defined code in RSSL specification. Furthermore, as can be seen from the second experiment, it is possible to develop a library of overloaded functions. As a result, the designer's task would come down only to selecting the appropriate transition function from the library, and as a result, the code necessary to define an overloaded function would be reduced to a single function call. The advantage of this approach would be the reusability of existing code, while minimising the work done by designer.

C. Applicability of RSSL to Complex Robotic Systems
RSSL is a tool resulting from a long evolution of robotic system design methods elaborated at our laboratory [16]. This evolution not only improved and extended the concepts underlying RSSL but tested their utility on fairly complex systems, e.g.: a controller of an industrial robot having a serial-parallel manipulator structure [19], a two-manipulator robotic system solving the Rubic's cube puzzle [20], robots utilising positionforce control [21], visual servoing [22], [23], stigmergic communication of independently acting robots [24], multi-robot system acting as a fixture in aircraft part machining [25] and robot companion having variable controller structure [26]. The concepts underlying RSSL, which were tested on those systems, are fairly independent of each other, thus they support decomposition facilitating robot system design. RSSL by using those concepts provides the metamodel being the scaffolding for any robotic system. Metamodel parameters, when appropriately defined, transform this metamodel into a model of a particular system. Definition of each of those parameters is independent of the definitions of others. Thus an increase of complexity of the designed system neither introduces extra complexity into the design process nor increases the complexity of the task. It simply enlarges the number of the parameters that have to be defined. Hence, RSSL scales well for large systems.

IX. CONCLUSION
RSSL facilitates the specification and implementation of robotic systems at different levels of abstraction, starting at the robotic system level and ending with the inter subsystem communication modes. The RSSL specification of a robotic system is decomposed naturally into structure and activities of each of its subsystems. The thus produced specification is subsequently translated into the code of a robotic system controller ready to be compiled by a general purpose language compiler. The RSSL specification defines all parameters necessary to obtain RSHPN model from parameterised RSHPN meta-model. It can be seen from the experiments that the introduction of the parameterised RSHPN meta-model has made the process of creating robotic system controllers easier and more efficient. The designer's task is only to define the relevant parameters defining the structure and activity of the system using only concepts from the domain. Obviously this still requires some effort from the designer, but as it was shown, a significant benefit of the proposed approach is apparent. Other elements of the system, e.g. those related to the RSHPN-based approach, are automatically generated so that the designer does not have to focus on them at all.
Using our design methodology, it is possible to develop a robotic system controller, either as a whole or limited to just a fragment of the controller communicating with an already existing fragment of the system. There is no need to design an entire robotic system from scratch each time -it suffices to extend the existing controller with higher layers, so it requires the development of a separate controller that adequately interfaces with the existing controller. Given the multitude of existing ROS-based robotic systems, the proposed approach based on RSSL is an attractive option when designing robotic systems based on ROS.