A Low-Code Approach for Connected Robots

Advanced robotic systems are finally becoming a reality; following the increased attention that robotics have attracted during the last few decades, new types of robotic applications are launched, from robotic space vessels and fully autonomous cars to robotic dancers and robot companions. Even more, following the advancements in the Internet of Things (IoT) domain, robots can now participate in more complex systems, namely Cyber-physical systems (CPS). In such systems, robots, software, sensors and/or “things” cooperate seamlessly in order to exhibit the desired outcome. However, the high heterogeneity of the components comprising CPS systems requires expertise in various scientific domains, a fact that makes development of CPS applications a resource- and time-consuming process. In order to alleviate this pain, model-driven (or model-based) approaches have been introduced. They employ a low code software engineering approach and hide the domain-specific knowledge needed, by providing an abstract representation that can be more easily understood. Following the low-code paradigm, current work focuses on the development of Domain-specific Languages (DSL) for ROS2 (Robot Operating System 2) systems in order to hide low-level middleware-specific setup and configuration details and enable access to robot development by non ROS experts. Furthermore, in order to enable the integration of ROS2 robots in CPS, a second DSL was developed. The first language, GeneROS, is used for the development and configuration of the core functionalities of the robot (such as hardware drivers and algorithms), while the second language, ROSbridge-DSL, implements the interfaces for connecting robots to the Edge and the Cloud, enabling this way remote monitoring and control in the context of IoT and CPS.


Introduction
The rapid evolution in Robotics, IoT, Cloud and Software Engineering sciences, has lowered the complexity of developing and delivering interconnected robotic systems. Traditional robotic applications were monolithic, meaning that they were executed in confined systems (either a single robot or a group of robots in a local area network). This view has changed with the introduction of the IoT paradigm. IoT builds upon a network (or network of networks) of physical objects (sensors, effectors, robots etc), able to manage data exchanges. Nowadays robots can be perceived as "Things" in the IoT concept, since they essentially are complex devices collecting sensory data from their environment and offering behaviour-level functionality and actuation services. The coupling of robotics and IoT areas introduces a new scientific and application area, namely the Internet-of-Robotic-Things (IoRT) [1,2], that offers additional capabilities. From the robotics point of view, IoRT enables rapid setup and configuration of inter-robot communications and data exchanges, cloud connectivity, remote management and monitoring, and knowledge sharing (via cloud-hosted or edge-hosted algorithms as-a-service) among others. On the other hand, intelligent physical robotic agents extent the IoT context, enabling this way more sophisticated CPS environments and applications to be built, deployed and monitored.
Due to the high level of heterogeneity and complexity (physical sensors, devices, software-defined agents and platforms, different communication technologies/protocols, networking etc) in CPS, operation-level or application-level programming can be performed using event-based (or datadriven) asynchronous communication protocols between the individual components. Such an approach allows for fast and dynamic integration of devices, robots and services in a centralized control system. This way applications can be executed in a distributed fashion, giving access to resources provided by devices, robots, services and even other applications.
On the other hand, Model-driven engineering (MDE) and Model-driven development (MDD) areas aspire to promote rapid application development and target to tackle various challenges faced in design, development, deployment, and run-time phases of software systems through abstraction and automation [56]. Model-driven and domain specific development methods are approaches for for addressing the challenges of building complex heterogeneous systems in domains such as aerospace, telecommunication and automotive [4]. Robotic systems face similar challenges, due to the need for blending hardware and software knowledge and technologies in a holistic way intrinsically raising many crosscutting concerns such as synchronization, concurrency, uncertainty, soft real-time requirements and time constraints [5,6] for critical robotic tasks, such as navigation, simultaneous localization and mapping, motion control and obstacle avoidance. By experience, traditional general-purpose languages often lead to a gap between the language features and the implementation requirements.
Domain-specific languages (DSLs) and models offer a powerful, systematic way to overcome the challenges of developing systems and applications for CPS [7]. A (DSL) is a programming language dedicated to a particular problem domain that offers specific notations and abstractions, which, at the same time, decrease the coding complexity and increase programmer productivity within that domain [8]. Models offer a high-level way for domain users to specify the functionality of their system at the right level of abstraction.
In the context of the current work, we focus on low-code robotic systems development via utilization of Model-driven development methodologies and Domain-specific language engineering. For this purpose, two DSLs has been implemented, promoting low-code development of robots in the context of IoRT and CPS. This contribution provides an abstract representation of robotic systems based on the Robot Operating System 2 (ROS2) [9], as well as a toolchain for designing valid, reusable and abstract robotic systems in the form of models. It can be considered as a Platform-Specific Model (PSM) for ROS2 robots and can be used by more abstract representations of the robotics domain (Platform-Independent Models / PIMs), using proper Model-to-Model transformations between the PIM and PSM meta-models. Furthermore, our DSLs provide means of connecting robotics resources with IoT platforms, via message broker technologies, enabling this way integration of robots in a wider range of application domains, such as home automation/assistant, smart industry, automotive, and CPS in general.
The rest of the paper is structured as follows. Chapter 2 presents the state of the art in the field of Model-driven robotics, while also discusses currently available means for remote monitoring and control of ROS2 systems. Chapter 3 describes our Model-driven approach for developing ROS2 robots. Chapter 4 discusses the means of bridging robots to the IoT world, while Chapter 5 presents a Model-driven approach for connecting ROS2 robots to remote platforms by employing communication middlewares highly adopted in the IoT domain. Next, in Chapter 6, a step-by-step example for rapid development of robotic applications is evident, utilizing the DSLs developed in the context of the current work. Finally, conclusions and future work are presented in Chapter 7.

State of the Art
The Internet of Robotic Things (IoRT) domain is an emerging vision that brings together devices, sensors and objects with robotic and autonomous agents and systems [10]. Merging Robotics and IoT technologies extends the IoT objectives, such as data aggregation, monitoring and analysis, by introducing concepts such as action, interaction and autonomous behaviours. IoRT concepts can be met in physically distributed, heterogeneous robot control systems, such as network robot systems [11] and cloud robotics [12,13]. It denotes a concept, where sensor data from heterogeneous devices are fused and processed, resulting in control and manipulation of objects (e.g. robots) in the physical world [14].
The emerging term "Cyber-Physical Systems (CPS)" is an architectural paradigm where sensing technologies and robotic agents represent fundamental parts [15]. Originally defined in the computer sciences domain, the term Cyber-Physical Systems has been adapted to fit very different domains such as the control theory or electronic engineering. Nowadays, CPS is being interpreted as a particular scenario of IoT. CPS have similar concepts and principles to the IoRT. A full-fledged CPS is typically designed as a network of interacting physical and computational elements [16]. This notion is closely tied to concepts of robotics and sensor networks with mechanisms capable of computational

