enabling data sharing with dds on real-time constrained industrial robots - diva...

Malardalen University

School of Innovation Design and Engineering

Vasteras, Sweden

Thesis for the Degree of Master of Science in Intelligent

Embedded Systems

ENABLING DATA SHARINGWITH DDS ON REAL-TIME

CONSTRAINED INDUSTRIALROBOTS

Sergio Erick Vieyra Enrı[email protected]

Examiner: Moris BehnamMalardalen University, Vasteras, Sweden

Supervisor: Saad MubeenMalardalen University, Vasteras, Sweden

Company supervisor: Kristian Sandstrom,ABB Corporate Research,Vasteras , Sweden

Malardalen University Master Thesis

Abstract

Data Distribution Service (DDS) is a decentralized, zero-configuration, communica-tion middle-ware. This thesis presents a performance analysis of a communicationbased on DDS in the context of industrial robotics. The purpose is to find out if DDSis an adequate alternative for establishing a communication network between indus-trial robots, as well as other devices, and consider the advantages and disadvantagesthat this technology brings. Several current works are explored to give an insight inthe current state of smart industrial automation, as well as to serve as a basis for thetests conducted in this thesis related to DDS performance. Using ABB industrialrobots, a prototype is prepared and a series of experiments are carried out in orderto measure the performance of the connection compared to a traditional end-to-endTransmission Control Protocol (TCP) socket. After explaining both the softwareand hardware architecture of the build setup, several test cases are presented inorder to compare the performance of the system with different configuration pa-rameters and network traffic conditions. An analytic review on the capabilities ofthe prototype, based on the test data is presented. The specific DDS distributionused in this thesis complies with the requirements needed by ABB robots in manydifferent applications.

1


Acknowledgements

I want to thank my university supervisor at Malardalen University, Saad Mubeen,and my thesis evaluator, Moris Behnam, who kindly provided very valuable feedbackand expertise to help me improve this thesis. I am also very thankful for the supportand technical expertise that I received from Kristian Sandstrom, Larisa Rizvanovicand Hongyu Pei-Breivold in ABB Corporate Research. I am very grateful for theopportunity to work in this project which brought me a chance to develop myselfacademically and professionally.

2


Table of Contents

1 Introduction 51.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.2 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . 61.3 Thesis Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Background 92.1 Industrial Robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1.1 Robot Arm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.1.2 Robot Controller . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Data Distribution Service . . . . . . . . . . . . . . . . . . . . . . . . 102.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2.2 Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.3 Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.4 Real-Time Publish Subscribe Protocol . . . . . . . . . . . . . 12

2.3 Real-Time System . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.2 Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Other terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.2 Internet of Things . . . . . . . . . . . . . . . . . . . . . . . . . 142.4.3 Industrial IoT . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.4 Cloud Computing . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Related work 173.1 The Real-Time Publish/Subscribe Protocol . . . . . . . . . . . . . . . 17

3.1.1 RTPS use in Distributed Systems . . . . . . . . . . . . . . . . 173.1.2 DDS Performance . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Industrial Robotics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.1 Robot Collaboration . . . . . . . . . . . . . . . . . . . . . . . 183.2.2 Industrial Data . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Research methodology 204.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204.2 Conceptual Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.2.1 Research Objectives . . . . . . . . . . . . . . . . . . . . . . . 204.2.2 Expected Outcomes . . . . . . . . . . . . . . . . . . . . . . . . 21

4.3 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.4 Analysis and Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.4.1 Initial Design . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.4.2 Time Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 22

4.5 Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.5.1 Development Stages . . . . . . . . . . . . . . . . . . . . . . . 22

4.6 Observation and Evaluation . . . . . . . . . . . . . . . . . . . . . . . 22

3


5 System architecture 235.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2 The Robot Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2.1 The Teach-Pendant . . . . . . . . . . . . . . . . . . . . . . . . 245.2.2 The Controller’s Firmware . . . . . . . . . . . . . . . . . . . . 24

5.3 The Central PC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

6 Implementation 256.1 The Base Experimental Setup . . . . . . . . . . . . . . . . . . . . . . 256.2 The DDS Experimental Setup . . . . . . . . . . . . . . . . . . . . . . 266.3 The Communication Algorithm . . . . . . . . . . . . . . . . . . . . . 26

6.3.1 Robot R1’s Algorithm . . . . . . . . . . . . . . . . . . . . . . 266.3.2 Implementing the C++ Module . . . . . . . . . . . . . . . . . 266.3.3 Robot R2’s Algorithm . . . . . . . . . . . . . . . . . . . . . . 28

7 Experimental Results and Evaluation 317.1 Testing Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

7.1.1 The Conducted Experiment . . . . . . . . . . . . . . . . . . . 317.1.2 Data to be Logged . . . . . . . . . . . . . . . . . . . . . . . . 33

7.2 Socket Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . 347.2.1 Basic Setup Measurements . . . . . . . . . . . . . . . . . . . . 347.2.2 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

7.3 Complete Setup Measurements . . . . . . . . . . . . . . . . . . . . . 367.3.1 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.4 Communication Layer Measurements . . . . . . . . . . . . . . . . . . 407.4.1 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7.5 DDS-specific Measurements . . . . . . . . . . . . . . . . . . . . . . . 427.5.1 The DDS Performance Test . . . . . . . . . . . . . . . . . . . 447.5.2 The DDS Subscribers Test . . . . . . . . . . . . . . . . . . . . 467.5.3 Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7.6 Analysis and Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 497.6.1 Advantages: Flexibility and Scalability . . . . . . . . . . . . . 497.6.2 Disadvantages: Latency and Timeliness . . . . . . . . . . . . . 497.6.3 Reliability in the QoS . . . . . . . . . . . . . . . . . . . . . . 51

8 Conclusions 528.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 528.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

8.2.1 RAPID/DDS Coupling . . . . . . . . . . . . . . . . . . . . . . 528.2.2 Possible Future DDS Use-cases . . . . . . . . . . . . . . . . . 52

References 57

4


1 Introduction

1.1 Motivation

The tasks that a robot can perform have greatly been constrained, among otherreasons, by the processing power that the robot itself has. Some of these criti-cal tasks, such as calculating and planing a path, recognizing a pattern or findingan optimal solution to a new problem, require a very large amount of processingtime, therefore, a cost-efficient way of providing this processing power is needed.Despite the decreasing and improving performances of computer systems many ofthese problems still require very powerful processing units in comparison to theembedded solutions often used in robotics [1, 2, 3]. Even more, in the context ofmachine learning and artificial intelligence, large amounts of data are required inorder to run an algorithm. Communication and data sharing among other machinesor with the users is another need that most robotic systems have, which adds up tothe final complexity of the system. Industrial robots are usually more constrainedthan their mobile counterparts since the applications that industrial robots performhave more demanding safety requirements. The safety constraints, reliability, andprolonged up-times that industrial robots require are achieved by slow (but highlydeterministic) processors. Nonetheless, industrial robots have been able to fulfilltheir duties with the aforementioned constraints since their usual tasks are not toodemanding on processing power. In other words, industrial robots are usually moreconcerned with metrics like repeatability, speed, and up-time rather than decisionmaking or pattern recognition.The advent of the Smart Factory poses a big challenge in many industrial areas: themanufacturing process, which historically has been a rigid, expensive and “custom-made” solution, is seeking to modernize itself and reduce costs, energy consump-tion and deployment complexity while increasing its robustness and flexibility [4].Consequently, industrial robots face new challenges. The topic of flexibility andhighly-customized manufacturing has taken great relevance in the last few years[5]. A flexible manufacturing process is one that can react to both deliberate andundeliberate changes in the manufacturing line. Interconnecting several stages ofthe manufacturing process could lead to a greater flexibility and an autonomousresponse to changes. Even more, these changes could be requested by a customerasking for a special requirement in its product [4, 6]. The Smart Factory will bedefined by these kind of future scenarios during the upcoming years.By connecting an industrial robot to a network in the manufacturing plant, aplethora of possibilities arises. Sharing the information within the robot and othermachines from different stages of the manufacturing process can lead to complexsynchronized behaviors and more flexible lines of production [6].This thesis explores the possibility of connecting a series of industrial robots to alocal cloud in order to exchange information with each other, as well as with othermachines and operators. A cloud architecture is deployed where the robots canfreely communicate with other machines using a networking middle-ware and theycan request services from both a local and a remote cloud in order to gain newcapabilities or extend their existing ones. For this work, the Data Distribution Ser-vice, or DDS for short, has been selected by ABB to serve as the communication

5


middle-ware that implements the communication over a local cloud. The reasonsfor the selection of DDS include its robustness in real-time systems, de-centralizeddesign and its no-configuration peer-discovery [7].

1.2 Problem Definition

For a given network topology implemented locally over Ethernet and based on DDSrunning on an industrial robot controller, we explore the following question:

What is the performance impact that this new DDS-basedcommunication will have in comparison to an end-to-end TCP socket

communication?

In order to answer this question in an industrial context, we will develop a proto-type setup using two ABB industrial robots and its corresponding industrial robotcontrollers. Because of the software architecture of the controller, a robot appli-cation only has access to a predefined set of communication mechanisms, thereforea software workaround needs to be created in order to avoid this constrain, whichfurther impacts the performance of the system. In concrete terms, this thesis inves-tigates a proposed software architecture and network setup in order to understandits real-time performance and whether or not DDS is an adequate technology forABB industrial robots.

1.2.1 System Overview

A networked setup is tested during this thesis in order to understand the advantagesand limitations of a DDS-based robot communication. Figure 1 shows a very basicsetup where the relevant components are present. A description of the system’sparts is also provided.

1. The industrial robotsThese robots are the main agents on the implemented communication scheme.They exchange data among them and with the cloud.

