Aalborg Universitet
A Plug and Produce Framework for Industrial Collaborative Robots
Schou, Casper; Madsen, Ole
Published in:
International Journal of Advanced Robotic Systems
DOI (link to publication from Publisher):
10.1177/1729881417717472
Creative Commons License
CC BY 4.0
Publication date:
2017
Document Version
Publisher's PDF, also known as Version of record
Link to publication from Aalborg University
Citation for published version (APA):
Schou, C., & Madsen, O. (2017). A Plug and Produce Framework for Industrial Collaborative Robots.
International Journal of Advanced Robotic Systems, 14(4). https://doi.org/10.1177/1729881417717472
General rights
Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners
and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.
- Users may download and print one copy of any publication from the public portal for the purpose of private study or research.
- You may not further distribute the material or use it for any profit-making activity or commercial gain
- You may freely distribute the URL identifying the publication in the public portal -
Take down policy
If you believe that this document breaches copyright please contact us at vbn@aub.aau.dk providing details, and we will remove access to
the work immediately and investigate your claim.
Downloaded from vbn.aau.dk on: August 26, 2022
Research Article
A plug and produce framework
for industrial collaborative robots
Casper Schou and Ole Madsen
Abstract
Collaborative robots are today ever more interesting in response to the increasing need for agile manufacturing
equipment. Contrary to traditional industrial robots, collaborative robots are intended for working in dynamic envir-
onments alongside the production staff. To cope with the dynamic environment and workflow, new configuration and
control methods are needed compared to those of traditional industrial robots. The new methods should enable shop
floor operators to reconfigure the robot. This article presents a plug and produce framework for industrial collaborative
robots. The article focuses on the control framework enabling quick and easy exchange of hardware modules as an
approach to achieving plug and produce. To solve this, an agent-based system is proposed building on top of the robot
operating system. The framework enables robot operating system packages to be adapted into agents and thus supports
the software sharing of the robot operating system community. A clear separation of the hardware agents and the higher
level task control is achieved through standardization of the functional interface, a standardization maintaining the
possibility of specialized function features. A feasibility study demonstrates the validity of the framework through a series
of reconfigurations performed on a modular collaborative robot.
Keywords
Collaborative robot, multiagent system, plug and produce, human robot interaction, modular architecture, robot
operating system, primitives, robot reconfiguration
Date received: 25 May 2016; accepted: 19 May 2017
Topic: Robotics Software Design and Engineering (ROSENG)
Topic Editor: Anis Koubaa
Associate Editor: Salvatore Graziani
Introduction
In response to the challenges derived from the globalization,
manufacturing companies today face the need for more flex-
ible and agile manufacturing equipment. Traditional indus-
trial robots constitute a flexible manufacturing resource as
they hold the option to be reprogrammed to perform new
tasks. However, once the robot is commissioned in a man-
ufacturing line, it is often fixed to a dedicated workstation
doing a single repetitive task. As a result, the original flex-
ibility is not utilized. Collaborative robots, on the other hand,
are intended to operate in the more dynamic production
environment of the human operators with lower batch sizes,
greater variety, diverse tasks, and more frequent change-
overs. In this context, the reconfiguration of the robot to a
new task should no longer be an engineering task but should
be handled by the production staff. However, this requires
new approaches to configuring (installing, equipping, pro-
gramming) and operating the collaborative robot as com-
pared to a traditional industrial robot.
1
The transitioning of a collaborative robot to a new task
covers two main reconfigurations: (1) programming the robot
to the new task, and (2) configuring the hardware of the robot.
Department of Materials and Production, Aalborg University, Aalbo rg,
Denmark
Corresponding author:
Casper Schou, Aalborg University, Fibigerstraede 16, Aalborg 9220,
Denmark.
Email: cs@m-tech.aau.dk
Interna tion al Journal of Advanced
Robotic Sy stems
July-August 2017: 1–10
ª The Author(s) 2017
DOI: 10.1177/1729881417717472
journals.sagepub.com/home/arx
Creative Commons CC BY: This article is distributed under the terms of the Creative Commons Attribution 4.0 License
(http://www.creativecommons.org/licenses/by/4.0/) which permits any use, reproduction and distribution of the work without
further permission provided the original work is attributed as specified on the SAGE and Open Access pages (https://us.sagepub.com/en-us/nam/
open-access-at-sage ).
In the industry, the variation in tasks is often of such magnitude
that they cannot be solved by a single hardware configuration.
2
Thus, the need for hardware reconfiguration emerges.
In previous research, we have focused on intuitive robot
programming and industrial applications for collaborative
robots.
3,4
Through this work it has become clear to us that
as the task variety increases, simply reprogramming the robot
is not sufficient; the hardware must be reconfigured as well.
Thus, it is our experience from prior research that hardware
reconfiguration is inevitable in industry. Consequently, our
ongoing research on hardware reconfiguration for collabora-
tive robots is rooted in these practical experiences and
applications.
Recent work by Schou and Madsen
5
propose the follow-
ing four research objectives as a roadmap toward an intui-
tive hardware management framework that enables shop
floor operators to perform the hardware reconfiguration
of a collaborative robot:
modular architecture,
module selection,
module exchange, and
module utilization.
If shop floor operators are to exchange hardware mod-
ules of the robot at the shop floor, the exchange must be fast
and efficient, and it should not require mechanical,
robotics, or programming expertise. Hence, the hardware
exchange should be done in a plug and produce manner.
Realizing this requires not only standardization of the phys-
ical interfaces between the modules but also standardiza-
tion of the control interfaces. Schou and Madsen
5
present a
conceptual overview of an envisioned architecture for a
plug and produce framework.
In this article, we propose, design, and demonstrate a
plug and produce framework for modular collaborative
robots based on robot operating system (ROS).
6
We adopt
the architecture outline from Schou and Madsen
5
and use
this outline to propose an architecture for a hardware man-
agement framework. The framework allows ROS drivers
from the ROS community to be used within the framework
with only very limited adaptation. In extend to the hard-
ware management framework, we also propose a function
generalization which supports the use of both generic and
specific device functionality.
The remaining part of the article is structured as follows.
Related research is presented in the second section. The third
section describes the concept and implementation of the
hardware management framework. Results from a feasibility
study of the presented framework are described in the fourth
section, and the last section draws the conclusions.
Related research
The idea of plug and produce was first proposed by Arai
et al.
7
as a response to the need for agile manufacturing
systems. The te rm is d erived from the “plug and play”
concept of the IT world. The purpose of plug and produce
is to enable quick (un)plugging of components from a man-
ufacturing system with little to no reprogramming and
reconfiguration of the remaining system. Since the manu-
facturing equ ipment do main is vast, complex, and lacks
standardization of interfaces, a modular hardware architec-
ture is often introduced to encapsulate components as mod-
ules with well- defined interfaces. Several authors have
presented modular hardware architectures for robotics.
8–17
In extend to the physical structure, the control and commu-
nication ar chitecture must als o be considered. One
approach is agent-based systems in which active modules
become independent agents. Agents have some degree of
self-contained control and can provide and request func-
tionality to the rest of the system. Agent-based systems or
multiagent systems originate from the computational
domain; however, agent-based approaches have been pro-
posed in many different aspects of manufacturing enter-
prises.
18
Within the domain of manufacturing equipment,
multiagent systems have been proposed on several techni-
cal granularities.
19
Some are focused on the production line
or system level, where each agent thus becomes individual
stations or machines. Other focus on the machine level with
individual devices as agents. The latter being related to the
structure of a collaborative robot.
In the EU FP6 project “EUPASS,”
20
a multiagent system
architecture was developed defining both hardware and con-
trol interfaces of assembly systems. The architecture covers
automation equipment used for precision assembly in electro-
nics manufacturing; thus, this includes robots and robot mod-
ules.
21
Extending the results of EUPASS, the EU FP7 project
“IDEAS”
22
developed an integrated agent control board used
as a proxy to adapt legacy components into agents.
23
The
proposed framework and agent controller are tested
through a series of industrial experiments which demon-
strates the viability of the agent-based approach for s hop
floor reconfiguration of manufacturing systems in real-
world set tings.
23
In the EU FP7 project “PRIME,”
24
amul-
tiagent system archite cture was pr oposed which incl udes
both standardized hardware and control interfaces as a
means to developing highly adaptable and reconfigurable
plug and produce systems. In PRIME, explicit focus was
given to adapting legacy components into agents.
25
Despite their high relevance to this work, EUPASS,
IDEAS, and PRIME all focus on multiagent systems on a
manufacturing system le vel. All three projects include
robotics in their architectur e, but they do not present a
detailed approach and decomposition for collaborative
robots.
In the study by Andersen et al.,
26
a control framework
specifically for a collaborative robot is presented. The
framework enables reuse of both hardware and control
modules and furthermore enables online exchange of hard-
ware components. The article describes the overall concept
and architecture, but only very few implementation details
2 International Journal of Advanced Robotic Systems
are provided. Furthermore, the task control architecture of
the study by Andersen et al.
26
uses a taxonomy with a less
clear separation between higher level task control modules
and low-level device functionalities.
In this article, we describe the design, implementation,
and test of a plug and produce framework for industrial,
collaborative robots. Several plug and produce and agent-
based frameworks for rob otics have been proposed in
literature; however, only few of them present implemen-
tation details. G iven that the usage and acceptance of ROS
is widespread within the collaborative robotics commu-
nity, we see the need for a compati ble plug and produce
framework. The proposed f rame wor k provides necessary
adaptation for any ROS package to be used in the frame-
work. It is impor tant to note that ROS provides the imple-
mentation infrastructure, and it does not in itself provide a
plug and produce solution. As part of the plug and produce
framework, a function generalization is introduced to
clearly separate t he task co ntrol system from the device-
level control framework. The focus of this article is the
system-level design of the framework. As a result, we
built the framework on well-established communication
and architec tur al sch emes.
Hardware management framework
The motivation of the hardware manageme nt framework
is to introduce an agent-based management and control
scheme for a modular hardware architecture based on
ROS. The framework must be separated from the task
control system and thus be independent from the t ask
control’s internal architecture. The goal of which is to
make the task control system independent o f specific
hardware configura tions. Thus , the task control becomes
solely focused on the task related goals, while the device
control system f ocu ses on ach ie ving the actions requested.
The framework manages the connected modules and
introduces a standardized control interface between the
hardware modules and the task control system. Th e latter
is done using a set of gener al functions called primitives
serving as a common function interfac e betw een the task
control and the hardware devices.
The hardware management framework takes it offset in
an agent-based architecture. It builds on the architecture
outline introduced by Schou and Madsen,
5
which in this
work has been developed into further details. The resulting
architecture used in the hardware management framework
is presented in Figure 1.
Each physical device (e.g. gripper, camera, robot arm,
etc.) is represented by an associated device driver acting as
an agent and providing interaction with the given device.
The device manager manages the connected devices and
their respective device drivers. It keeps track of the avail-
able functionality and provides hardware independent and
abstract functions to the task control layer. For clarity, the
specific functions provided by the devices are referred to as
device functions and the generalized hardware functions
are referred to as primitives.
To facilitate the communication between the different
software nodes, ROS is used. First and foremost, the com-
munity behind ROS offers open source sharing of software,
for example, device drivers. The possibility to download
ROS device drivers provides a great advantage in terms of
development resources; especially on a collaboraitve robot
composed of commercial-of-the-shelf components.
The following sections will elaborate on each node in
the architecture as shown in Figure 1.
Device driver
The device drivers constitute the agents of the system.
Each active h ard ware module has a corres pon di ng soft-
ware driver, which in Figure 1 is referred to as the device
driver. On one side, the device driver provides the low-
level commu nica tio n a nd c ont rol toward the devic e. Such
communication is highly device specific and dependent
on the physical connection to the device . On the other
side, t he device drive r implements a R OS interface toward
the device manager, through which the driver provides a
set of functions. Given that drivers might be downloaded
from t he ROS community, the implemen tatio n of the ROS
interfaces of the drivers will be diverse, that is, with
diverse syntax, structure, and communication structure.
Figure 2 illustrates t he communication type and data flow
between the nodes.
Device proxy
With the presented framework, the task control operates on
abstract and generalized functionalities, , that is, primitives.
However, at some point through the control pipeline (see
Device manager
Physical
device
Physical
device
Physical
device
Physical
device
Device
proxy
Tas k c on tro l
Device
control
layer
Device
proxy
Task
control
layer
Device
KB
Device
proxy
Device
proxy
Device
driver
Device
driver
Device
driver
Device
driver
Figure 1. Architecture of the agent-based hardware management
framework. The device manager with a set of device proxies is
introduced as an intermediate control agent between the task
control and the device drivers. It provides both agent manage-
ment and a standardization of the control interface of the device
drivers.
Schou and Madsen 3
Figure 2), the primitive must be “translated” into the syntax
and structure of a specific device function on a specific
device. The device proxy is introduced to perform this
translation, and consequently the main purpose of the
device proxy is to provide a map ping from primitive to
device-specific syntax. The device proxies are created as
dynamically linked libraries, which are loaded during run-
time by the device manager.
Device manager
The device manager is the central node in the hardware
management framework. It connects the above task-level
control system to the various device drivers. The two main
tasks of the device manager are to (1) register and manage
connected agents and (2) designate incoming primitive
requests to a specific device and pass the primitive to the
associated proxy. To keep track of the connected devices,
the device drivers (agents) are registered on the device
manager upon their launch. This will be explained in fur-
ther details in “Device registration” section. An incoming
primitive request from the t ask control syst em must be
matched against the set of available primitives. The device
manager searches for a matching available primitive and
passes the request to the related proxy. This will be elabo-
rated in “Function generalization” section. The device
manager also provides a graphical user interface (GUI) (see
Figure 3). Through the interface, a list of all connected and
running device drivers can be monitored. The library of all
known devices is available in t he GUI, from which the
device drivers can be manually started.
Task control
The device manager, device drivers, and device proxies
together constitute the nodes of hardware management
framework. Above is the task control layer,whichis
responsible for the higher level robot control and, hereby,
the accomplishment of task-related goals. As we will not
discuss the structure of the task control layer in this paper, it
is only represented by a single node (task control)in
Figure 1. However, as long as it complies with the interface
described in “Function generalization” section, the struc-
ture of the task control is irrelevant. In other words, any
task control system would apply as long as it interacts with
the device manager in terms of primitives. In conjunction
with this work, we have used a task control system devel-
oped for intuitive, manual task-level programming. The
system is build on the concept of skills, which serve as
task-related control modules that can be concatenated and
parameterized to form a sequence of operations leading to
the accomplishment of a task. Details on this work can be
found in Schou and Madsen, 2016; Pedersen et al.,
2016.
5,29
Device knowledge base
In order to both successfully register a device and subse-
quently utilize the functions provided by the device, the
device manager needs information about the device in
question. This information is stored in the Device Knowl-
edge Base (see Figure 1). The device knowledge base is an
ontology containing semantic descriptions of both the robot
equipment domain and of specific device variants. The
semantic knowledge base is formatted using the Ontology
Web Language 2.
27
By using an ontology-based knowledge
base, the device information could potentially come from
external sources or be shared via the “Semantic Web”
28
between robots. In order for the device manager to recog-
nize, register, and utilize a device, sufficient semantic
information about t he device must be available in the
device knowledge base. At the very least, the following
information must be available:
Device
manager
Physical
device
Device
proxy
Ta sk
control
Device
driver
Primitives
Device functions
ROS interface
ROS interface
Figure 2. Subset of Figure 1 illustrating the interface types and
data flow. The italic text denotes interface type. The text to the
right of the connection denotes the data passed.
Figure 3. Screenshot of the GUI of the device manager. The
image shows the library tab, where all known devices are listed.
GUI: graphical user interface.
4 International Journal of Advanced Robotic Systems