Model-Driven Development of Robotic Systems
Model-driven software development with DSLs aims to extract agreed-upon syntax and semantics from the problem domain, e.g., by reviewing existing code examples and APIs, through the analysis of formal descriptions found in the literature or the application of further analysis patterns [25]. Based on the results of these domain analysis steps, the identified abstractions and desired notations can be realized as a DSL. Instead of hiding the domain concepts in a compilation unit implemented with traditional programming techniques, the DSL approach provides the specific abstractions at the model level. In contrast to General Purpose Languages (GPL) such as C++, Java, or Python, DSLs usually contain only a restricted set of notations and abstractions, based on the understudy domain [8]. Numerous research efforts have been introduced over the last years on the direction of MDD of robotic and CPS systems, aiming to decrease the cost of robotic solutions, to increase their agility and make them accessible to the industry. The MDD process promises to make system development quite easier for non experts, as it requires from the software designer to use only domain specific tools. Additionally, MDD also provides software and hardware validation and improve the reusability of the software [56]. MDD seems to attract the robotics community lately, in an effort to provide tools for rapid and error-free development of robotic systems and applications.
The first steps towards this direction were taken by BRICS [26,27]. BRICS was a large scale European project that generated the BRIDE (BRICS Integrated Development Environment) software as well as related guidelines and standards. BRIDE is a complete Eclipse 1 plugin able to let the designer create robotic software as a set of components, behaviors and communication interfaces. It provides abstraction layers, graphical tools for building components, model validation, as well as code generators for ROS and OROCOS [28]. These features increase component reusability, allow modular development and speed up the software testing process. One could argue that BRICS has generated a PIM for robotics, as it allows for a clear separation of frameworkindependent and framework-specific code for OROCOS or ROS and provides a base framework for other implementations, too (BRICS Component Model, BCM). However, BRIDE does not support ROS2, which is one of the most promising robotic frameworks and already one of the most commonly used. In addition, it is complex and difficult to learn, thus not suitable for small/mid-scale projects and new users. Finally, BRIDE support has ceased since 2017 and any further contribution in the project is difficult as it requires strong JAVA, ROS and Eclipse skills.
On the other hand, the Robot Operating System Modeldriven development tool suite (ROSMOD) [29] is an integrated development environment (IDE) for designing ROS software, presented in the 2015 International Symposium on Rapid System Prototyping (RSP) and funded by both the United States Department of Defense and the National Science Foundation of USA. It provides graphical tools and a component-based approach to decrease the cost and the time required for the development and the deployment of ROS software. It is a PSM for ROS2, based on four meta-models that describe the software, the hardware, the deployment model and the experiment of a ROS system. However, ROS-MOD follows a meta-model approach that diverts from the original ROS one and the developer has to be aware of that. It does not allow the designer to reuse models or components between projects and this is its main weakness, limiting reusability. Furthermore ready-to use ROS packages cannot be imported and used in a ROSMOD design, which is also a drawback; it does not allow setup, configuration and deployment of ready to use robotics algorithms, such as SLAM, navigation and path-planning among others. The lack of reusability features make ROSMOD useful only for designing ROS packages but not ROS systems.
RobMoSys [30] is another large scale project in the direction of MDD for robotic systems. RobMoSys aims to integrate MDE tools for robotics in a complete ecosystem. It builds upon and extends other Model-driven approaches in the domain of robotics, such as Smartsoft [31] and Papyrus for Robotics. The Smartsoft Model Driven Software Development Toolchain constitutes a complete IDE for robotic software. It extends the robotic software development to the independent component development of PIM, allowing the modular development of big projects increasing software reusability. It supports textual as well as graphical languages for developing components and their behaviors. The communication and the behaviors of the components can be changed at runtime, making the final software context aware and adaptive. It integrates many new and pre-existing tools both general purpose and domain specific, to build a huge toolchain for a very wide area of applications. Although complete, SmartSoft is a very complex tool, useful only for big teams and organizations with several domain experts (System architects, Robotic experts, System integrators etc).
On the other hand, the Papyrus for Robotics Toolchain [32] is another IDE that RobMoSys came out with. It is built on the top of the Eclipse platform and at the moment it provides safety analysis on system architecture's components, using a graphical DSL for that purpose. A performance analysis and a code generator implementation have been announced for a later release. Its capabilities are limited at the moment, as its development is still in progress. The future plan is to support only OROCOS systems.
ROSIN is another large scale project of the European Union, aiming to bring ROS to the industry, with several MDD tools. The Hardware Robot Information Model (HRIM) [33] is an MDE tool for modeling robotic hardware and a part of the ROSIN project. It does not focus on modeling the software like the rest of the purposed systems and this makes it a special approach. It implements a set of rules and standards the robotic hardware should follow, such as the communication data models, and divides the hardware into sensors, actuators, communication objects, processing units, interfaces and power suppliers. Hardware models can be developed by the user using an included DSL. It also allows the designer to develop ROS systems totally independent, raising the abstraction layers of the software. However, like ROSMOD, ROSIN does not support reusability of readyto-use ROS packages. This way the designer cannot include state-of-the-art robotics algorithms, developed by the ROS community, in their design and thus it can not be used for end-to-end design code generation, due to missing capabilities of the language and its concepts.
Other research in robotics focuses on modelling robotic missions [34]. For instance, by proposing better comprehensible mission DSLs that facilitate their definition by citizen developers [35] or through identification of specification patterns to further ease mission planning of robots [36]. The application of block-based modelling languages also is subject of is addressed by ongoing research in robotics too [37]. While being less domain-specific than mission planning languages, this research trend holds promise for easing robot development in the future.
Another interesting study on MDE for ROS is presented in [38] by Hammoudeh García et al. for bootstrapping the MDE development process with ready-to-use artifacts from public repositories, by using static code analysis and reverse MDE techniques, to transform manual code into working models.
Overall, there is a plethora of publications on the application of model-based and model-driven techniques to robotics, there only are few studies on this. The use of MDE in robotics looks promising as testified by many initiatives, works, and statements made by organizations.

IoT-Connected Robots
Over the last years a few research efforts have been published providing concerns and solutions about accessing ROS environments via web technologies. Rosbridge [39,40] for example is stated to be a middleware abstraction layer which provides access to robot interfaces (ROS) via web technologies. More specifically, Rosbridge uses websockets as the transport layer and implements a communication API on top of it that allow to access the onboard ROS environment. This approach implements the server-part on the device, thus further in-depth network configuration is required to allow access from outside the local network (e.g. from the cloud). Furthermore, it does not provide direct support for multirobot integration and application development and has a poor authentication layer that relies on an unofficial mechanism for authentication and authorization via a ROS node. The Rosbridge approach makes it extremely difficult and complex to connect from outside the local network and requires advanced knowledge of networks and networking, such as port forwarding and tunnelling.
Another noticeable work is ROSRemote [41] where authors provided a solution of connecting a local ROS master with a remote one running on the cloud. Though, this approach is limited to applications written in ROS and does not provide a solution for accessing via web technologies, neither does it deal with aspects like reliability, scalability and security.
It is obvious that none of the existing solutions provides a unified solution for remote control and monitoring of robots in the context of IoT and CPS. In the context of the current work we propose a DSL for connecting ROS-enabled robots with Edge and Cloud platforms and infrastructures, via utilization of message broker technologies [42]. The proposed DSL supports state-of-the-art communication protocols, such as AMQP, MQTT and Redis. This enables easy and rapid integration of robots with widely used low-code automation and assistance platforms, such as NodeRED 2 and HassIO. 3