2. The central computerA computer that closely monitors the state of the system (up-time, iterations,joint positions, etc) and provides access to the local and remote clouds asrequested by the robots or other devices.

3. Other devicesThis devices can range from personal computers to tablets and cellphones.The purpose these devices is to monitor and access information regarding thecurrent state of the system.

1.3 Thesis Outline

The layout that the reader can expect in this thesis is as follows:

6


Figure 1: A basic diagram of the network topology that will be employed during this work.

Introduction: An introductory section, stating the goals, challenges and motiva-tion of the thesis is presented at the beginning of this work. The motivation andrelevance of the work’s topic is highlighted and the problem is briefly defined.

Background: A general overview and explanation of the involved technologiespopulate this section. The Background contains information meant to familiarize thereader with the concepts and terminology that this work uses. A quick theoreticaloverview into the concepts of industrial robotics, DDS communication, and real-timesystems is presented here.

Related Work: this section showcases some of the research already conducted onthe field that serves as the basis for this thesis.

Research Methodology: a systematical approach regarding the performed re-search for this thesis is presented in this section. An explanation on the methodologyitself, as well as the tasks regarding the thesis itself are presented for the reader.

System Architecture: this section presents in a detailed way the entities thatconstitute the system to implement. The hardware, network topology, software, aswell as the task that the robots need to carry out, are presented during this section.

Implementation: in this phase the process to develop and deploy the system ispresented. The tasks for developing the system’s architecture, the software and theintegration of the DDS facilities are discussed here.

7


Experimental Results and Evaluation: this part of the thesis explains thetests used to evaluate the system, the results obtained and the learned outcomes.A discussion feature, containing the advantages and disadvantages of the aforemen-tioned system is also presented.

Conclusions: in the last part of the thesis, a summary of the thesis is presentedalong with a suggestion for the future work that should be performed with thisproject and future scenarios that could benefit from a similar communication setup.

8


2 Background

The basic concepts that the reader must be aware of are presented in this section.Both robotics, embedded and cloud systems are areas that span over a vast amountof topics and research areas. The following sections provide a brief introduction tothese topics and the relevance they have for the thesis.

2.1 Industrial Robot

We can define an industrial robot as an “automatically controlled, re-programmable,multipurpose manipulator, programmable in three or more axes, which can be eitherfixed in place or mobile for use in industrial automation applications” [8].An industrial robot is a manipulator widely used in the automation industry inorder to perform a predefined task. This type of robot is designed to performrepetitive tasks that are unsuitable for a human worker. Given the nature of itspurpose, industrial robots must compel with strict safety constraints. Since thefield of industrial robotics is very vast, this thesis focuses on the kinematic chaintype of industrial robots, commonly known as industrial robot arms.

2.1.1 Robot Arm

A robot arm consists of a series of articulated links connected by powerful actuatorsin its joints. This is a very common type of robot in the automation industry sinceit provides a great amount of flexibility that can be employed in a plethora of tasks.The end part of a robotic arm, or the tool that the robot “is holding” is refereedto as the end effector. In order to program an industrial robot, instructions thatcommand the robot to move to a certain point in space with a certain orientation ofits end effector are needed. Figure 2 shows a typical industrial robot arm. The robotprogram must translate the position and orientation specified in the instructions intorobot joint angles. This process is called Inverse Kinematics, as opposed to directkinematics when an end effector state is calculated from the joint angles. Some ofthe most important parameters for an industrial robot are the following:

• Degrees of freedom: the number of joints that a robot has.

• Payload: the highest weight that a robot can lift while functioning properly.

• Workspace: the space in which the robot can perform movements.

• Precision: the accuracy of the robot’s movements.

• Repeatability: the ability of a robot to return to the same desired point inspace several times.

• Up-time: the total time that a robot can perform a task without any inter-ruption.

9


Figure 2: ABB IRB120. The smallest industrial robot from ABB.

2.1.2 Robot Controller

The robot controller is a device that executes the robot’s program and handles theinputs and outputs of the robot. Since a robot must compel with very strict timeconstraints, robot controllers almost always run an instance of a Real-Time Oper-ating System (RTOS). The controller also performs motion control tasks in orderto ensure that the industrial robot reaches the desired positions in the fastest, mostreliable and most efficient way possible. Robot controllers are programmed with aplethora of different programming languages. For instance, ABB controllers use theRAPID programming language, a specific-purpose programming language designedby ABB to easily and robustly program ABB’s line of industrial robots [9]. Usually,a robot controller also communicates with external industrial equipment by meansof digital signals. These signals are usually processed by robust Programmable LogicControllers (PLC) that serve as an interface to other industrial equipment.

2.2 Data Distribution Service

2.2.1 Overview

Data Distribution Service (DDS) is a data-centric machine-to-machine (M2M) com-munication middle-ware designed with real-time constraints, scalability and inter-operability in mind. DDS has been standardized by the Object Management Group[10] and there exists several commercial and open source implementations. Un-like most communication middle-wares, DDS uses a publisher/subscriber model forsharing its data. An entity using DDS publishes or reads information from a pre-

10


defined topic. This approach puts the data in a central role which simplifies thedeployment of intricate distributed systems. The DDS middle-ware also supportsquality-of-service (QoS) parameters that can configure the behavior of the data ex-change. A visual representation of a publish/subscribe communication scheme isshown in Figure 3

Figure 3: The DDS publish/subscribe model.

2.2.2 Structure

DDS encourages modularized and well-defined functionality on a distributed system.A list of the entities that compose a basic DDS communication is shown below.

Domain: in order to share data, applications need to be in the same domain.Complex distributed systems can use domains in order to separate different com-munication tasks.

Domain Participant: this entity provides the process with the facilities to par-ticipate in a DDS domain. Through this object, a process may create subscribers,publishers and all kinds data entities that conform to the DDS communication.

Topic: an object that encapsulates several communication publications with acommon purpose.

Publisher: a Publisher is an object responsible for the actual dissemination ofdata.

Data-writer: an entity that sets the data values to be published under a givenTopic.

Subscriber: a Subscriber is an object responsible for the actual reception of thedata disseminated by publishers.

11


Data-reader: a Data-reader allows the application to declare the data it wishesto receive (by making a subscription using a Topic, ContentFilteredTopic or Multi-topic) and to access the data received by the attached Subscriber.

2.2.3 Quality of Service

“Quality of service is defined as the characteristics of a network service that bearon its ability to satisfy stated or implied needs to the user of the service”. In otherwords, a network link must be able to satisfy certain demands from the devices thatpopulate it even under less-than-optimal operating conditions [11]. Some examplesof Quality of Service metrics are:

Speed: it is how fast the network can perform one of its functionalities, regardlessof the accuracy or correctness of the function.

Dependability: the degree of certainty with which a network performs one of itsfunctionalities given certain expected operational conditions but regardless of itsaccuracy.

Availability: indicates how likely is a feature of the service to be ready for theusers assuming that the necessary resources for the service are provided beforehand.

Reliability: the probability that a network will accurately perform one of itsfunctionalities under stated operating conditions.

Simplicity: the lack of complexity and the degree of abstraction with which theusers can access the network’s features.

Security: the robustness against any attempt to exploit a vulnerability of the net-work in order to gain unauthorized access to its assets (i.e. information, bandwidth,etc).

Data Integrity: the capability with which the network guaranties secure datastorage and correct transmission.

2.2.4 Real-Time Publish Subscribe Protocol

The Real-Time Publish Subscribe (RTPS) protocol is an interoperability protocolthat allows several providers of DDS to communicate with each other. The RTPSprotocol is a fundamental part of DDS since it defines the DDS communicationpackets in terms of the Internet Protocol (IP), thus ensuring that the middle-wareremains interoperable independently of the software implementation. RTPS wasfirst developed in the industrial automation context and was an approved standardby the International Elechtrotechnical Commission IEC as part of the Real-TimeIndustrial Ethernet Suite [12]. The protocol is a widely used and proven technology

12


that has been implemented around the world in thousands of industrial devices [13].The main features of the RTPS protocol include:

• Performance and QoS configuration parameters to enable best-effort and re-liable publish-subscribe communications for real-time applications over an IPnetwork.

• Fault tolerance against malfunctioning nodes.

• The ability to extend and enhance the protocol without hindering interoper-ability.

• Automatic network discovery, connection and re-connection, even when thenodes connect intermittently and/or without any warning.

• Configurations allow to balance the requirements on reliability and timelinessfor every data transaction.

• The protocol is modular, allowing resource-constrained devices to implementa subset of the protocol and participate in the network.

• Good system scalability allows the network to potentially scale to a very largenumber of nodes.

• Type-safety protects nodes from programming errors presented in other nodes.

The RTPS protocol is designed to be able to run over multicast and connection-less best-effort way in transport protocols such as UDP/IP.

2.3 Real-Time System

2.3.1 Definition

A real-time System is a system in which its correctness not only depends on theresult of its computation, but also in its ability to perform said computation withina given time constraint. In other words, a real-time system needs to perform anoperation correctly and in time. Real-time systems are deployed in many fields.Industrial robotics is one of those fields.

2.3.2 Characteristics

Some of the most important real-time properties and parameters are presented inthe following paragraphs.

Schedulability: is the property of a real-time system has if there exists a feasibleschedule that allows the system to execute all of its tasks within the aforementionedtime limit [14]. Vast theory on the means and methodologies for achieving thesefeasible schedules has been developed over the years [15]. Some of the most com-mon scheduling algorithms are Rate monotonic (RM), earliest-deadline first (EDF),deadline monotonic (DM), etc.

13


Many real-time operating systems support priorities in order to give preference tosome processes over others in the case that many tasks are available and ready toexecute at the same time.

Execution Time: It is the total time that a task or executing process uses inorder to perform its functionality assuming no interference or blocking occurs.

