-Recently, one of the main research topics in the context of application of Cyber-Physical System (CPS) in the Smart City and Industry 4.0 scenarios is the one related to the use of Robot Operating System (ROS)-based CPS. Specifically, one of the main interest is to allow a ROS-based smart robot communicating with other heterogeneous Internet of Things (IoT) applications in an intelligent environment to efficiently react to the system requirements and environment changes. However, the communication between the IoT systems will face many challenges and increase the cost and risks that lead to the requirement of a cross-platform communication for bridging the ROS-based CPS and other heterogeneous IoT applications. This paper introduces ROS Edge Node for the interoperability between Robotics domain and other IoT domains, leveraging the highly modular BRAIN-IoT federation, which allows to decentralize, compose and dynamically federate the heterogeneous IoT platforms using OSGi specification, thanks to its dynamic modularity and wide usage in IoT middlewares. Together with the flexible integration with existing IoT devices/platforms within BRAIN-IoT platform, the event-driven asynchronous communication mechanism realizes cross-platform interaction with ROSbased CPS and solves the major challenges faced. This communication mechanism allows dynamic deployment of new functionalities for enhancing/extending the behaviour of robots according to external events. In addition, some specific behaviours to new ”virgin” robots, which might be needed to extend the fleet of robots or replace damaged/low batteries ones can be dynamically deployed at the setup phase. In BRAIN-IoT platform, Edge Node behaves as IoT devices/platform adaptors which integrate the existing IoT devices/platforms. The ROS Edge Node is one type of the Edge Node, which bridges the underlying ROSbased robotics systems and BRAIN-IoT execution environment, thus communicates with various IoT systems connected to the BRAIN-IoT platform. A Service Robotic use case is developed to demonstrate the proposed solution, it shows how the ROS Edge Node enables the fast adaptivity and interoperability between heterogeneous IoT domains in a federated environment. Index Terms-Brain-IoT, Cyber-Physical System (CPS), Service Robotics, IoT Middleware, Cross-platform Communication, OSGi
Nowadays, CPS are widely used in various aspects in our
society, including but not limiting in areas such as
manufacturing, energy, health, transportation and intelligent buildings,
causing significant socio-economic impacts. CPS are defined
as physical and engineered systems whose operations are
monitored, coordinated, controlled and integrated by a computing
and communication core. To realize such an intelligent system,
various technologies need to be involved, including sensor and
actuator technology etc. Together with IoT, Cloud computing
and Cognitive computing, they become the main technologies
of Industry 4.0 [
The communication is an important research topic for both
of CPS and IoT. As more and more different devices will
be integrated in an intelligent production environment, the
requirement of communication between different CPSs or
between CPS and IoT devices are becoming more and more
significant. For example, in a smart factory, different CPSs
such as Autonomous Mobile Robots (AMR) [
However, such communication is not that easy to realize since heterogeneity is a basic property for both CPS and IoT devices.
On the one hand, heterogeneity exists because different
CPS and IoT devices use different technologies in hardware,
software, or communication method due to different needs. On
the other hand, it is because the manufacturers of the devices
are different. Different manufacturers will design the device
according to their own standards. Devices from different
manufacturers, even if they are using the same technologies, their
protocol will be different. According to the latest statistics [
This paper presents a novel adaptor, ROS Edge Node, which
Copyright © 2020 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
implements an event-driven asynchronous cross-platform
communication mechanism for ROS-based CPS. The work is a
part of the H2020 research project BRAIN-IoT [
The rest of this paper is organized as follows. Section II introduces the state of the art of the solutions similar to the one proposed in this paper in multiple domains and the challenges to be addressed typically by these software. It also outlines the relevant technologies used to develop the proposed solution.
Section III describes the architecture of the ROS Edge Node, functionalities and development process. Section IV implements a simple robotic application to validate the solution in a distributed environment. Finally, the paper concludes with the Section V to provide a summary of the cross-platform communication mechanism for ROS-based CPS and the future work being undertaken.
One of the most popular example of CPSs is represented
by smart industrial robots. This sector is really fragmented,
in terms of hardware and software architectures, But in
recent years, more and more robots have begun adopting one
common technology, the middleware ROS. According to the
annual ROS Metrics Report for 2019 [
The ROS–YARP Framework for Middleware
Interoperability [
ROBIN Middleware for CPS [
devices, being deployable on heterogeneous platforms. After ROS is deployed on the device, it can use ROS as communication method to communicate. However, it can only support communication between devices developed based on ROS, it cannot be used to communicate with off-the-shell devices using different technologies. Furthermore, the messages used in ROS are the original data sent by the device, which has not been standardized. The receiver must know the content of the communication in advance, otherwise it will not be able to understand the received data. In State Of The Art (SOTA), one of the limitations of ROS–YARP middleware is the applicability area, which is limited to ROS and YARP only, while CPSs are widely used in various aspects. The robotic bridge provided by ROBIN project allows the communication between ROS and the automation application through the inter-node communication mechanism in ROS, but it requires the developers to directly create or include in existing ROS packages the valuable features for interacting with other external devices via fieldbuses or industrial network protocols. This requires to the developers to be expert in ROS programming. Besides, the direct operation on existing ROS packages may bring the risk of the damaging the basic functionalities. Moreover, in the real production environment, the robotics applications are significantly sophisticated and dynamic, requiring to the bridge to be flexible enough to react to the continuously changing production environment; to allow this the robotic bridge needs to support the update at runtime and the deployment on demand and this feature is not feasible using only native ROS.
Instead, ROS Edge Node bridges ROS and other IoT platforms using OSGi specification, in such way, the robot’s behaviours can be developed at the application level using OSGi instead of ROS. And this allows to have all the advanced OSGi capabilities applied in robotics scenario(i.e., start and stop atomic behaviours at runtime, deploy new ones, import, update and upgrade behaviours at runtime every time a new more stable or more secure version is available).
ROS Edge Node intends to address the gaps mentioned in
the previous section in the current State of The Art (SoTA)
and the typical challenges faced in researches on middleware
for CPS [
Abstraction and Automatic Adaptation: [
Security and Privacy: Automatic communication of
reallife objects represents a huge challenge in terms of trust,
security and privacy. The security and privacy component is
needed to provide the integrity of the collected data (stream)
and to ensure that the user’s privacy is not violated. The
data can only be able to connect to authenticated/certified
IoT devices. The management support of security and privacy
has to be considered as a main function of the
middleware for the IoT. The ROS Edge Node adaptor will be
integrated with the BRAIN-IoT platform, which introduces
a holistic end-to-end trust framework and privacy-awareness
and control approach to address the challenge [
Autonomous Operation: Many CPS applications are considered complex systems which can be in a huge number of different states at any point of time. It is generally extremely difficult to develop code to handle all these states effectively and in a timely manner. Having middleware that supports autonomous operations such as self-adaptive, self-resilient, and self-protected services can relax implementing and operating these complex CPS applications. The ROS Edge Node addresses this challenge supporting the development of complex IoT solutions for monitoring and controlling physical environments and systems. Specifically, it simplifies the operation of application providing a an event-driven notification method, which allow avoiding to use polling methods to query the robot or mission status, reducing greatly the network traffics.
RosJava Open Source Library2: RosJava project provides
a pure Java implementation of ROS, and it also can
interconnect to an existing ROS environment through the Internet
Protocol (IP) address. It provides a client library for ROS
communications in java that allows Java programmers to
quickly interface with ROS topics, services and parameters
through the eXtensible Markup Language (XML)-Remote
Procedure Call (RPC) [
JCodeModel Open Source Library3: JCodeModel is a Java code generation library. It provides common API to generate Java programs using Java language.
World Wide Web Consortium (W3C) and WoT: In recent
years, W3C organization has developed the WoT [
lines. More specifically, The central building block is the WoT TD4, which can describe the metadata of the object and the network-oriented interfaces and it’s the entry point of a Thing. TDs are encoded in a JavaScript Object Notation (JSON) format that also allows JSON-based Serialization for Linked Data (JSON-LD) processing, primarily intended to be a way to use Linked Data in Web-based programming environments. The building blocks allow an application client (a Consumer) to interact with Things that expose diverse protocols through the three types of Interaction Affordances defined by W3C WoT Interaction Model representing the capabilities of individual Things: i) Properties (PropertyAffordance class) can be used for sensing and controlling parameters, such as getting the current value or setting an operation state; ii) Actions (ActionAffordance class) model invocation of physical (and hence time-consuming) processes, but can also be used to abstract RPC-like calls of existing platforms. iii) Events (EventAffordance class) are used for the push model of communication where notifications, discrete events, or streams 2https://github.com/rosjava 3https://github.com/phax/jcodemodel 4https://w3c.github.io/wot-thing-description/ of values are sent asynchronously to the receiver. TD can be used for flexible implementation and simulation (if required). WoT will break the barrier of interoperability of various IoT platforms, thereby contributing to the explosive growth of the market. It doesn’t aim to define a new platform, but to use the metadata to bridge existing platforms and standards.
In this paper, these technologies will be used in the following aspects. The ROS Edge Node, will be developed as OSGi bundles, which can be remotely installed, started, stopped, updated, and uninstalled without requiring a reboot in BRAINIoT federation.
RosJava can be considered as the bridge between ROS world and Java world. It provides an efficient way for the ROS Edge Node to establish a communication with ROS-based devices. Different ROS functionalities will be mapped into different OSGi services in the ROS Edge Node. The mapping procedure will be done automatically through JCodeModel library with a TD of the underlying ROS environment. Anyway, the corresponding formatting procedure of events and integration with BRAIN-IoT framework should be done by developers.
ROS Edge Node will be integrated with BRAIN-IoT Fabric
[
The architecture of ROS Edge Node is shown in Fig.1. For its development and validation, the authors have used the ROS simulation for BRAIN-IoT service robotic use case provided by the Robotnik Automation S.L.L. (see Section IV). The ROS Edge Node has two main requirements: i) to expose all the relevant ROS functionalities as OSGi services (task done by OSGi Service Component). The objective is to make the adaptor able to interoperate with the ROS environment leveraging APIs provided by the open source Rosjava project, in this way, the adaptor is able to send/receive the ROS request/response messages from/to the ROS services and publish/subscribe to the ROS topics between the OSGi world and ROS world. ii) To collect and format of the BRAIN-IoT events from different sources based on the Publish-Subscribe pattern5 (task done by BRAIN-IoT Robot Service). The adaptor receives the events from heterogeneous platforms in the distributed BRAIN-IoT Fabric environment and constructs them as Java 5https://en.wikipedia.org/wiki/Publishn%E2n%80n%93subscribe pattern objects representing ROS messages, then transforms to ROS environment through the exposed OSGi services. In contrast, the adaptor also retrieves the ROS messages from the native services/topics and convert to the BRAIN-IoT events, then deliver them in the distributed EventBus. The connectivity with ROS is configurable through the ROS environment variable ROS MASTER URI by default whose value is configurable on-the-fly in order to set up which machine as a ROS master when a new ”virgin” robot join the fleet of robots.
interoperability challenge when integrating other IoT devices in BRAIN-IoT platofrm. As Fig.1 shows, the basic function of ROS Edge Node is to map the ROS messages to BRAIN-IoT events and vice-versa. The BRAIN-IoT services interact with each other by leveraging the Requirements and Capabilities metadata provided by default by all OSGi Bundles, the events issued by a source BRAIN-IoT service contains the sufficient information presenting the Requirements of this service, in the meanwhile, the events also identify the Capabilities of the sink BRAIN-IoT services that will consume them.
The ROS Edge Node simply interconnects to the ROS environment thanks to the RosJava library which provides a simple interface enabling the ROS Edge Node to automatically generate a set of Java object classes, which is totally compliant with native ROS messages’ structure in the ROS environment. The instances of the classes could be transformed to the ROS environment. However, it’s not possible to make the BRAINIoT events types the same as the names of the native ROS messages. For a single robot, there could be hundreds of types of native ROS messages in the ROS environment and their data structures are in general very complex, direct mapping between the ROS messages types and BRAIN-IoT events is inefficient and will increase the complexity of the usage of the events for other IoT applications. Also, different robots having same functions may use completely different types of ROS messages as commands. In such case, if directly mapping each ROS message into an event, the difficulty to integrate different robots in a system will be increased. Thus, some common data types including necessary information need to be defined and shared between diverse IoT applications. So it’s necessary for ROS Edge Node to format the received events into the specific Java objects that are compliant with ROS messages.
The ROS Edge Node wraps also the native ROS functionalities, exposing them to the OSGi services for heterogeneous IoT applications’ access, by creating the corresponding ROS services and publish/subscribe clients in OSGi bundles, through the APIs provided by RosJava project. The exposed OSGi services are a set of java classes containing multiple robot operations mapped to Java methods. The BRAIN-IoT Robot Service in Fig.1 is a wrapper of the exposed OSGi services, with the specific Capabilities information represented by the consumed event types. The ROS Edge Node is responsible for communicating with other BRAIN-IoT services using Events. When the robot service receives an event from the EventBus, it will construct a ROS message in Java type and perform the corresponding action by calling the exposed ROS functionalities. Thanks to the BRAIN-IoT solution, the service will be deployed on the BRAIN-IoT Fabric by the event-driven mechanism. It’s completely de-coupled from the underlying BRAIN-IoT Fabric runtime.
2) The Autonomous Operation: As mentioned in Section II-C, supporting autonomous operation is one of the challenges for a CPS adaptor. In the ROS Edge Node, the autonomous operation is fully supported by a feedback mechanism: the ROS Edge Node is responsible for continuously querying the execution status of CPS where it is installed and then to issue an response event if the status changes. This allows building services, which leverage the ROS Edge Node, which are “smarter” and reducing the communication workload on the EventBus,(see Fig.6 in Section IV).
is a usual task that needs to be supported by such type of solutions. For ROS-based devices, this challenge is addressed by ROS Edge Node. As mentioned above, the exposed service components are a set of java classes containing multiple methods for robot operations. The operations are done through ROS services/topics clients in Java code via simple API provided by RosJava library. Normally, when developers create the java clients for the used native ROS functionalities, the java clients could be grouped in one or more Java classes for better organization.
Since the services or topics and their related methods in a component class have the same structures, the authors achieve to automatically realize the adaption by creating a Code Generator to automatically generate the OSGi service classes from a predefined configuration file as the input. Since all entities in ROS-based CPS communicate through services and topics, the authors choose to use the W3C WoT TD, which is a general standard for both integrating diverse devices and interoperability of diverse applications to describe the ROS functionalities. In the proposed solution, WoT TD describes the interfaces for OSGi to expose the ROS services and topics. In this way, a standard approach is used to describe the ROS API and to generate the corresponding OSGi services, this allows to have a solution WoT integration-ready and highly reusable. The ROS functionalities are compliant with TD specification: 1) the topics are as Properties Interaction Affordances 2) the services are described as Actions Interaction
For a ROS service, the part of TD file is shown as Fig.2. More specially, there could be a set of ROS services described in the Actions element, and for each of them, the information will include serviceClientName, serviceName, service
Name, which are used by the Code Generator to create service clients in OSGi world. The Code Generator uses the ClassName property to generate multiple component classes
Fig. 3. Expose of ROS Environment to OSGI Services Using WoT TD for different types of robot functionalities, and each component can contain multiple service clients and the different operations could be done through the methods called by each client. The values of other properties will be used as the arguments of the generated methods. Similarly, the ROS topics will be described in the Properties element, including the information about
and ClassName. The value of the Role property could be publisher or subscriber, so the corresponding client type will be created with the client name equal to the value of
speed up the ROS Edge Node development for the ad-hoc ROS platforms, A code generator is provided to generate the artefacts automatically by taking the TD as a configuration file, to describe the ROS services and topics, as shown in Fig.3, which is demonstrated in Fig.5 in Section IV. This approach greatly reduces the dependence for developers in the process of adapting to different ROS-based CPSs, increasing the development simplicity. Developers can therefore focus more on the development of BRAIN-IoT services rather than on adaptation work.
In this section, a brief description of ROS simulation The new functionalities for enhancing/extending the behaviour used for the Brain-IoT Service Robotic Use Case and the of robots according to external events can be dynamically result obtained evaluating the cross-platform communication upgraded and redeployed in the BRAIN-IT architecture. Based mechanism using it are presented. on that, the authors define the events in three types: action, query and cancellation. The events in action type includes A. Use Case Introduction WriteGoTo, PickCart and PlaceCart, which present the basic
Smart warehouse is a popular application of Industry 4.0. functions of the robot. There are also other events defined for The basic elements of a smart warehouse include AMR, querying the execution status of corresponding actions and for heterogeneous IoT devices and cargo carts. To be “smart”, cancelling current actions. these elements need to interact and cooperate with each other. In the use case, there are three services related to the The use case aims to realize one of the basic function of smart WriteGoTo action event, a WoT TD file is defined for the comwarehouse: the cart movement. The Fig.4 shows the warehouse munication with the robotic system, the code generator using with three zones in 3D perspective in Gazebo simulator: a the TD as input will automatically generate the class named docking area, a unloading area and a storage area. The last GoToComponent as shown in Fig.5 by using the open source two zones are separated by an automatic door, which is an JCodeModel library which is a Java code generation library. IoT device. There are three rb1 base robots (robot1, robot2 and Specifically, according to the ROS functionalities described robot3) in the docking area responsible for moving all carts to in the TD, there are three ROS service clients (e.g. gotoRun, the storage area. In the unloading area there are 3 carts (cart1, gotoCancel, gotoQuery) will be created in the generated class. cart2 and cart3) and each has a different QR code attached. when the ROS Edge Node receives an event, the corresponding The storage area is divided into three sub-zones (zone A, zone construct XXX Msg method representing the operation of the B and zone C). The robots need to pick up these carts from client will be called to construct a Java object representing the the unloading area, pass through the door and place them in ROS message as a ROS service request to be sent to the native the storage area according to the received commands from the ROS environment through the call XXX method of the service robot application. client, where the XXX stands for the name of the service client. The Robot Behaviour Service continuously checks the B. Robot System Design shared tables to get a task and then it controls the robots
In order to demonstrate how the adaptor bridges the ROS through a sequence of BRAIN-IoT events to finish the mission. environment and the OSGi environment, the authors imple- The events will be received by the ROS Edge Node Service mented a simple multi-agent robot system based on OSGi to and sent to the connected robot. As an example shown in Fig.6, control the simulated robots. after the ROS Edge Node receives a WriteGoTo event from the
The system contains three system parts: a Robot Behaviour Controller Service containing the coordinates where the robot Service, a ROS Edge Node Service and a Door Edge Node should go, with the autonomous operation of the ROS Edge Service. There are several tables storing the coordinates of Node, only twice communications are needed between the the carts and the storage positions will be used as the shared Controller Service and the ROS Edge Node, one for sending resources among three robots. In the ROS simulation, the basic the action command, while the other one for receiving the task for each robot is that starting from the docking area, it action result. When the robots detected a door on the way needs to go to the picking area for picking up a cart, then pass to the storage area, it reports the situation and the Robot through a door to the storage area and finally place the cart, Behaviour Service will instruct the Door Edge Node Service the procedure is controlled by the Robot Behaviour Service. to open the door. Fig. 6. Communication Procedure of “WriteGoTo” action for ROS Edge Node find the pending tasks. When a cart to be moved is found in the table, Robot Behavior will change the status of the cart to moving and start the moving procedure. Robot behaviors will deliver a sequence of events to the corresponding ROS Edge Node one by one to command the robot to move to cart position, pick up the cart, move the cart to specific position in the storage area and finally drop the cart. When ROS Edge Node receives an event, it extracts the information contained in the event, constructs a ROS message in Java type, and communicates with the robot through the exposed OSGi services.
ROS Edge Node is responsible for continuously querying the execution status from the specific ROS service/topic, when the action of an event is finished or something wrong happened, a feedback event will be issued to inform the Robot Behavior to ask for the next action. During the moving procedure, if the door is closed, it will scan the QR code of the automated door, and return a DoorFound event to the Robot Behavior.
The Robot Behaviour will send a OpenDoor event to the Door Edge Node service to open the door.
After finishing the moving procedure, the Robot Behavior Service will change the status of the cart to moved in the table and search for the next mission. Finally all carts are moved in ROS simulation.
Fig. 7. Deployment of Robot System in the distributed BRAIN-IoT Fabric
tributed Fabric environment containing multiple Raspberry Pis
and one Linux server running the ROS simulation as
BRAINIoT nodes in a same network. The Linux server is labeled
in advance when BRAIN-IoT Fabric cluster is created and the
ROS Edge Node Service is automatically deployed on it when
the label is detected. Since there are three simulated robots,
three instances of the ROS Edge Node Service instantiated
by OSGi Configuration Admin Service Specification [
6https://felix.apache.org/documentation/subprojects/apache-felix-gogo.html cluster. Secondly, it provides an approach to automatically expose the ROS functionalities as OSGi services for bridging the ROS world and OSGi world. Thirdly, ROS Edge Node maximizes the flexibility of the mechanism by supporting customized autonomous operation to detect the changes of action status and issue feedback events, thus greatly reduces the communication load on EventBus and its dependence on other system components. Finally, the use of WoT TD standardizes the description of the ROS functionalities.
Compared with the existing CPS middleware or IoT middleware, the proposed solution presents several advantages, but some further developments are still ongoing. The integration with the BRAIN-IoT End-to-End Security Framework are still under development. Besides, its functionalities will be enriched more, such as the graphical monitoring of robot status and the warehouse coordinates at runtime by integrating with other BRAIN-IoT monitoring tools. ROS Edge Node will be tested on the real robots with a more complex Robotics use case and the performance will be compared with other existing solutions, in the future work.
model-Based fRamework for dependable sensing and Actuation in iNtelligent decentralized IoT systems” and received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 780089.
The simulation environment is provided by Robotnik Automation S.L.L.