Low-Code Development of Robotic Things
In Model-driven engineering, the concepts of a specific domain, along with their properties, are described via metamodels. A meta-model specifies all relevant properties of the domain and thus defines the rules for creating valid models. Models are abstract representations of certain aspects of a given domain (e.g. the robotics domain) and they can be the result of, or the input to (or both) numerous different processes. These processes generate, interpret or modify models, or even transform them into some different representations that focuses on a different aspect of the system. Compatibility between individual processes is ensured by the use of meta-models. The language to express models could be a either a general purpose or a domain-specific one (e.g. a robotic DSL), based on the approach. By focusing on the representation of the domain, MDD highlights a representation of knowledge about a domain rather than the algorithmic solution to a problem. A quick overview of MDD techniques can be found in [43].
In the context of the current work, MDD principles are used for the development of a low-code approach for building IoT-connected Robots. Our approach defines and implements two DSLs; a) GeneROS, the DSL for describing robots using ROS concepts, and b) ROSbridgeDSL, for connecting robots to the IoT domain, which includes Edge and Cloud integration. Each DSL consists of (at least) a textual grammar (defined by the meta-model of the language), a validator and a code generator. Furthermore, each DSL includes an internal engine that provides validation and software automation processes, via scripts. Input robot and bridge models are first validated against the relevant meta-models before executing software automation processes. In case the validation of the input models passes without any relational and logical errors, software automation processes are executed to generate the source code and documentation files. The aforementioned validation and code generation processes are evident in Fig. 1.
The Robotics domain is considered one of the most complex scientific and engineering domains nowadays, that utilizes knowledge from several other domains, such as computer science, artificial intelligence, networking, sensing and actuation technologies and distributed systems. For this reason, GeneROS builds upon well-established robotics middlewares, such as ROS, in order to abstract low level knowledge and enable reusability of community-driven software components, such as algorithmic processes and hardware drivers. Furthermore, utilization of model-driven technologies can lead to rapid and error-free (by design) development of robotic systems, due to the fact that robot models must conform to the meta-models, which define the relational and logical constraints for the robotics domain.
On the other hand, a big obstacle between robotics and the IoT world is the way robotics software is developed. Robots are not developed using dedicated software for the IoT, so domain-specific requirements are not met, leading to system implementations which are hard to integrate with the Edge and the Cloud. In this paper we propose an architecture that is based on message broker technologies, which are nowadays widely used in IoT, Edge and Cloud infrastructures for implementing the communication and messaging middleware. Such technologies enable asynchronous message-driven communication via a centralized broker. A message broker (or "broker") is a piece of softwaredefined middleware in charge of receiving messages and delivering them to those who have shown interest. It can be described as "the router for messages", providing communication reliability, flexibility, scalability and security, between the heterogeneous peers ( Fig. 2).

GeneROS DSL
GeneROS, the proposed DSL for describing ROS2-powered robots comprises several PIMs and PSMs, such as the System meta-model, the Package meta-model, the Object meta-model and the Graph meta-model. Modeling of the domain was performed using the Eclipse Modeling Framework (EMF) [44,45] and PyEcore [46] modeling tools, while the grammar of the textual DSL, along with the validation, code and documentation generation were developed using textX meta-language [47]. The core features of the GeneROS DSL, which are further described in this section, are listed below: • Ecore meta-model that describes the domain • Grammar of the textual DSL • Model validation The latter (GeneROS-to-ROSbridge M2M transformation), implements a user-guided procedure for generating a ROSbridge model from a given GeneROS model. This feature is used for connecting pre-modeled robots with Edge and Cloud platforms, via utilization of the ROSbridge DSL.
The root concept of the meta-model is the ROSSystem, which defines a ROS2 system. ROS2 systems consist of a software part (Software concept), system graphs (System-Graph concept) and topology details (Topology concepts).

Fig. 2 Message brokers to build a reliable and distributed communication middleware -Versatile Usage
This structure is presented in the general meta-model of Gen-eROS in Fig. 3. Each of the Software, SystemGraph and Topology concepts are represented by an individual metamodel in the following subsections, to reduce the complexity by applying both horizontal (separation of concerns) and vertical layering (abstraction).
In this section the proposed meta-models for ROS2enabled robots are presented, along with the toolset for describing, tranforming, validating, generating and monitoring robotic systems. This toolset comprises the DSL for the development of ROS2 robotic systems, namely GeneROS.