Determinism: it is the grade of predictability that the behavior of a system has.In other words, the output of a deterministic system is one whose outcome canbe predicted and does not depend on any stochastic variable [15]. This is a veryimportant real-time property since the analysis and design of a system is based onthe modeling and prediction of its tasks.

Latency: it is the time delay between a request and the generated response in asystem. Latency is an important factor that needs to be taken into account in orderto correctly model and design a system.

Jitter: it is the slight variation in the starting and end times of a real-time task.The presence of jitter in a system can affect its determinism and makes the systemdifficult to analyze, therefore, jitter is an undesirable trait on any system.

Real-time Distributed System: a distributed system consists of two or moreprocessing nodes that cooperate in order to solve the same problem [14]. Whenthese systems need to comply with strict timing requirements, they are said to be areal-time distributed system.

Variance: in probability theory and statistics, variance is the expectation of thesquared deviation of a variable from the mean. in a real-time context, the varianceof random sample measurements can tell how deterministic a system is.

2.4 Other terms

2.4.1 Overview

In this section we will cover some concepts that, while they do not have a central rolein the development of this work, they serve as the context for this work effort. Oneof the main reasons to integrate an industrial robot to a local network is to be ableto gain a better insight into the manufacturing process. The kind of informationthat an industrial robot can provide about this process is very valuable for newdevelopments in the field of the so-called Internet of Things [16].

2.4.2 Internet of Things

The Internet of Things (IoT) consists of the latest developments in micro-controllers,embedded platforms, smart sensors, communication technologies, and Internet pro-tocols, working together in order to interconnect devices without direct human

14


involvement [17]. These devices range from smart phones, televisions and homeappliances, to smart sensors, monitoring systems and health-care devices. Anotherdefinition of IoT is the collection of sensor and actuators interconnected to computersystems used to monitor and control their operation. Devices primarily designed forhuman interaction are not considered as part of the IoT [16]. The rate at whichwe are adding new devices to the Internet is very fast. The IoT promises seamlessmachine to machine (M2M) communication and equally easy data retrieval fromsmart devices, which will deliver a new class of “smart functionality” to our objects.Because of its potential benefits, it is expected that the IoT will generate 3.9 to 11.1trillions of dollars per year by the year 2025 [16]. As mentioned during the intro-ductory section, smart manufacturing and smart factories are a trend that requiresindustrial equipment to be more and more interconnected, both with their operatorsas well as with other machines.

2.4.3 Industrial IoT

The Internet of Things in an industrial context is commonly known as “The Indus-trial IoT”. Research on Industrial IoT applications is still in an early stage [18],nonetheless, a trend is evident among the research efforts to make industrial robotsmore connected to its environment (machine-machine as well as machine-operator)which could yield more flexible production lines (the so-called Industry 4.0 [19], seeFigure 4 ).

Figure 4: A tight integration between IT and manufacturing systems will bring the 4thIndustrial Revolution [19].

2.4.4 Cloud Computing

Cloud computing is a term that describes a computing system that provides a service(data access/storage, applications, CPU power, etc) to a remote client over a networkconnection [5]. The “shapeless” infrastructure formed by the immense amount ofservers that compose the Internet is what is refereed to as “The Cloud”. Thebenefits that cloud computing brings, both at the consumer and business levels,are very evident. The ability to access virtually limitless CPU power and data,

15


plus the ability to share information over the network, has had an immense impactin the way we use computers [5, 17]. Cloud services are offered in a plethora ofways to consumers and businesses. On-line storage, office suites, video streamingand driving directions are some of the most familiar cloud services. For businesses,data analysis, business management and monitoring/supervision are some exampleapplications.

16


3 Related work

In this section we review some of the research works that are related to the objec-tives of this thesis.While robot collaboration in the context of DDS as the enabling technology is arelatively new topic, there exists other works that have attempted to communi-cate robots with similar frameworks, and more importantly, with similar real-timeconstraints.

3.1 The Real-Time Publish/Subscribe Protocol

3.1.1 RTPS use in Distributed Systems

First and foremost, we can start by mentioning some of the existing literature re-garding the real-time publish/subscribe protocol used in the context of industrialautomation.On a related work carried out by the National University of Defense of China [20],DDS is employed to encapsulate the communication capabilities of a real-time, scal-able, distributed robotics communication framework. The obstacles addressed within [20] are similar to the ones that are the focus of this thesis, since the main con-cern is the hard real-time requirements for the dissemination of the data across allthe nodes. Whereas the aforementioned work has the freedom to chose the bestplatform for implementing this technology, with Robot Operating System (ROS)chosen as the basis of their so-called MicROS-drt system, this thesis deals with alegacy system that cannot be easily manipulated of adapted to implement DDS andtherefore a software communication layer needs to be implemented. Another key-difference is that the system presented in [20] uses a loosely-coupled link betweenthe different nodes that constitute the distributed system, whereas this thesis imple-ments a completely-coupled system, where no connection drop-out or delay above atolerance threshold happens.Limsoonthrakul [21] showcases in his research paper about the usage of of a publishsubscribe protocol in another communication framework for distributed autonomousrobot systems [21]. We can compare this effort in terms of its limitations and theoverall complexity of the system that in contrast gets avoided by using the RTPSprotocol in DDS in this thesis.The prototype system of the thesis will be deployed over Ethernet using a genericswitch. Efforts for testing the capabilities of the RTPS protocol over Ethernet andmeasuring the non-deterministic capabilities inherent of Ethernet have been docu-mented in [22]. To achieve very tight real-time constraints, Open Real-time Ethernetis implemented in that work. This thesis, in contrast, uses the common Ethernetimplementation to implement the prototype.

3.1.2 DDS Performance

While this thesis focuses on the performance of a DDS communication in a specificsoftware and hardware setup for the needs of the robot controllers, the performance

17


of the communication middle-ware has already been analyzed on several works. Asurvey of DDS and other real-time-oriented communication middle-ware can be con-ducted in [14]. The importance of DDS as an enabling technology in the Internetof things has been claimed in [17]. The performance evaluations of DDS in anindustrial automation context conducted in [7] served as the basis to test the ex-perimental setup developed in this thesis. The primordial difference between theseresearch efforts and this work is that the system that is being used as a prototypecan be considered a legacy system from the point of view of this thesis, since itcannot be modified to embed the DDS libraries and an additional communicationlayer is required to make it work.

3.2 Industrial Robotics

3.2.1 Robot Collaboration

Industrial robots usually collaborate in a “hard-coded” way. This means, robotsjust follow a predefined path programmed by an operator in order to orchestrate acollaborative effort. Enabling robots to dynamically and easily communicate witheach other and add a higher layer of abstraction to collaborative robotics has beendiscussed in [23]. In contrast to this thesis, [23] does not explores the possibility ofusing a higher abstraction layer in a time constrained environment like this thesis.Another collaboration of this work is that the industrial robots discover each otherin an automatic way because of the capabilities that DDS has access to. Therefore,zero-configuration is required in the context of the thesis work.Other research works focus more in the collaboration of small, non-mission-criticalrobots. Works like [24, 25] showcase examples of robots collaborating between them-selves in a non-industrial setting.Other research efforts implement data sharing capabilities in robots for human col-laboration [26, 27]. This thesis proposes a test prototype into autonomous, intelli-gent, robot-to-robot industrial collaboration, which hasn’t been yet fully explored.

3.2.2 Industrial Data

Accessing all the (massive) stream of data generated by a factory as a new paradigmfor manufacturing supervision. Researching procedures for using the data generatedby a plant as a mean to optimize the energy consumption has been widely docu-mented recently [4, 28, 29]. These works make use of external sensors or add-insolutions to monitor the activity of the manufacturing plant and integrate it intothe logistics of the overall business. Using the information available on an industrialrobot, in real-time, and specifically having the robot publishing the data itself is anarea that has not been thoroughly investigated. In the future work section of thisthesis, some possible use cases that are related to this new paradigm are presented.One research work [30] attempts to use information gathered from a ROS-basedrobot in order to monitor its functional behavior. Fusing this approach with anin-robot DDS-based communication framework could greatly remote monitoring ef-forts.

18


3.3 State of the Art

Industrial robots usually collaborate in a hard-coded way. This means, robots justfollow a predefined path programmed by an operator in order to orchestrate a col-laborative effort. Enabling robots to dynamically and easily communicate with eachother and add a higher layer of abstraction to collaborative robotics has been re-searched before [23]. Allowing machines and work objects to communicate with therobots in order to adjust the manufacturing process to fit a customers is anotheractive research topic [31, 32]. Accessing all the (massive) stream of data generatedby a factory as a new paradigm for manufacturing supervision. Researching pro-cedures for using the data generated by a plant as a mean to optimize the energyconsumption has been widely documented recently [4, 28, 29]. Increasing a robotscapability to communicate could also lead to smarter robots or robots that can learnexpert knowledge from human operators, as shown in [33]. In this research, a robotis teleoperated by an expert user in order to weld parts with a complicated geom-etry. The robots connection to the Internet makes it possible for the operator tocontrol the robot from a distant place. It is also possible for the robot to learn fromthe movements and procedures that the expert user performs in order to become abetter solder; In this case, a more powerful computer runs the algorithm that therobot executes.

19


4 Research methodology

4.1 Overview

The research methodology used in this thesis is based on the well-defined andsystematic approach mentioned in [34] and [35]. After analyzing and contrastingthese works with the objectives of the thesis, “System Development” is the researchmethodology that is employed in the thesis. This methodology strives to answertheoretical questions where the solution is hard to find without a real prototypeor where the objective is to apply existing technology in an innovative way. Thismethodology is a systematic and intensive approach that follows five main steps, asdemonstrated in Figure 5:

1. Construct a conceptual framework