Software Concept
ROS2 software is organized into Packages represented by the Package concept in GeneROS. ROS2 uses Quality of Service (QoS) profiling to configure any kind of communication between Nodes. GeneROS assumes that a ROS2 system consists also of QoS profiles (QoSProfile concept) that may configure some communications between its Nodes, independent of the Package they belong to. This structure is presented in Fig. 4. Each of the Package and QosProfile concepts are presented by an individual meta-model below.
A Package can be either a CustomPackage or a RosPackage. CustomPackage is used to model new ROS2 Python Packages that GeneROS generates in the final system. RosPackage is used to describe and include pre-existing ROS2 Packages. GeneROS imports, documents and includes RosPackage definitions in the final ROS2 system and the system graphs but it doesn't generate them. Both of the Package types maintain the same attributes and references, as their only difference is on the code generation part.
ROS2 Packages comprise several files that hold the information of the installation and the execution that are basically modeled by the Package attributes. A ROS2 Package also consists of Nodes (Node concept), which are standalone processes that represent a concept or a component of the system, such as for example a navigation node or a motor node. Nodes are able to communicate either through oneto-many publish-subscribe (PubSub) streams called Topics, or via Remote Procedure Calls (RPCs) called Services, or through a combination of the above called Actions. A Topic interface, a Service interface or an Action interface describes the data that will be exchanged over the Topic, the Service or the Action, respectively. The interfaces could be defined by the user inside Packages, but ROS2 provides also some ready-to-use interfaces in ROS2 pre-existing Packages. Packages consist of Service interfaces (ServiceMessage concept), Topic interfaces (TopicMessage concept) and Action interfaces (ActionInterface concept).
Finally a Package consists of Deployment configurations and a number of Dependencies to other Packages. In Gen-eROS, every Package has a Documentation that includes basic and advanced information, in order to follow the best practices of software engineering. All this structure, along with the attributes of these concepts are depicted in Fig. 5.
The core concept of a ROS2 system is the Node. A ROS2 Node comprises clients (Client concept), servers (Server concept), publishers (Publisher concept), subscribers (Subscriber concept), action servers (ActionServer concept), action clients (ActionClient concept) and parameters (Parameter concept), to interact with other Nodes as described above. A communication interface could be either a custom one or a ROS pre-existing one and following the ROS2 approach, a Service interface could be implemented as a CustomService or as a RosService, a Topic interface as a RosMessage or as a CustomMessage and an Action interface as a CustomActionInterface because in ROS2 there aren't any pre-existing action interfaces yet.
Any Topic interface in ROS2 has a strict data model for message exchanges between publishers and subscribers. A service in ROS2 consists of a request from the client and a response from theserver. Similarly, a CustomService consists of a Request and a Response to build a service interface message from scratch. Any action interface (Cus-tomActionInterface) consists of a Goal, a Feedback and a Result. For custom interfaces, GeneROS automatically creates a new Package, the Interfaces package, to help the user get rid of commonplace package declarations (Fig. 5).
In ROS2, any custom interface consists of properties (ObjectProperty) and comments. Each Property has a Datatype that could be another ROS2 interface (ROSData), a Boolean (Bool), a Number (Int, Uint and Float) or an Array (IntArray, UintArray and FloatArray). Number and Array types are interpreted as one of the ROS2 primitive data types (Fig. 6). All the Dependencies (pre-existing ROS2 interfaces, custom interfaces and their containment) are automatically resolved by GeneROS.
ROS2 uses Quality of Service (QoS) profiles to configure any kind of communication between Nodes. GeneROS assumes that ROS2 systems consist also of QoS profiles (QoSProfile concept) that may configure communication between Nodes, independently of the Package they belong to. A QoSProfile is actually either a pre-existing one (RosQosProfile concept) or a custom one (CustomQosProfile concept), where various QoS-specific properties can be configured. Any kind of communication between Nodes (server, client, publisher, subscriber) could refer to a QoSProfile to receive a special configuration. Otherwise, the default configuration is used for inter-node communication. The QoS meta-model of GeneROS is evident in Fig. 7).

Graph Concept
Except from the software, GeneROS generates documentation about the design of the ROS2 system, such as the interconnections between the independent Nodes. This documentation has nothing to do with the individual package documentation, as it is describing the whole ROS2 system simultaneously based on graphs. The system documentation consists of a package graph (PackageGraph concept) and a communication graph (Graph concept). The PackageGraph is a UML like graph, that presents the packages of the ROS2 system and their dependencies and thus refers to packages. A simple example package graph, for a Package (my_package) and its dependencies, is evident in Fig. 8. In this example, the CRSM-SLAM dependency is considered to be a ready-to-use ROS2 package that is included in the design, while the interfaces and launch_robot packages are generated by the DSL, based on defined communication messages and deployment schema.
The communication graph (Graph meta-model) is a directed graph that visualizes the message flow in the ROS2 system (Fig. 9). It refers to Nodes and consists of links between them, through Services (ServiceLink concept), Topics (Topic concept) and Actions (ActionLink concept). Service links refer to Clients and Servers, Topic links refer to Publishers and Subscribers and Action links refer to Action Clients and Action Servers. The Nodes among with their interfaces (services, topics or actions) are presented as vertices in the directed graph, while the Publishers, the Subscribers, the Clients, the Servers, the Action Clients and the Action Servers are the edges, connecting the vertices. Finally, an example communication graph, as produced by the documentation generator, is evident in Fig. 10, where Nodes are represented by a round-corner rectangles and ellipse denotes Topics.

Topology Concept
A ROS2 system is composed of software components that could be deployed to one or multiple host devices. These devices are organized in a physical topology. A topology describes the units of the CPS, their capabilities and their network configuration. For example a topology is a robot with 2 connected processing units or a grid of 4 robots connected through a local network. Therefore, GeneROS assumes that a ROS2 system consists of a topology (Topology concept) which consists of platforms (Platform concept) and possibly a local network (LocalNetwork concept). Any platform consists of host devices (Host concept) each of them is a unit with certain capabilities and a ROS2 installation able to run ROS2 executables. Hosts have network interfaces (NetworkInterface concept), such as Ethernet and WiFi links, to communicate with other hosts. This structure is presented in Fig. 11.
A Deployment configuration in ROS2 is described via Launch files written in XML or Python. Any configuration Fig. 8 An example package graph generated by GeneROS of this type belongs to a Package as described in Section 4.1. These files describe the Nodes to be executed within the ROS2 environment. The Nodes described in the Launch file can be imported from any Package implemented or imported in the ROS2 system. Therefore, GeneROS assumes that a Deployment configuration (Deployment concept) includes Nodes and a Host on which the deployment will take place, as presented in Figs. 5 and 11.
GeneROS generates a new Package for every Host, where hostname is the name of the Host. These Packages contain all the Launch files and the information for installing and executing the target executables on each Host. Adding Dependencies to the Package of a Host could resolve the installation of the other depended Packages to the Host.

Models and Transformations
In Model-driven engineering, domain models are created using dedicated DSLs, designed to fit and conform to the rules defined by the domain meta-model. But, the meta-model of the understudy domain may vary from the rules of a textual DSL. The set of rules of a DSL is called grammar and it can be seen as the meta-model of the DSL. Any model expressed in a DSL undergoes a validation process through the specific Fig. 9 Graph meta-model of GeneROS grammar, to ensure that it follows the morphology, the vocabulary and the syntax of the language. Afterwards, the model is fed into another validation process through the meta-model rules, to ensure that it does not violate the constraints of the specific domain. Models may also go through a set of M2M transformations, each of which represents a transformation from a domain to another. Every M2M transformation also implements a validation step through the rules and the constraints of the meta-model of the new domain. Finally, a Model to Text (M2T) transformation is applied to the input models from a generation engine that produces the target source code, documents, diagrams etc. In this section, the models, the transformations and the generation engine are described.
As evident in Fig. 12, GeneROS takes as input a model file (GRS format), that is then validated, based on the grammar of the DSL. This model follows the grammar of the textual DSL, which means that is expressed in a valid syntax and morphology. Afterwards, an M2M transformation is applied on the GRS model, where the GRS model is transformed into an Ecore model. The new model is validated against the ROS2 meta-model relational and logical rules.
The relational rules concern the structure of the concepts, their relations, their attributes and the default values, as they have already been described by the meta-models (e.g. A Software could have from zero to unlimited Packages, but every Package should have a name attribute). The logical Contrary to what it may seem, the M2M transformation is a critical step in GeneROS. This step provides modularity on the maintenance of the system and also provides an entry point for future extensions, as the M2M transformation separates the whole development process into two different concepts, the DSL and the generation engine. On the one hand, changes and updates on one concept do not affect the other and on the other hand some other DSL could be linked to GeneROS by implementing only a new grammar and a new M2M transformation. This allows extensibility to GeneROS. For example, an extension could be a new DSL with a totally different approach (for example a graphical DSL) and a different user target group. Another noticeable extension could be a PIM on the top of GeneROS.