2. Develop a system architecture

3. Analyze and design the system

4. Building the prototype

5. Observation and evaluation

Figure 5: The System Development methodology. Note that the arrows indicate that theprocess can be iterative (it is allowed to go to previous stages if needed).

4.2 Conceptual Framework

A Conceptual framework is constructed by establishing clear research objectives andexpected outcomes. The functionality of the system must be defined in a high-levelway. Theoretical work must be carried out in order to better understand the researchproblem and to be able to reach a better result. Aiding and related disciplines mustalso be defined and studied in this step.

4.2.1 Research Objectives

After connecting several industrial robots and other monitoring devices (such as PCsand tablets) within the same network, we will attempt to analyze the performance ofthe communication within the industrial robots under different, predefined, testingconditions. Latency over payloads within the local network in which the robotsexchange their data is the main parameter to analyze.

20


4.2.2 Expected Outcomes

Regarding the implementation outcomes, it is expected to have a fully functionaldata exchange software that can seamlessly integrate multi-platform clients (Vx-Works, Windows, Android, etc) in order to simplify, enhance and monitor robotictasks. This data exchange is expected to bring the following benefits:

1. The robots will be able to communicate with each other and exchange data.

2. The data of the whole system will be easily accessed and displayed, even inon-line applications.

On a research level, after designing a system that can accomplish the aforementionedimplementation goals, we expect to have answered the research questions of thisthesis. In other words, this thesis will provide a good insight, backed up with testresults and other studies, about the possibilities of implementing a robot to machinecommunication based on DDS. Moreover, the thesis will deal with the constraintsthat this kind of communication would pose to real-time-centric applications whileanalyzing its performance and weighting in the advantages and disadvantages ofchoosing DDS for an ABB industrial robot.

4.3 System Architecture

Developing a system architecture is a step of the research that consists in definingthe components that will form the system, as well as the way these componentswork with each other. During this stage, all the constraints for the system need tobe taken into account to ensure a successful prototype. A complete section of thisthesis is dedicated to an in-depth explanation of the system’s architecture.

4.4 Analysis and Design

Analyzing and designing the system consists on applying technical knowledge aboutthe project in order to devise possible solutions to build the system. In the contextof this thesis, the provided hardware will be analyzed and an initial design will betraced

4.4.1 Initial Design

In order to start designing the system, the techniques and technologies that willbe used for it will be defined. The hardware that the system contains dictatesmany of the requirements that must be followed in order to develop a system withsaid components. For example, ABB robots can only be programmed with theRAPID programming language. Similarly, the robot controller’s operating systemand the DDS-based product that will be employed reduce the communication-centricprogramming language options to C and C++. It is important that the initial designof the system takes into account these imposed constraints.

21


4.4.2 Time Constraints

Regardless of the scope of the project, the main limiting factor in most thesis worksis the time, and this project is no different. Planning the design process needs tobe closely related to the amount of time that the thesis work has available. Thescope, objectives and outcomes of the project have all been declared after takinginto account the time constraints that this thesis will follow.

4.5 Development

As the name implies, this stage is all about developing the prototype that will helpto answer the proposed research questions.

4.5.1 Development Stages

The hardware provided already consists of two industrial robots, each one equippedwith a robot controller connected to a network by means of a switch. The firstdevelopment phase will focus on writing the software that is needed for enabling aDDS-based communication between the industrial robots. Developing a robot appli-cation that can send and receive data from the aforementioned communication willbe the next phase once the DDS-communications is working. After developing thispreliminary application, the main priority will switch to measuring the performanceproperties of the implemented communication between the robots and other partsof the network.

4.6 Observation and Evaluation

By observing and analyzing the developed prototype, one can learn about the ques-tions that were posed as the objective of the research. In order to do this, a seriesof experiments will be performed. The setup, as well as the results of each test willbe logged in different “test cases” that will be reported in the following sections.

22


5 System architecture

5.1 Overview

The system will contain three main entities:

1. The ABB industrial robots.

2. A central Windows-based computer.

3. Local monitoring devices.

It is important to note that the experiments are performed with only two ABBindustrial robots. The main entities of the system are connected by an Ethernetconnection that goes through a Cisco 2960 Switch. A wireless access point is con-nected to the Cisco 2960 switch in order to facilitate access to monitoring devices(like tablets or mobile phones). Figure 6 showcases the architecture of the developedsystem. Many entities of the system are very different from each other, thus, their

Figure 6: The architecture of the intended system. The node “Robot Task” consists of thecommands to be executed by the robot. This module is accessed through TCP Sockets by acommunication module, which is where all the DDS facilities are located.

available interfaces, as well as the programming languages in which the softwarecan be written for them, vary greatly. As shown in Figure 7, the Windows 7-basedcentral computer integrates the DDS software using a C# application. This ap-plication also publishes the data to Microsoft’s cloud computing platform, Azure.Since the industrial robot controllers are based on VxWorks, the software is createdusing C++. The C++ applications on the robot controllers communicate with therobot’s program, which is written in ABB’s RAPID by means of a socket. We willanalyze each entity in detail in the upcoming sections.

5.2 The Robot Controller

A Robot controller is the device responsible for the robots correct program execu-tion, motion control and many other functions. The controller’s firmware is basedon VxWorks, therefore, C and C++ applications can run on the controller. Therobot’s program is written in an ABB’s proprietary language called RAPID. The

23


Figure 7: The relationships among the entities, as well as the programming languages usedto make the software vary between devices.

RAPID programming language provides a high-level of abstraction for commandingthe robot. It also provides a set of functions that can interact with other non-robotrelated components, like a socket-based networking capabilities and inter-processcommunication message queues.

5.2.1 The Teach-Pendant

ABB’s robot controller has an interface device that can control the execution ofthe program, the controller’s configuration parameters or even manually jog therobot. This interface is called the “Teach Pendant”. The aforementioned device isused during our thesis work in order to load and resume the execution of both thefirmware-related VxWorks programs and the RAPID-based instructions.

5.2.2 The Controller’s Firmware

The robot controller runs on top of a VxWorks installation. This real-time operatingsystem is responsible for deploying the tasks employed by the controller, among otheradministrative and security features. In this prototype, the controller runs a C++script that interfaces the RAPID-based program that the robot runs with the DDSpublish/subscribe functionality required to communicate with other parts of thesystem. RAPID-based programs have the capability to communicate with externalapplications by several means, like Transmission Control Protocol (TCP) sockets.The simplest alternative to connect the RAPID program with the C++ applicationis to use the aforementioned socket capabilities. This solution increases the overheadand response times of the overall system, therefore, measurements and an analysisof this performance impact is presented in the following sections.

5.3 The Central PC

The central PC is a Windows 7 based computer that runs a C# program thatimplements the DDS libraries. This computer is meant to issue commands to therobots, as well as logging and monitoring the work carried out by them.

24


6 Implementation

In this section, we explain how the DDS communication was implemented on theexperimental setup used to build the prototype, which served both as a proof of con-cept and as a benchmark for testing the feasibility of a DDS-based communicationscheme in ABB’s industrial robots.

6.1 The Base Experimental Setup

Before the start of this thesis work, a basic setup was already implemented using asimple, socket-based, communication. An explanation of this setup, which later wasadapted to work with DDS, is now presented. As stated before, the desired networktopology that will be tested consists of three main entities:

• ABB robot with industrial robot controller 1 (R1).

• ABB robot with industrial robot controller 2 (R2).

• A PC (Windows 7 x64) showing the shared data in real-time.

The experiment consists of a data exchange in order to pick and place a work objecton different X and Y coordinates in a shared work area. It is intended that eachrobot will randomly generate the coordinates of a new position on the plane andwill place the object there. Afterwards, the other robot will obtain the coordinatesfrom the first robot, pick-up the object and move it to a new randomized position.The Central computer can subscribe to the data of the system and visualize whatthe robots are sending to each other in real-time. The algorithm that the robotsrun for the experiment, compels with the following logic: Once the first robot (R1)picks the work object from a known start point...

• R1 generates random X and Y coordinates.

• R1 places the work object in the coordinates.

• R1 returns to its home position.

• R1 sends the coordinates to R2.

• R2 picks the object from the received position.

• R2 generates random X and Y coordinates.

• R2 places the object at the new positions.

• R2 returns to its home position.

• R2 sends the coordinates to R1.

• R1 picks the object from the received position.

These steps are repeated until a stop command is issued to any of the robot con-trollers. The communication between this robots is implemented using the thebuilt-in RAPID socket functions.

25


6.2 The DDS Experimental Setup

The aforementioned functionality of the base setup is ported to a DDS proof-of-concept experiment that showcases the feasibility of running DDS on an ABB robotcontrollers and use the setup to implement a more advanced communication schemeamong the involved entities. Aside from the data exchange between the robots,the system is able to showcase the information being shared through the centralcomputer.

6.3 The Communication Algorithm

This subsection showcases the steps performed by the code written in RAPID (ex-ecuted by the robot) and in C++ (executed internally in the controller). It alsodescribes in more formal terms the separation of the tasks performed during the al-gorithm, as well as the alternating order in which the robots and the C++ modulesperform their steps.

6.3.1 Robot R1’s Algorithm

Below is a short description of the execution steps that R1 performs. A flowchartdepicting the algorithm is shown in Figure 8.

1. R1, the first one of our pair of robots, starts by grabbing the work object froman initially known position, generates a set of XY coordinates randomly andsends them to the C++ module.

2. The C++ module receives the new XY position and publishes it to the DDSdomain. After that it starts waiting for a new XY pair to be published in theDDS domain.

3. R2’s execution starts at this point and ends with its C++ module publishingdata to the DDS domain.

4. R1’s C++ module detects the published data and sends that to the RAPIDprogram of the robot. It then proceeds to wait for new data from the robot.

5. R1 receives the new XY position, grabs the object, and generates a new set ofcoordinates. The object is placed and the data sent to the C++ module. Thecycle repeats from step 2, on-wards.

6.3.2 Implementing the C++ Module

Speed was an important factor to take into account when coding the C++ code thatexecutes in the VxWorks 7-based controller. As stated in the DDS distribution’stechnical manual, the built-in mechanism that the DDS distribution employs toasynchronously fetch DDS publications through interrupts has an inherent lag thataffects applications in situations where speed is a key factor. For this reason, thealgorithm was coded to use both the default fetching mechanism (fetching) and apoling fetching mechanism. It is worth noting that the both fetching mechanisms

26


Figure 8: Flow chart depicting the steps performed by R1’s RAPID and C++ algorithms.

27


are employed in the C++ algorithm enclosed in a while loop. The inherent lag thatthe asynchronous mechanism presents slightly impacts the overall response time ofthe algorithm, as seen in the results.The priority assigned to the VxWorks task that serves as our communication layeris 1, therefore it runs with the second highest priority possible. This priority waschosen because it is not desired to impact the performance of the tasks with thehighest priority in the controller, such as the motion control tasks, etc, since doingso could lead to severe consequences. There are other controller-related tasks thatrun with a higher priority, unfortunately, the type of tasks and other informationabout them is not allowed in the scope of this thesis. What can be said is that thepriority of the communication task, as well as the other tasks executing at a higherrate allow the communication task to be executed once every 0.182ms on average.

6.3.3 Robot R2’s Algorithm

R2’s algorithm follows the same logic as R1’s. Nonetheless, since R1 is responsiblefor starting the data exchange, R2’s algorithm starts by waiting for new informationfrom R1, as opposed to picking up an object. R2 continues the algorithm andperforms the same steps as R1 from this point. Figure 9 showcases R2’s algorithm,both the RAPID code and the C++ communication layer. Figure 10 showcasesboth algorithms running side by side. This allows the reader to easily grasp thecommunication process performed by the robots and when the DDS exchanges occur.

28


Figure 9: Flow chart depicting the steps performed by R2’s RAPID and C++ algorithms.Note that, unlike R1, R2 waits for new data first and moves later.

29


Figure 10: Diagram showcasing the execution of R1’s and R2’s algorithms. The arrowsshowcase the data exchange, be it a DDS transmission or a local socket transmission.

30


7 Experimental Results and Evaluation

This section presents the methodology used to test the performance of the prototypesetup as well as the results obtained from the different experiments.

7.1 Testing Methodology

The main focus of the experiments is to measure latency against throughput. For agiven set of predefined parameters, the prototype setup is programmed to transferdummy packages from one robot to the other. As the test progresses, these packagesrange from 10 to 1000 bytes long. Each package is sent 1000 times to the robot inorder to ensure a statistically-accurate representation of the latency. First, thissection presents the latency of the communication scheme employed in the baseexperimental setup. Afterwards, measurements on the prototype system are shown,as well as measurements on individual stages of the system. Finally, a comparisonbetween the two setups, as well as the prototype setup with different configurationparameters, is presented.

7.1.1 The Conducted Experiment

The experiment consists in sending a dummy string of an ’n’ amount of bytes. Thestring starts with ’n = 10’ and ’n’ is increased by 10 bytes after it gets sent 1000times. The testing message starts from one robot (R1) and reaches the other robot(R2). The second robot replies with the same message and the first robot logs theamount of time it took the string to make a round trip. Figure 11 shows how manymessages will be sent. In order to decrease the probability error, every transition isdone 100 times. Each experiment of test case is presented in the following format:

Test name What is the test measuring?Hardware Which hardware is involved?Com. Type Socket / Socket + DDS / DDS-onlyQoS prof. Reliable or Best effort? (DDS)Read met. Asynchronous or Synchronous.Ext. subs. Subscribers in the topic? (DDS)Str. subs. DDS throughput test (DDS)

Test name As it name implies, it is the name of the test case that is going tobe performed. This name is representative on what kind of experiment is beingconducted.

Hardware refers to all the involved equipment during the test. Routers andswitches as well as other ”secondary” devices are also included. Some tests areperformed using a Socket to Socket communication, while others use the completeDDS+Sockets setup.

31


Figure 11: The amount of bytes per transmission in the experiments. Each transmissionis repeated 100 times. Point A and Point B can represent the R1/R2 robots, the Rapid /Communication modules, only the Communication modules, etc (depending on the type ofexperiment).

32


Communication Type Specifies the type of communication used during the ex-periment. It refers to one of the three possible tests: Socket (RAPID program tocommunication layer via TCP Sockets), Socket + DDS (complete system), or DDSonly (communication layer to communication layer between robot controllers).

QoS profile refers to the DDS-specific Quality of Service profile that is chosenfor the experiment. During this work, the default QoS by the DDS distribution isused. The Reliability is the only aspect changed from the QoS, both Reliable andBest effort tests are taken into account. A Cisco 2976 switch with the default factorysettings was used. It is important to note that the switches configuration does notblocks or interferes with the QoS parameters of the DDS distribution.

Reading method As stated before, the DDS distribution can fetch new informa-tion in a synchronous or an asynchronous (interrupt-driven) way. This field in theexperiment indicates which fetching method was employed.

External and Stress subscribers The DDS distribution has many testing utili-ties that can be used to measure or cause stress on an application. Two of this toolsare the DDS subscribers test and the DDS performance test. The External sub-scribers test creates subscribers that fetch data from the test topic, which is whatthe parameter refers too. The performance test creates other topics that publishinformation as fast as possible in order to degrade the network’s performance. TheStress subscribers parameter indicates whether or not an experiment is conductedwith the performance test running and shows the magnitude of the payload that thetest is employing (in KB).

7.1.2 Data to be Logged

During the experiments, three main variables will be logged:

• The average latency at each payload (from 10 to 1000 Bytes).

• The variance that the measurements present.

• The latency of the worst performing case.

As the tests progresses and the complexity of the system grows, there are many dif-ferent parameters that can influence the performance of the overall system. Duringthese experiments, the default QoS profile that is offered in the DDS distribution isused as a base and a comparison between the ”Reliable” and ”Best effort” reliabilitypolicies is performed. Finally, the performance of the DDS communication can behindered by the traffic of the network, so an experiment of a scenario that wouldbe typical in an industrial setup is performed and the impact on the performance ofthe overall system is logged.

33


7.2 Socket Measurements

What we are going to measure in this experiment is the average latency that oc-curs on the basic setup that was the foundation of this thesis work; This is twoABB industrial robots with their robot controllers sharing data over a TCP socketconnection.

7.2.1 Basic Setup Measurements

On this experiment, the communication happens only between two robots by meansof TCP sockets. The performance of this case is offered as a reference point for thefuture measurements that are performed on the upcoming experiments. Figure 12shows the simple node-to-node communication that is tested.

Figure 12: Controller-to-controller socket communication. The test program is imple-mented on the RAPID modules from the base system.

The obtained results are shown in Table 1. Figure 13 shows the behavior of thesystem at different payloads.

Table 1: Socket to Socket Communication

Test name Socket to Socket latencyHardware Controller (2), Cisco 2976Com. Type Socket TCP on EthernetQoS prof. Not applicable.Read met. Not applicable.Ext. subs. Not applicable.Str. subs. Not applicable.

Average Latency 0.58951 msVariance 0.006866 msWorst case latency 1.1 ms

34


Figure 13: Socket communication: Latency vs Payload.

7.2.2 Observations

We can observe from the results that the setup used to share information betweentwo robots has an average latency of 0.58 ms. This latency barely increases as thepayload ascends in size. The worst case scenario was a transmission that took 1.1ms to complete. Both the average and the worst-case scenarios are going to serveas the basis for the comparison of the DDS-enabled system, which is expected to bemore flexible at the cost of speed and determinism.

35


7.3 Complete Setup Measurements

The complete system, as stated before, consists of the DDS link between the tworobot controllers plus the local sockets that connect the RAPID robot programwith the VxWorks C++ code that hosts the DDS libraries. The test results of thiscomplete system, along with the individual tests of the isolated DDS and VxWorks toRAPID performance are shown in this section. The DDS + Socket measurementsrepresent the “complete” system measures that a real-life implementation of theprototype would have.

Figure 14: The “Default” DDS measurements setup. This setup involves a data packettraveling from the RAPID module 1 to the RAPID module 2, going through the internalUDP Sockets and the VxWorks Kernel Modules that implement the DDS functionality.

The test case, as well as the results obtained from it are shown in Table 2. Figure14 shows the behavior of the system at different payloads.

Table 2: “Complete system”: DDS + Socket

Test name DDS + Socket measurement.Hardware Controllers (2), Cisco 2976.Com. Type DDSQoS prof. Best effort.Read met. Synchronous.Ext. subs. 0. No external subscribers.Str. subs. 0. No stress test.


36


Figure 15: Socket communication: Latency vs Payload. Note that the new Socket + DDSsetup increases the average latency by almost 1.5 ms

The same test is performed but a reliable QoS policy is chosen over the default“Unreliable” one. The average latency increases as we can see from the test case inTable 3 and Figure 16.

Table 3: “Complete system”: DDS + Socket

Test name DDS + Socket (reliable).Hardware Controller (2), Cisco 2976.Com. Type DDSQoS prof. Reliable.Read met. Synchronous.Ext. subs. 0. No external subscribers.Str. subs. 0. No stress test.


Figure 17 shows a comparison between two DDS tests where the only differenceis that the reliability has been modified in the QoS profile. When compared to the“Unreliable” test , the “Reliable” QoS profile produces a slightly bigger impact onperformance as the payload increases. This, among other results, is explained anddiscussed in following sections.