Creating Models of ROS2 systems
A DSL implements an interface between the user and the MDD platform. It should provide freedom to the user to design models, rules to validate the models respecting the domain meta-model and domain specific knowledge to provide abstraction layers for reducing the effort and the cost to design for the domain. The requirements of a DSL present a trade-off between the freedom and the simplicity of the design and the final golden section varies depending on the target of the MDD platform. In this section, the developed textual DSL for creating ROS2 systems is discussed.
First of all, GeneROS provides a textual DSL, that has been developed using the textX framework, called GRS. The language is based on YAML and JSON principles and semantics and allows the user to define a ROS2 system  as a set of independent components which may contain attributes and other components. The available components, their commands and a short description for each of them are summarized in Table 1, where the last column includes the container class of each component. GRS is designed to enable component based development of ROS2 systems, following low code principles, also providing software modularity and reusability. GRS supports the reference to a component and a model through its name. The grammar of the language defines a set of required and optional attributes for every type of component. These attributes could be Strings, Floats, Booleans, Integers, references to other components or references to components from imported models. GRS supports a Python like system of imports as long as nested model imports. There are single value, multiple value (list), optional and required attributes for the components. The usage of a component could take place before its declaration, as the component order does not matter but it is recommended to the user to follow a certain structure into the models, to retain their readability. Comments can be placed anywhere and their usage is recommended to raise the readability and thus maintainability and reusability of the models.
The below example illustrates the simplicity of defining a GRS model for a simple robot model with two ROS2 Nodes. It is a simple example where a ROS2 system is presented with a topology of a single host (host1) on a single platform. The system contains software of one ROS2 Package (pack1), that consists of two Nodes (node1 and node2). The first Node contains a Publisher (pub1) and the second one a Subscriber (sub1), both using the pre-existing ROS message Header (from Package std_msgs), for a PubSub communication. The final system will be deployed in the host1, where both Nodes will be executed (as defined in launch1).

ROSbridge DSL
In this section we discuss the methodology for bridging ROS and ROS2 endpoints, which can be Services, Publishers and Subscribers, to a message broker running on a remote server/machine (e.g. to the cloud). This will allow for applications to be executed remotely, e.g. on the cloud and still be able to utilize robotic resources (Fig. 13). ROS endpoints can be accessed via all supported (by the message broker) protocols. For example, RabbitMQ provides and supports transports for AMQP, MQTT and STOMP protocols. Though, this approach is not intended to be applied in time critical applications, where (soft) real time constraints exist, due to network latency, signal drop etc. Critical operations should always be executed on the onboard processing unit, such as for example the navigation and obstacle avoidance tasks of a robot. In the context of the the current work a textual DSL has been developed for the definition and code generation of bridges for robots. This DSL, namely the ROSbridge DSL, can run independent of the GeneROS DSL and supports both ROS and ROS2 robots. The elimination of dependencies between GeneROS and ROSbridge DSLs was preferred in order to easily support code generators of bridges for both ROS and ROS2 robots. This approach and it's pros and cons will be further discussed next in this sections.

Connecting Robots to the Edge and the Cloud
A big obstacle between robotics and the IoT world is the way robotics software is developed. Robots are not developed using dedicated software for the IoT, so domain-specific requirements are not met, leading to system implementations which are hard to integrate with the Edge and the Cloud.
In this section we propose a way of bridging ROS-enabled robots with the Edge and the Cloud, by utilizing message broker technologies. Message brokers, such as MQTT, AMQP brokers and Redis are widely used today for building the communication and messaging middleware for various platforms. Such an approach can be applied to remotely monitor, control and program robots, supporting this way direct integration of robots with IoT, Edge and Cloud platforms. The proposed DSL (ROSbridge DSL) builds a model-driven tool upon this approach for remote control and monitoring of robots.
Message-driven architectures are widely adopted in the context of IoT today, as they provide means of asynchronous event/message-driven communication of the heterogeneous endpoints (devices, sensors, web components etc.) via message queuing technologies [42]. To cope with increasing demands on scalability, flexibility and reliability, a messageoriented middleware is an infrastructure for loosely coupled interprocess communication in a service bus or clouds [48]. Due to the centralized nature of message brokers, and the ability to seamlessly route messages between connected heterogeneous peers, this paradigm can be used for the development of message-driven and event-driven systems, which is the case for IoT applications.
As far as application development is concerned, there are several advantages of adopting the broker-based messaging paradigm. First of all, applications don't need to have any idea about location of devices, other applications or endpoints of any other nature. The only address they need is the network address of the broker, along with a communication port. Secondly, a broker routes messages to the right endpoints based on business criteria, such as queue name, routing key, topic, message properties and headers, rather than on physical network topology (e.g. IP addresses and host names). Thirdly, message producer and message consumer lifetimes don't have to overlap. Producer application can push messages to the broker and terminate. The messages will be available for the receiver application any time later. Lastly, broker model is to some extent resistant to the application failure. So, if the application is buggy and prone to failure, the messages that are already in the broker will be retained even if the application fails.
Drawbacks of the broker model are twofold: a) it requires some amount of network communication (such as connection keep-alive heartbeats), compared to peer-to-peer or multicasting communication, and b) the fact that all the messages have to be passed through the broker can result in broker turning out to be the bottleneck of the whole system. To prevent such a bottleneck from happening, scalability operations should be considered such as clustering. State of the art broker implementations, such as RabbitMQ and Kafka, support such mechanisms out-of-the-box to solve the scalability problem [49].
Lately, message brokers such as RabbitMQ and Kafka are widely used in web applications and cloud platforms to handle high-throughput scenarios, offering reliability, scalability, data persistence and security out of the box. Furthermore, the same approach is used in the design of IoT and Edge gateways to connect devices and exchange messages, as long as for connecting whole edge infrastructures to the cloud.
An example application of message brokers for Cyber-Physical systems is [50], where the authors presented a distributed architecture for the implementation of a Cyber-Physical version of the famous Pacman game, where a RabbitMQ message broker is used as to implement the communication layer between the individual heterogeneous endpoints, such as robots, IoT devices and web components.
A device or a subsystem can internally use different communication middlewares, more suitable and specialized to the application domain. An example that we often encounter in the domain of robotics is time-constrained environments. Such environments may include physical robotic agents, industry-level actuation and any other domain with real-time constraints. Such environments are better handled via QoSenabled communication protocols and standards, such as DDS. In such cases, protocol bridges can be used to connect endpoints between the two communication middlewares, in a pattern-based manner. For example, one should implement a bridge to map an AMQP RPC to a ROS Service, meaning that external clients will be able to interact with a ROS environment via an AMQP message broker (Fig. 14).