37


Figure 16: Socket communication: Latency vs Payload (Reliable). Changing the reliabilityparameter in the QoS increases the latency by approximately 0.1 ms

Figure 17: Socket communication: Reliable vs Best Effort. The 0.1 ms increase in latencyis more evident when comparing both plots side by side.

A comparison of the DDS measurements and the basic socket communication isshown in Figure 18. Some observations that are worth noting is the performanceimpact that the proposed setup has.

38


Figure 18: “DDS communication tests with Reliable” and “Best Effort” QoS as well asdirect Socket communication.

7.3.1 Observations

The most important comparison between the base system and the new DDS-enabledone is the fact that the average latency has greatly increased. The basic DDS test(default QoS) already poses a significant performance decrease. The modified QoStest that uses a reliable communication furtherly increases the average latency athigher payloads, but most importantly, the determinism of the system is decreased(as seen in the greater variance of the measurements). This increase in latency andvariance can be seen in Figure 17. Figure 18 shows a comparison of the two DDS+ Socket measurements with the Base system measurements. While this perfor-mance deterioration might seem discouraging, we have to keep in mind that thesoftware structure used during this thesis work did not allowed to implement theDDS middle-ware directly into the robot controller, instead, a DDS communicationlayer is being employed which greatly degrades performance. The amount of per-formance degradation caused because of the communication layer will be measuredin the following tests.

39


7.4 Communication Layer Measurements

The performance impact of the internal sockets connecting the VxWorks Kernel withthe Robot program is shown in this section. The measurement performed representsthe time necessary to deliver the packets of data from the Rapid program to theDDS Communication Module and back. Figure 19 shows the modules of the systemthat are going to be tested.

Figure 19: The impact performance caused by the communication layer is measured in justone of the robots. The packets have to travel from the RAPID module to the Communica-tion module and back in order to log their latency.

All of this happens in the same robot controller. The test case that showcasesthe settings used during the measurement is shown in Table 4. Figure 20 showcasesthe behavior of the internal socket scheme that is used in the prototype setup.

Table 4: “Internal socket: Latency test”

Test name Internal SocketsHardware Robot Controller(1)Com. Type UDP Socket.QoS prof. Not applicable.Read met. Not applicable.Ext. subs. Not applicable.Str. subs. Not applicable.


40


Figure 20: Internal sockets communication: Latency vs Payload. Here we can observe thatinternal socket setup has a considerable impact on the performance of the overall system.It is also worth mentioning that the variance of the latencies increases, as well as theworst-performing case.

7.4.1 Observations

It is evident that , while the average latency among the payloads is relatively small,the impact that this communication layer can have in the worst case scenarios ispretty high. This greatly reduces the determinism of the system and would diminishthe areas in which this technology would be applied, as stated before, the DDStechnology would need to be integrated at a deeper level with the controller in orderto be a feasible feature of ABB’s industrial line of robots.

41


7.5 DDS-specific Measurements

The latency that occurs between the DDS link (among two robot controllers) and theinternal socket link (among the Robot program and the VxWorks Kernel Module)is also measured separately. The latency between robots is the time it takes for amessage to go from one robot to the other one, passing through the robot controllers(which log the times). The latency between a robot and its controller is measuredby the time it takes to make a round trip from the controller, to the robot and thenback to the controller. Again, it is the controller the device that logs the elapsedtime. This subsection shows the performance of sending and receiving a packet ofdata in a round trip among the DDS link. This means that only the VxWorksKernel Modules in the robot controllers is involved in this process, without sendingthe data to the robot program. Table 5 shows the test case employed to measurethe performance of the DDS-based link between the Kernel Modules. The behaviorof this link can be seen in Figure 21.

Table 5: “DDS-only (no robot program): Controller-to-Controller test”

Test name DDSHardware Controllers (2), Cisco 2976.Com. Type DDS.QoS prof. Reliable.Read met. Synchronous.Ext. subs. 0. No external subscribers.Str. subs. 0. No stress test.


42


Figure 21: DDS-only test: Latency vs Payload. A slight increase in the average latencybut a considerable increment in the dispersion of the samples, which greatly affects theworst-case performance.

Figure 22 shows the performance impact that DDS has over the traditional end-to-end socket connection.

Figure 22: A slight increase in latency can be seen when opting for a DDS-based link overthe base Socket communication.

43


7.5.1 The DDS Performance Test

The DDS distribution provides a command-line utility that can be used to generateDDS traffic on a network and logging information about how much a DDS packagetakes to reach from a publisher to a subscriber. The tool is optimized to generatetraffic that puts a heavy stress under the overall DDS system. Many parameterscan be chosen from this tool, for example, the length of the data published, the QoSprofile, the publishing rate, etc. Using this tool serves two purposes for this thesis:

• Measure the performance of the Robots under network stress.

• Measure the performance of other systems while the robots work.

Figure 23: During the stress tests, the packet of data is sent from the RAPID 1 to RAPID2 and back. The node Perftest P publishes as much information as possible in order tosaturate the network, and the node Perftest S consumes the aforementioned data.

The testing setup, as seen in Figure 23, consists of two computers connected to thesame switch as the robot experimental setup. One computer works as a publisherwhile the other one works as a subscriber. The stress test is carried out with twosettings: Publishing and subscribing to a packet with a size of 1 KB and with apacket of 25 KB. Table 6 shows the test case that involves the Perftest stress testof 1 KB, while 7 shows the test case for the dataLength = 25 KB measurements.Figure 24 and Figure 25 show the performance of the experiments.

Table 6: “Stress test, data length = 1 KB, Reliable”

Test name Internal SocketsHardware Controllers (2), switch, Win7 PC(2)Com. Type DDS + Internal Sockets.QoS prof. Reliable.Read met. Synchronous.Ext. subs. Not applicable.Perftest. DataLength = 1 KB, QoS = Reliable


44


Figure 24: There is a performance degradation when the network is being used by otherpublishing and subscribing nodes.

Table 7: “Stress test, data length = 25 KB, Reliable”

Test name Internal SocketsHardware Controllers (2), switch, Win7 PC(2)Com. Type DDS + Internal Sockets.QoS prof. Reliable.Read met. Synchronous.Ext. subs. Not applicable.Perftest. DataLength = 25 KB, QoS = Reliable


45


Figure 25: It can be observed that there is a very slight performance degradation whencompared to the 1 KB long messages.

7.5.2 The DDS Subscribers Test

The performance impact that other topics have in the prototype setup has beenmeasured in this section. Here, the behavior of the system is examined when itneeds to publish and subscribe data alongside other processes that also subscribe tothe same topic. The DDS subscribers test tool is an utility that comes bundled withDDS distribution at use that can subscribe to any given topic in order to monitorthe information that is published by the other nodes. The utility also has thecapability of spawning several parallel processes, therefore, it is possible to connectseveral subscribers to a single publisher in order to witness the impact that this kindof connection would have on the system. The used setup consists of a computerconnected to the same switch as the two robot controllers. The connected computeris running the DDS subscribers test tool with a different number of subscribers, asshown in Figure 26. Table 8 shows the parameters used for this experiment whileFigure 27 shows the behavior of the system at different payloads.

46


Figure 26: The DDS module subscribes and consumes the data published in the topic thatthe industrial robots use.

Table 8: “DDS subscribers test tool”

Test name Latency measure, extra subscribersHardware Controllers (2), switch, Win7 PC(2)Com. Type DDS + Internal Sockets.QoS prof. Reliable.Read met. Synchronous.Ext. subs. 0, 1, 4, 10.Perftest. 0. Not applicable

Average Latency (10) 3.5576 msVariance (10) 0.1097 msWorst case latency (10) 5.9982 ms

Figure 27: Latency test with 0, 1, 4 and 10 subscribers. Notice that only the averagemeasurements are shown in this plot in order to increase the clarity.

47


7.5.3 Observations

In these measurements we could witness the real performance impact that is inherentof the DDS technology under different scenarios. First, we can see that the overallincrease of latency is small, as stated in the DDS-only test (refer to Figures 21 and22). Using the system while the included performance tools are running by publish-ing and subscribing many DDS messages significantly increases the average latencyof the system. The DDS stress test forces a publishing and a subscribing module totransfer as many DDS messages as possible between each other. The performancedegradation in the DDS-link of the robot controllers happens only when a the QoSpolicy forces the messages to be reliable. The DDS subscribers test creates nodesthat subscribe to the topic in which the robot controllers are exchanging data. Thesubscribing nodes are referred as DDS Spies by the distribution’s documentation.The Spies impact the performance of reliable DDS communications between therobot controllers in a proportional fashion.

48


7.6 Analysis and Discussion

In this part of the thesis, the timing measurements obtained from the various testcases will be interpreted and discussed within the context of whether or not DDSis a suitable solution for providing ABB industrial robots with flexible and scalablecommunication facilities.

7.6.1 Advantages: Flexibility and Scalability

As it has been discussed several times, the publish-subscribe model of DDS bringsa lot of benefits. For the demonstration system, flexibility and scalability are thetwo main gains from this new communication. The bandwidth stress experimentsshowcased in Figure 23 showcase that there is a latency increase when other nodesare subscribed to the topic. Nonetheless, the latency of the system scales at a veryslow rate even with high bandwidth traffic from other applications, which meansthat the system is suitable and scalable for many applications. It also shows thatthe number of subscribers consuming data from a topic has little-to-no impact onthe overall performance of the system, which means that this technology can be veryuseful for dynamically adding nodes to the application without worrying about aperformance impact.We can derive from the results that DDS has a small impact when compared to thesocket-only alternative. It is also a fortunate outcome that the biggest part of thelatency is caused by the internal communication layer, since the thread controllingthis communication relinquishes the CPU to controller-crucial activities that alsoneed to execute. This means that given the possibility to modify the controllers code,for example in a production environment, implementing DDS as part of RAPID, forexample, could eliminate this performance impact.

7.6.2 Disadvantages: Latency and Timeliness

As expected, the main issue with migrating a socket-based, end-to-end communi-cation from the base demonstration setup onto a DDS based one is the increase inlatency. Nonetheless, an interesting observation is that the overall performance ofthe system is mainly affected because of the extra communication layer that linksthe robot application and the DDS libraries. Figures 21 and 22 further demonstratethe small impact in the performance that the DDS-only communication producesover the traditional setup. In the current state of the demonstration setup, themain concern is the extra communication layer that produces approximately 68% ofthe overall latency, as shown in Figure 28. A Worst-case comparison demonstratesthat this software workaround can take up to 90% of the total transmission time, asshown in Figure 29.

49


Figure 28: Sockets, DDS (reliable) and DDS (unreliable) comparison: On the DDS mea-surements, the bar is separated in the time consumed by the DDS communication (lightblue) and the time consumed by the internal socket layer (dark blue).

Figure 29: Sockets, DDS (reliable) and DDS (unreliable) comparison (Worst case): Theamount of time that the internal socket has in order to .

50


7.6.3 Reliability in the QoS

The avid reader might have noted that the worst performance impacts happen whenemploying a DDS QoS profile where the reliability is enabled. Some experiments,like the DDS subscribers test, showcase a significant performance degradation onlywhen using this profile (Figure 27). This makes the need to appropriately tailor theQoS profiles depending on the task and for each individual node of the system. Forexample, in our main system that needs to be monitored from an external computerover the local network (Figure 6), the QoS profile employed by this observant dictatesan unreliable communication, since it is not necessary to receive all the transmissionsin real-time just to get an overview of the behavior of the system. Configuring thesystem appropriately and tweaking the QoS profiles accordingly (not just in thisvery superficial way) allows to connect a plethora of robotic elements, monitoringdevices, sensors, etc, without each other interfering with their performance.

51


8 Conclusions

8.1 Summary

During this thesis, the possibility of implementing a DDS-based communicationframework in an ABB industrial robot (coupled with its respective robot controller)is explored. While our solution’s architecture was effective, it was not efficientand most of the latency in the communication network was caused by the internalcommunication that happens in the software layer between the robot task and thecommunication module. This software layer does hamper the overall performance ofthe system by increasing the latency of the communication. Likewise, the existenceof an interconnecting layer between the RAPID programming code and the VxWorksKernel Module greatly decreases the determinism of the overall system by introduc-ing extra delays. Aside from these shortcomings, implementing this communicationwith DDS in the industrial controller is not only a feasible possibility, but also itbrings a plethora of benefits and possibilities for new applications. Two of the mostimportant benefits are flexibility and scalability, which bring bring many applicationopportunities, some of which will be discussed in the Future work subsection.

8.2 Future Work

8.2.1 RAPID/DDS Coupling

According to the experimental results and their evaluation conducted in this thesis,the biggest performance impact is created by the extra software layer that dotesthe RAPID program with DDS facilities. A tighter integration between the DDSmiddle-ware and the RAPID module needs to be developed, since the results clearlyshow that the longest and more varying delays are introduced by the coupling socketlayer that was developed to deal with the architectural limitations of the controller.Declaring a shared memory space for RAPID variables and constants that is acces-sible from the VxWorks Kernel Module or implementing some messaging queues aresome of the ways of improving the existing software workaround.

8.2.2 Possible Future DDS Use-cases

There exists several robotic processes that could benefit from a publish-subscribecommunication framework among industrial devices. This section presents somepossible future applications of DDS in an industrial robotics context.

Real-time analytics and monitoring Perhaps the clearest benefit from DDSis that the data on the different topics can be easily accessed by any DDS entity.Therefore, data analysis and monitoring can be easily implemented on robotic sys-tems in order to showcase information from the tasks they are performing.

Dynamic palletizing Palletizing processes are a common robotics application.The process consists on stacking an “n” number of goods together over a woodenbase (the pallet) in order to facilitate its transportation. A ”Dynamic Palletizer”

52


could create different pallets by following instructions of a central computer thatadministers the characteristics of the pallets to create based on parameters like theproducts dimensions, available robots, etc. This would take away complexity fromthe robots by moving the processes to a computer in a local cloud and increase theflexibility of the palletizing cell.

Product customization Several industrial processes can benefit from the shareddata that DDS makes available, and this could be used to customize the productsoffered by the manufacturer company. Swapping painting robots or using differentpackagings according to user requests are some basic customizations that a clientcould request and a robot with access to that data could react accordingly.

53


References

[1] J. Civera, M. Ciocarlie, A. Aydemir, K. Bekris, and S. Sarma, “Guesteditorial: Special issue on cloud robotics and automation,” IEEE Transactionson Automation Science and Engineering, vol. 12, no. 2, pp. 396–397,Apr 2015. [Online]. Available: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7057679

[2] B. Kehoe, A. Matsukawa, S. Candido, J. Kuffner, and K. Golberg,“Cloud-based robot grasping with the google object recognition engine,” IEEEInternational Conference on Robotics and Automation (ICRA), Karlsruhe,Germany,, 2013. [Online]. Available: http://goldberg.berkeley.edu/pubs/Grasping-with-Google-Goggles-icra-2013.pdf

[3] B. Kehoe, S. Patil, P. Abbeel, and K. Goldberg, “A survey of researchon cloud robotics and automation,” in IEEE Transactions on AutomationScience and Engineering, K. Goldberg, Ed., vol. 12, no. 2. IEEE Roboticsand Automation Society, Apr 2015, pp. 398–409. [Online]. Available:http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7006734

[4] F. Shrouf, J. Ordieres, and G. Miragliotta, “Smart factories in industry 4.0:A review of the concept and of energy management approached in productionbased on the internet of things paradigm,” in IEEE International Conferenceon Industrial Engineering and Engineering Management (IEEM), Dec 2014, pp.697–701. [Online]. Available: http://dx.doi.org/10.1109/IEEM.2014.7058728

[5] C. Perera, C. Liu, S. Jayawardena, and M. Chen, “A survey on internet of thingsfrom industrial market perspective,” Access, IEEE, vol. 2, pp. 1660–1679,2014. [Online]. Available: http://dx.doi.org/10.1109/ACCESS.2015.2389854

[6] Y. Lu, K. C. Morris, and S. Frechette, “Standards landscape anddirections for smart manufacturing systems,” in Automation Scienceand Engineering (CASE), Aug 2015, pp. 998–1005. [Online]. Available:http://dx.doi.org/10.1109/CoASE.2015.7294229

[7] J. Yang, “Data distribution service for industrial automation,” Masterthesis in intelligent Embedded Systems, Sep 2012. [Online]. Available:http://www.idt.mdh.se/utbildning/exjobb/files/TR1345.pdf

[8] Robots and robotic devices – Vocabulary, International Organization for Stan-darization. ISO 8373:2012, 2012.

[9] A. Robotics, “Technical reference manual: Rapid instructions,functions and data types,” pp. 433–460, 2004. [Online]. Avail-able: https://library.e.abb.com/public/688894b98123f87bc1257cc50044e809/Technical%20reference%20manual RAPID 3HAC16581-1 revJ en.pdf

[10] “Data distribution service (dds) version 1.4,” The Object Management Group,2015. [Online]. Available: http://www.omg.org/spec/DDS/1.4/PDF/

54

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7057679

http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=7057679

http://goldberg.berkeley.edu/pubs/Grasping-with-Google-Goggles-icra-2013.pdf

http://goldberg.berkeley.edu/pubs/Grasping-with-Google-Goggles-icra-2013.pdf

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=7006734

http://dx.doi.org/10.1109/IEEM.2014.7058728

http://dx.doi.org/10.1109/ACCESS.2015.2389854

http://dx.doi.org/10.1109/CoASE.2015.7294229

http://www.idt.mdh.se/utbildning/exjobb/files/TR1345.pdf

https://library.e.abb.com/public/688894b98123f87bc1257cc50044e809/Technical%20reference%20manual_RAPID_3HAC16581-1_revJ_en.pdf

https://library.e.abb.com/public/688894b98123f87bc1257cc50044e809/Technical%20reference%20manual_RAPID_3HAC16581-1_revJ_en.pdf

http://www.omg.org/spec/DDS/1.4/PDF/


[11] T. S. S. of ITU, “Definitions of terms related to quality of service,” Qualityof telecommunication services: concepts, models, objectives and dependabilityplanning Terms and definitions related to the quality of telecommunicationservices, 2008. [Online]. Available: https://www.itu.int/rec/dologin pub.asp?lang=e&id=T-REC-E.800-200809-I!!PDF-E&type=items

[12] “Digital data communications for measurement and control - fieldbus for use inindustrial control systems - section 1: Modbus application protocol specificationv1.1a - section 2: Real-time publish-subscribe (rtps) wire protocol specificationversion 1.0,” Industrial process measurement and control, 2004.

[13] “Real-time publish-subscribe (rtps) wire protocol specification,” Nov 2004.

[14] H. Perez and J. J. Gutierrez, “A survey on standards for real-time distributionmiddleware,” ACM Comput. Surv., vol. 46, no. 4, Mar.

[15] L. Sha, T. Abdelzaher, K.-E. A. rzen, A. Cervin, T. P. Baker, A. Burns, G. But-tazzo, M. Caccamo, J. P. Lehoczky, and A. K. Mok, “Real Time SchedulingTheory: A Historical Perspective,” Real-Time Systems, vol. 28, no. 2/3, pp.101–155, 2004.