ROS-Broker Bridges
To bridge communication between a ROS environment and a message broker, a bridge must be executed on the host device, as depicted in Fig. 13. This will allow for remote utilization of ROS endpoints running on a device or robot. Of course, both ROS and ROS2 support communication within a Local Area Network (LAN), thus it is possible to run the bridge process on any device within the same LAN. Two main types of bridges are observed based on the communication Fig. 15 Example of connecting ROS service and topic endpoints to an AMQP broker via proper protocol-based bridges pattern -RPC (or Service) bridges and PubSub (or Topic) bridges (Fig. 15). The first defines a way of interconnecting ROS Services with the message broker so that they can be remotely called. A Service bridge is composed of an RPC service listening on the target message broker, and a ROS Service client. On the other hand, Topic bridges are used in case of ROS Topic communication and are directional, meaning that they have configurable direction of message flow, which can be of type Broker-to-ROS (B2R) or ROS-to-Broker (R2B). B2R topic bridges are used to route messages from a message broker to a ROS topic, while R2B bridges route messages in the opposite direction, that is from a ROS topic to a message broker. Finally, ROS Actions are also easy to bridge via composition of Topic and Service bridges.
The aforementioned can be observed as the mapping of ROS endpoints to broker endpoints. This enables configurable integration of robots to iot, edge systems and cloud infrastructures, since bridge models are defined per-robot. Furthermore, bridge models actually define the remotely accessible resource API (Application Interface) of robots.

The ROSbridge-DSL Meta-Model
The meta-model of the language for describing bridge models for robots is evident in Fig. 16. The three main concepts of the DSL are: a) Bridge, Connection and Import. A Bridge is the definition of a software component that bridges message flow between ROS/ROS2 systems and message brokers (AMQP, MQTT and Redis). More specifically, three types of bridges exist, based on the communication pattern. TopicBridge is used for ROS Topic communications, ServiceBridge for remote utilization of ROS Services and ActionBridge, which  is a composition of TopicBridges and ServiceBridges, as defined by the ROS communication model. A Bridge has two connection endpoints, a ROSConnection and a Broker-Connection, making it possible to connect one-or-more ROS endpoints to one-or-more brokers. Each BrokerConnection has a reference to a BrokerAuth instance for authentication purposes. Currently, one type of authentication is supported by the DSL, that is plain authentication (BrokerAuthPlain), using simple username and password credentials, though the meta-model and the code generators has been designed to easily support future additions. Finally, the direction property of the TopicBridge entity indicates the data-flow direction and valid values are 'B2R' (Broker-to-ROS) and 'R2B' (Brokerto-ROS).

Models and Transformations
A ROSbridge model can be either defined by the designer using the dedicated ROSbridge-DSL or obtained by a proper M2M transformation from a GeneROS model. While a Gen-eROS model is describing the core functionality of the robotic system, this information can be passed to an M2M transformation to set up a bridge from the ROS2 system to the cloud. The transformation parses the designed communica-tion interfaces of the GeneROS model (Publishers, Servers, etc.) and creates the bridges corresponding to the ROSbridge model. The information related to the Broker is passed to the transformation as a parameter and the process ends with a complete ROSbridge model. The transformation supports a single ROS2 system to a single Broker bridging, but the designer is able to create custom ROSbridge models for more complex designs.
The generation of source code is performed via proper M2T transformations. The code generation engine uses preexisted template files, for each type of supported bridges (TopicBridge and ServiceBridge). M2T transformations apply information from the model (e.g. broker type, connection parameters, bridge type etc), leading to the generation of the source code for the execution of the bridges defined by the bridge model. The generated software is written in Python (3.5+) and all bridges are launched from a single executable file.

Constraints
Beyond relational constraints, which are defined by the metamodel, there are also several other property and logical constraints. There are situations where it is important to define constraints on the value that a property of an entity can have. For example, the name of a ROS endpoint must not include the dot character. Constraints are either functional or non-functional and are defined using regular expressions.
The set of constraints is executed as rules to the instance model on two phases. In phase 1, as relational and type rules are defined by the meta-model, validation is performed while creating the instance model. Next, upon successful creation of the instance model, constrain rules are executed to validate against property rules (e.g. an AMQP URI cannot include the slash '/' character).

Language Grammar Definition
In the context of the current work, a DSL has been developed for connecting ROS-based systems with state-of-the-art message brokers based on communication pattern (PubSub, RPC, Hybrid) and protocol (e.g. MQTT, AMQP and Redis). ROSbridge-DSL is designed to provide a textual language for the definition of R2B bridges for ROS environments.
The representation of the models is defined by the grammar of the language. The grammar defines the set of rules for mapping text to concepts of the meta-model. Using textX "meta-language" to implement the language, a model parser is also generated and is used to validate input models and to generate the source code of the executable bridges, defined by the input model. The implementation of the grammar conforms to the meta-model of the language as evident in Fig. 16 and as deeply described in Section 5.3.
Below is an example instance model for a robot that includes a TopicBridge and a ServiceBridge, which connect to an AMQP broker on the cloud (CloudConn). The TopicBridge (FrontSonarData) forwards data from the front sonar sensor to the cloud, as defined by the direction property (R2B), while the FrontSonarState ServiceBridge allows for remote control of the state of the sensor (enable/disable).
A noticeable feature of the language is the ability to split models into separate files and to use an import statement to load Bridge and Connection definitions from other model files. The Include entity of the meta-model (Fig. 16) also defines a grammar rule for defining import statements, using Fully-Qualified-Names (FQN) to import other model files. Below is an example of using an import statement to reference Connection definitions from another model file (connections.rbr).
Furthermore, in-language comments are supported by the CommentLine and CommentBlock rules, as evident in Table 2. Fully-Qualified-Names (FQN), which are used for model imports and nested object reference resolution (e.g. objects within objects or namespaces), are defined using the dot ('.') separator character.

Use Case Scenario
By utilizing MDE principles, the development and the deployment process of robotic applications is rapid, efficient and requires fewer skills. Furthermore, by bridging robots to well-established message brokers for the IoT, such as Redis, MQTT and AMQP, we enable fast integration with the IoT, Edge and Cloud platforms and infrastructures. This way robots can be manipulated, either as source of information (using the onboard sensors), or to perform some action on the environment (e.g. clean the house), or even both, from within the edge or from the cloud.
As earlier explained in Chapter 5, the bridge model of a robot defines it's remotely accessible API. This API can be utilized, via well-established message brokers, by applications developed using low-code programming paradigms. A noticeable example is NodeRED, a low-code platform for IoT application development, using flow-based programming techniques. NodeRED uses message flows to implement application, a technique that is applied for asynchronous and event-based application development, which is the cases of the Web and the IoT. The interface of the platform provides simple nodes for reading/writing to a database, for deploying and calling web services, for implementing functional and algorithmic components and for communicating with various message brokers (e.g. Redis, MQTT and Fig. 17 System graph of the obstacle avoidance use case for the TurtleBot3 robotic platform AMQP), among others. NodeRED nodes have input and output ports for wiring nodes, which defines the data flow of the application.
An obstacle avoidance application for the TurtleBot3 4 (developed by the robotics company Willow Garage) service robot could be taken as a proof-of-concept example of our low-code approach using Domain-specific Languages and platforms. TurtleBot is a widely used robot for research and education purposes due to the low price and easiness of building custom robotics solutions. The obstacle avoidance service is implemented using three sonar range finder sensors installed on the front and the rear of the platform and connected to the Raspberry Pi running the ROS2 stack. All models used under this study can be found at the github repository of GeneROS. 5 As explained in Chapter 4, GeneROS supports the definition of already existing packages (RosPackage concept) such as for the TurtleBot3 which enables access to basic functionalities, e.g. motion control (motor commands) and sensors data acquisition. 6 The GRS model of TurtleBot3 includes various nodes, publishers, subscribers, though for the purposes of this use case only a subset is included. More specifically, the turtlebot3_core node is used, which includes two publishers (odometry and bat-tery_state) and two subscribers (cmd_vel and motor_power), as evident in the below snapshot of the TurtleBot3 GRS model. 4 TurtleBot3 platform: https://www.turtlebot.com/turtlebot3/ 5 Obstacle avoidance example for the TurtleBot3 robotic platform: https://github.com/robotics-4-all/generos/tree/master/examples/ jint_use_case 6 TurtleBot3 basic funcitonalities: https://wiki.ros.org/turtlebot3_ bringup The installed sonar range finders are modeled using Gen-eROS in the form of an individual package. The sonar package includes three nodes and each one is responsible for gathering and publishing measurements from a single range finder installed on the TurtleBot3 platform. Furthermore, as evident in Fig. 17, distance measurements are published on different topics, using the identifier of the relevant sensor (front_left, front_right and rear). The generated source code of the nodes includes the skeleton of the implementation and only requires the development of the logic part, that is the communication with the hardware to obtain and filter measurements. Custom interfaces are not defined due to that build-in communication messages are used, such as the Range message from the sensor_msgs package, the Odometry message from the nav_msgs package and the Twist message from the geometry_msgs package.
The design for this use case scenario is divided into several model files, in order to promote model reusability principles from the MDE prospective which are included in the implementation of the GeneROS DSL. More specifically, the design is split into three GRS files: The GRS model that describes the obstacle avoidance application is evident in Fig. 18 (graphical representation). It contains the core information required for the implementation of the obstacle avoidance application, which are the sonar nodes, along with for package segmentation and the deployment schema. The obstacle avoidance algorithm can be implemented as part of the robot using GeneROS, or execute remotely and access TurtleBot's resources by using the ROSbridgeDSL low-code approach presented in Chapter 5. For the purposes of this study, the obstacle avoidance algorithm is developed using the NodeRED low-code platform, promoting this way the rapid and error-free integration of robots in a wider range of IoT and CPS applications. GeneROS DSL provides a way of generating ROSbridge models from input GRS models, via a proper M2M transformation. 7 The M2M operation receives the GRS model and the parameters for connecting to a message broker (e.g. host, port and credentials), which in this case is an MQTT broker. The generated ROSbridge model consists of a ROS2Connection for the local ROS2 system, a MQTTConnection for the MQTT Broker and the proper TopicBridges to connect the Publishers and the Subscribers of the ROS2 system to the broker. Interpreting the GRS model using GeneROS generates a ready-to-build ROS2 system, along with documentation files (e.g. reports in pdf format and package and system graph diagrams) and deployment artifacts. The generated source code of this example contains the sonar_sensors package that includes required configuration, build and install files among with the implementation of the nodes and the launch_robot package with the deployment configuration of the example. The implementation of the logic for acquiring and publishing distance measurements from the sonars strongly depends on hardware specifications, in case of deploying on a physical robot, such as the type of the sonars (e.g. SRF04) and low-level connectivity and communication protocols (e.g. UART, I2C, SPI). Though GeneROS by default generates a mock implementation of the data acquisition and publishing logic, based on the predefined interfaces (e.g. messages) of the node, so that it can be initially used for system-level verification of the design. In case of deploying in a simulation environment, the implementation of the logic strongly depends on the simulator tool (e.g. Gazebo) for proper acquisition of distance measurements from the virtual environment. Table 3 documents the LoC metric [51] to count the volume of generated code artifacts. The measurements were taken using the Cloc 8 tool for Linux environments. XML files refer to generated package configuration and launch artifacts, while HTML+CSS refer to the generated documentation files. Notice that the auto-generated source code is documented in depth (LoC -Comments metric) based on the information provided in the input model. Interpreting the ROSbridge model (generated from the GeneROS-to-ROSbridge M2M transformation) will enable bridging robots' resources (ROS2 endpoints) to message broker technologies via well established protocols, such as AMQP, MQTT and Redis. For this purpose, the code generator of ROSbridge-DSL is used to build the bridge 8 Cloc Linux package to count and compute differences of lines of source code and comments: https://linux.die.net/man/1/cloc for connecting MQTT endpoints. The output is a single executable for ROS2 environments (vanilla ROS is also supported), that includes the source code of the bridge and it can be deployed on any device connected to the TurtleBots' network and have access to the ROS2 endpoints. LoC measurements are provided in Table 4 and the number of 196 lines refer to only six (6) topic bridges for our use case as evident in Fig. 17. Imagine the volume of the source code in robotic applications where tenths or even hundreds of endpoints have to be bridged for remote control and monitoring purposes, as it depends on the number of the topics, services and actions to bridge and the direction of message flow (B2R, R2B, bidirectional). Finally, the implementation of the obstacle avoidance application in NodeRED is evident in Fig. 19. Three MQTT topic subscription nodes are used to feed measurements from the sonar sensors to the application, via utilization of the R2B topic bridges. Range measurements are then fused and processed in order to calculate possible obstacles within the range of the robots' "safety area" and therefore calculate the desired velocities of the base of the TurtleBot3 platform. The output of the NodeRED flow are the desired motor velocities which are forwarded to the /cmd_vel topic via an B2R MQTT topic bridge. The flow is executed every time a message is received for either one of the sensors, due to the asynchronous nature of PubSub communication and the MQTT protocol. Furthermore, it is able to manually enable and disable the motion of the TurtleBot3 platform by sending proper messages to the /motor_power topic via the MQTT broker. The topmost three nodes in Fig. 19 (EnableMotors and DisableMotors inject nodes and MotorPower mqtt-out node) are used for remotely controlling of the state of motors (enable/disable).