[16] J. Manyika, M. Chui, P. Bisson, J. Woetzel, R. Dobbs, J. Bughin,and D. Aharon, “The internet of things: Mapping the value beyondthe hype,” Mckinsey Global Institute, Tech. Rep., Jun 2015. [On-line]. Available: http://www.mckinsey.com/∼/media/McKinsey/Business%20Functions/McKinsey%20Digital/Our%20Insights/The%20Internet%20of%20Things%20The%20value%20of%20digitizing%20the%20physical%20world/Unlocking the potential of the Internet of Things Executive summary.ashx

[17] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and M. Ayyash,“Internet of things: A survey on enabling technologies, protocols, andapplications,” Communications Surveys Tutorials, IEEE, vol. 17, no. 4,pp. 2347–2376, 2015. [Online]. Available: http://dx.doi.org/10.1109/COMST.2015.2444095

[18] J. Tervonen, V. Isoherranen, and M. Heikkila, “A review of thecognitive capabilities and data analysis issues of the future industrialinternet-of-things,” in 6th IEEE International Conference on CognitiveInfocommunications (CogInfoCom), Oct 2015, pp. 127–132. [Online].Available: http://dx.doi.org/10.1109/CogInfoCom.2015.7390577

[19] K. Zhou, T. Liu, and L. Zhou, “Industry 4.0: Towards future industrialopportunities and challenges,” in 12th International Conference on FuzzySystems and Knowledge Discovery (FSKD), Aug 2015, pp. 2147–2152. [Online].Available: http://dx.doi.org/10.1109/FSKD.2015.7382284

[20] B. Ding, H. Wang, Z. Fan, P. Zhang, and H. Liu, “Microsdrt: supporting real-time and scalable data distribution in distributed robotic systems,” in Roboticsand Biomimetics. Springer Open, 2016. [Online]. Available: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4865524/pdf/40638 2016 Article 38.pdf

55

https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-E.800-200809-I!!PDF-E&type=items

https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-E.800-200809-I!!PDF-E&type=items

http://www.mckinsey.com/~/media/McKinsey/Business%20Functions/McKinsey%20Digital/Our%20Insights/The%20Internet%20of%20Things%20The%20value%20of%20digitizing%20the%20physical%20world/Unlocking_the_potential_of_the_Internet_of_Things_Executive_summary.ashx




http://dx.doi.org/10.1109/COMST.2015.2444095

http://dx.doi.org/10.1109/COMST.2015.2444095

http://dx.doi.org/10.1109/CogInfoCom.2015.7390577

http://dx.doi.org/10.1109/FSKD.2015.7382284

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4865524/pdf/40638_2016_Article_38.pdf

https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4865524/pdf/40638_2016_Article_38.pdf


[21] S. Limsoonthrakul, M. N. Dailey, M. Srisupundit, S. Tongphu, andM. Parnichkun, “A modular system architecture for autonomous robotsbased on blackboard and publish-subscribe mechanisms,” in Robotics andBiomimetics, 2009, pp. 633–638. [Online]. Available: http://dx.doi.org/10.1109/ROBIO.2009.4913075

[22] O. Dolejs, P. Smolik, and Z. Hanzalek, “On the ethernet use for real-timepublish-subscribe based applications,” in IEEE International Workshop onFactory Communication Systems, 2004, pp. 39–44. [Online]. Available:http://dx.doi.org/10.1109/WFCS.2004.1377674

[23] M. Stenmark, J. Malec, K. Nilsson, and A. Robertsson, “On distributedknowledge bases for robotized small-batch assembly,” IEEE Transactions onAutomation Science and Engineering, vol. 12, no. 2, pp. 519–528, Apr 2015.[Online]. Available: http://dx.doi.org/10.1109/TASE.2015.2408264

[24] Z. Shi, J. Wei, X. Wei, K. Tan, and Z. Wang, “The task allocation modelbased on reputation for the heterogeneous multi-robot collaboration system,”in 2010 8th World Congress on Intelligent Control and Automation (WCICA),2010, pp. 6642–6647. [Online]. Available: http://dx.doi.org/10.1109/WCICA.2010.5554165

[25] D. k. Liu, D. Wang, and G. Dissanayake, “A force field method basedmulti-robot collaboration,” in IEEE Conference on Robotics Automation andMechatronics, 2006, pp. 1–6. [Online]. Available: http://dx.doi.org/10.1109/RAMECH.2006.252693

[26] J. T. C. Tan, F. Duan, Y. Zhang, R. Kato, and T. Arai, “Safety design anddevelopment of human-robot collaboration in cellular manufacturing,” in IEEEInternational Conference on Automation Science and Engineering, 2009, pp.537–542. [Online]. Available: http://dx.doi.org/10.1109/COASE.2009.5234120

[27] A. Bechar, Y. Edan, and J. Meyer, “Optimal collaboration in human-robottarget recognition systems,” in IEEE International Conference on Systems,Man and Cybernetics, vol. 5, 2006, pp. 4243–4248. [Online]. Available:http://dx.doi.org/10.1109/ICSMC.2006.384801

[28] P. Brizzi, D. Conzon, H. Khaleel, R. Tomasi, C. Pastrone, A. Spirito,M. Knechtel, F. Pramudianto, and P. Cultrona, “Bringing the internet ofthings along the manufacturing line: A case study in controlling industrialrobot and monitoring energy consumption remotely,” in IEEE 18th Conferenceon Emerging Technologies Factory Automation (ETFA), Sep 2013, pp. 1–8.[Online]. Available: http://dx.doi.org/10.1109/ETFA.2013.6647947

[29] C. Lee, C. Yeung, and M. Cheng, “Research on iot based cyber physicalsystem for industrial big data analytics,” in IEEE International Conference onIndustrial Engineering and Engineering Management (IEEM), Dec 2015, pp.1855–1859. [Online]. Available: http://dx.doi.org/10.1109/IEEM.2015.7385969

56

http://dx.doi.org/10.1109/ROBIO.2009.4913075

http://dx.doi.org/10.1109/ROBIO.2009.4913075

http://dx.doi.org/10.1109/WFCS.2004.1377674

http://dx.doi.org/10.1109/TASE.2015.2408264

http://dx.doi.org/10.1109/WCICA.2010.5554165

http://dx.doi.org/10.1109/WCICA.2010.5554165

http://dx.doi.org/10.1109/RAMECH.2006.252693

http://dx.doi.org/10.1109/RAMECH.2006.252693

http://dx.doi.org/10.1109/COASE.2009.5234120

http://dx.doi.org/10.1109/ICSMC.2006.384801

http://dx.doi.org/10.1109/ETFA.2013.6647947

http://dx.doi.org/10.1109/IEEM.2015.7385969


[30] E. Pinto, P. Deusdado, F. Marques, A. Loureno, R. Mendona, P. Santana,L. Flores, and J. Barata, “A health and usage monitoring systemfor ros-based service robots,” in 10th International Symposium onMechatronics and its Applications (ISMA), 2015, pp. 1–6. [Online].Available: http://dx.doi.org/10.1109/ISMA.2015.7373493

[31] B. Hameed, I. Khan, F. Durr, and K. Rothermel, “An rfid based consistencymanagement framework for production monitoring in a smart real-timefactory,” in Internet of Things (IOT), 2010, Nov 2010, pp. 1–8. [Online].Available: http://dx.doi.org/10.1109/IOT.2010.5678436

[32] M. Weyrich, J.-P. Schmidt, and C. Ebert, “Machine-to-machine communica-tion,” Software, IEEE, vol. 31, no. 4, pp. 19–23, Jul 2014. [Online]. Available:http://dx.doi.org/10.1109/MS.2014.87

[33] Y. Liu and Y. Zhang, “Toward welding robot with human knowledge:A remotely- controlled approach,” in IEEE Transactions on AutomationScience and Engineering, K. Goldberg, Ed., vol. 12, no. 2. IEEE Roboticsand Automation Society, Apr 2015, pp. 769–764. [Online]. Available:https://dx.doi.org/10.1109/TASE.2014.2359006

[34] J. F. Nunamaker and M. Chen, “Systems development in informationsystems research,” System Sciences. Proceedings of the Twenty-ThirdAnnual Hawaii International Conference, vol. 3, pp. 631–640, 1990.[Online]. Available: http://gkmc.utah.edu/7910F/papers/JMIS%20systems%20development%20in%20IS%20research.pdf

[35] G. Dodig-Crnkovic, “Scientific methods in computer science,” in Conferencefor the Promotion of Research in IT at New Universities and atUniversity Colleges in Sweden, 2002, 2002. [Online]. Available: http://www.mrtc.mdh.se/publications/0446.pdf

[36] K. Goldberg, Ed., Editorial: Multiplicity has more potential than singularity,vol. 12, no. 2. IEEE Robotics and Automation Society, Apr 2015.[Online]. Available: http://ieeexplore.ieee.org.ep.bib.mdh.se/stamp/stamp.jsp?tp=&arnumber=7057690

57

http://dx.doi.org/10.1109/ISMA.2015.7373493

http://dx.doi.org/10.1109/IOT.2010.5678436

http://dx.doi.org/10.1109/MS.2014.87

https://dx.doi.org/10.1109/TASE.2014.2359006

http://gkmc.utah.edu/7910F/papers/JMIS%20systems%20development%20in%20IS%20research.pdf

http://gkmc.utah.edu/7910F/papers/JMIS%20systems%20development%20in%20IS%20research.pdf

http://www.mrtc.mdh.se/publications/0446.pdf

http://www.mrtc.mdh.se/publications/0446.pdf

http://ieeexplore.ieee.org.ep.bib.mdh.se/stamp/stamp.jsp?tp=&arnumber=7057690

http://ieeexplore.ieee.org.ep.bib.mdh.se/stamp/stamp.jsp?tp=&arnumber=7057690

enabling data sharing with dds on real-time constrained industrial robots - diva...

Documents