Threats to Validity
The usage of experiments to evaluate and compare algorithms is a recent trend. The same can be said for software engineering, since major experimental studies in the area are usually no more than twenty years old. Search-based software engineering (SBSE) experiments share the limitations born out of the immaturity in both its source areas.
One of these limitations regards the lack of a list of validity threats that may affect SBSE experiments. In our study, we introduce a series of abstractions for the robotics domain, as proposed by the model-driven engineering paradigm and the model-driven architecture (MDA) [52], so as to lower the complexity and required time to develop IoT-connected robotic systems and applications, concluding to the design of a PSM based on ROS2 and a textual DSL for building ROS2 systems from model definitions. Much research adopting the MDA paradigm in domain-specific software engineering [8] and development tasks resulted in more effective and robust software, while also lowering the complexity, time and errors [53], resulting in a productivity improvement of standalone developers and development teams. Our case study was internally evaluated by four robotics developers, and self-reported the results for productivity improvement. However, we consider the self-reported results to be threat-negligible, since the developers established and applied a solid methodology to measure the productivity gain based on the Goal-Question-Metric approach [54]. Furthermore, the developers used their preferred methodology, frameworks and tools for the manual build of the robot software stack for the TurtleBot3 obstacle avoidance scenario. Another threat may exist regarding the selection of textual representations for the DSL, instead of visual. The proposed DSL provides a grammar for the textual language to enable the definition of GRS models. We too believe that a visual DSL built on top of the textual one presented in this work will further increase productivity of end-users. This approach is further discussed in the next paragraph, as a future work that we consider to perform.

Conclusions & Future Work
Although ROS2 is today a well-established middleware for developing robots, with a huge community and a repository with ready to use robotic algorithms and hardware drivers, it is extremely hard for newcomers in the area of applied robotics to learn how to program using ROS2. This is where MDE technologies can be incorporated in the development process of robotic systems.
In this paper, a model-driven low-code approach of developing robotic systems is proposed. A domain-specific language has been developed, that provides textual semantics for describing ROS2 robotic systems. The language is accompanied by a compiler (code generator) for generating the source code of the robot, given an input model file. The model-driven software automation approach enables rapid development of ROS2 software by making the design easier, cost effective and domain specific. The testing process could be resolved by the meta-model validation and the quality of the software does not rely on the developer's general programming skills. In addition, this approach could make the domain of ROS2-enabled robotic systems accessible to more audience, without requiring general purpose skills, which could bring a significant enlargement of both academic and industrial purpose robotic application development.
Furthermore, cloud computing and the IoT has seen a noticeable improvement over the last years, with numerous academic work, industrial applications and solutions for individuals. While clusters of smart things are already installed as wireless sensor networks, robots can be seen as "things", in the IoT concept, too. The remote control and monitoring of robots could let the developer use technologies and techniques of the IoT in robotic applications. Nowadays, cloud connected robots are used only by big organizations, able to cover the development and the maintenance cost of software for connecting robots with IoT platforms. An MDE approach could provide cheap, valid and rapid ways for connecting CPS to the Cloud, allowing to collect data and to perform complex tasks effectively, while ensuring centralized management.
One of the limitation of the language is that only the ROS2 middleware is supported. As described in Chapter 1, our study delivers a Platform-specific meta-model (PSM) for ROS2 and can be further used by future PIMs to enable abstraction of the development and execution middleware. ROS2 was mainly selected for this study because it is a well established open source robotics framework, which is used by a wide range of end users, such as roboticists, developers, researchers and companies, and has an extensive communitydriven repository of ready-to-use algorithms and hardware drivers for building robotic systems. Nowadays OS2 have support for most of the consumer robots, sensor and actuator devices and cloud robotics service providers. We intend to build a PIM on the top of the current PSM of GeneROS DSL for this purpose. This extension could let developers design totally Platform-Independent models and to generate Platform-Specific software without getting involved with Platform-Specific details.
A very interesting perspective would be the development of a web crawler to systematically retrieve information about available ROS2 packages, supplied by a Reverse MDE process [55] that could generate models (from input package definitions), from ROS repositories. This way we will automate the process of creating a repository of ready-to-use ROS package and system models. Models are easier to maintain, more scalable and more reusable [3], compared to source code. Furthermore, models are easier to represent using graphical semantics and can be understood and manipulated by not domain experts. The next step for this work is to build a visual DSL on top of GeneROS textual DSL so as to allow for the graphical construction of GRS models. Models created via the visual DSL will be initially transformed into GRS models via an M2M transformation and then an M2T will be performed sequentially to generate the source code of the design. Visual representations are simpler to understand by end-users, thus it is believed that this approach will further increase productivity by lowering the time required to study on and learn the semantics and the grammar of the textual language. Furthermore, we intend to extend to enable web integration, so that it may be possible to deploy in cloud infrastructures. This implies the development of a Web IDE for the language, realtime model validation and system generation backends, that will utilize the implementation of the GeneROS and ROSbridge DSLs. In this context of web implementation of the DSL, we suggest to implement a visual representation of the language so that it can be accessible by a wider range of end-users, such as citizen developers and Academics.
Currently, connecting ROS-enabled robotic systems to a wide range of IoT platforms, such as as home assistant and home automation platforms, or NodeRED low-code programming platform, is performed using a DSL that does not directly uses the GeneROS meta-model. We intend to extend the B2R DSL so that definition of bridges can be defined based on input GeneROS models, and not directly bind to hardcoded topic, service and action URIs and communication messages.
Dr. Emmanouil Tsardoulias obtained his doctorate and engineering diploma from the Department of Electrical and Computer Engineering at Aristotle University of Thessaloniki, Greece, in 2013 and 2007 respectively. His working experience includes participation in several EU and NSRF projects (e.g. RAPP, RELIEF, TekTrain). His research interests are focused in Cyber-Physical systems, Internet of Things and in Autonomous Robotic Agents. Some of the topics involved are systems engineering, autonomous driving, robotic applications and Model Driven Engineering for CPS. He is the technical manager of the ISSEL team, which operates at the School of Electrical and Computer Engineering, Aristotle University of Thessaloniki.
Andreas Symeonidis is a Professor with the Department of Electrical and Computer Engineering at the Aristotle University of Thessaloniki, Greece and the Head of Research at Cyclopt.com. His research interests include Software engineering processes, Model-driven engineering, Software quality and Software analytics, Middleware Robotics and Knowledge extraction from big data repositories. Dr. Symeonidis' work has been published in over 200 journal articles, book chapters, and conference publications. He is co-author of the books "Agent Intelligence through Data Mining" (Springer publishing), "Mining Software Engineering Data for Software Reuse" (Springer publishing) and "Practical Machine Learning in R" (Leanpub publishing). He is currently coordinating more than 10 contract R&D projects, while serving occasionally as a R&D project evaluator and reviewer for the European Commission. More at: http://users.auth.gr/symeonid.