online reconfiguration of distributed robot control systems ......a further experiment demonstrates...

https://doi.org/10.1007/s10846-020-01234-9

Online Reconfiguration of Distributed Robot Control Systemsfor Modular Robot Behavior Implementation

Malte Wirkus1 · Sascha Arnold1 · Elmar Berghofer1

Received: 20 December 2019 / Accepted: 7 July 2020© The Author(s) 2020

AbstractThe use of autonomous robots in areas that require executing a broad range of different tasks is currently hampered bythe high complexity of the software that adapts the robot controller to different situations the robot would face. Currentrobot software frameworks facilitate implementing controllers for individual tasks with some variability, however, theirpossibilities for adapting the controllers at runtime are very limited and don’t scale with the requirements of a highlyversatile autonomous robot. With the software presented in this paper, the behavior of robots is implemented modularly bycomposing individual controllers, between which it is possible to switch freely at runtime, since the required transitions arecalculated automatically. Thereby the software developer is relieved of the task to manually implement and maintain thetransitions between different operational modes of the robot, what largely reduces software complexity for larger amounts ofdifferent robot behaviors. The software is realized by a model-based development approach. We will present the metamodelsenabling the modeling of the controllers as well as the runtime architecture for the management of the controllers ondistributed computation hardware. Furthermore, this paper introduces an algorithm that calculates the transitions betweentwo controllers. A series of technical experiments verifies the choice of the underlying middleware and the performanceof online controller reconfiguration. A further experiment demonstrates the applicability of the approach to real roboticsapplications.

Keywords Robot programming · Robot control architectures · Robot autonomy · Model-based development ·Model-driven engineering · Robot control

1 Introduction

Autonomous robotic systems, that are versatile in theirapplication areas, will at some point face the problem that achange in control policy is needed in order to account for anew situation or task. There can be numerous reasons for arequired adaption of the controller. For example; a sensor-equipped robot might need to switch its data processingpipeline to make use of different sensing hardware to copewith changes in the environment. The robot also might beconfronted with a task requiring interacting with specificobjects, which can only be recognized with a certain sensor-processing algorithm. A further example would be that fora legged system, a change in the ground properties might

� Malte [email protected]

1 Deutsches Forschungszentrum fur Kunstliche Intelligenz(DFKI), Robert-Hooke-Str. 1, 28359 Bremen, Germany

require exchanging the gait control subsystem. With anincreasing number of possible controller configurations fora robot, also the software complexity of the coordinationlayer increases when the possible controller transitions haveto be implemented manually. For a software developer it canbe difficult to grasp all possible permutations of controllerreconfiguration for robots that are truly versatile in theircapabilities.

A usual approach to handle complexity in computerscience is to modularize, i.e. to divide the software intosmaller, manageable parts that are independent from eachother. The robotics community largely adopted the idea tomodularize software with the advent of component-basedsoftware development frameworks like the well-knownRobot Operating System (ROS) [1], the Robot ConstructionKit (Rock) [2], or Yet Another Robot Platform (YARP) [3].

The frameworks aim to achieve two main goals: Onone hand, they simplify developing software componentsby providing tools or automatizing certain parts of theimplementation, such as inter-process communication or

/ Published online: 18 September 2020

Journal of Intelligent & Robotic Systems (2020) 100:1283–1308

http://crossmark.crossref.org/dialog/?doi=10.1007/s10846-020-01234-9&domain=pdf

http://orcid.org/0000-0003-3780-1031

mailto: [email protected]

data visualization. The frameworks provide a commonstructure and interfaces for software components, andthereby unburden the software developers with manydesign decisions, while enforcing a common softwarestructure ensures technical compatibility between differentcomponents. The second main goal of the developmentframeworks is achieved by using a software-packagemanagement system that allows simple retrieval andinstallation of required components: The frameworksprovide access to a large selection of working softwarecomponents that can be used in different applicationsand robotic systems. The robot controller is eventuallycreated by interconnecting the interfaces of the individualcomponents and adapting component properties to the givenhardware or environment.

The component-based software development frameworkscontributed largely to the ability of research groups toprototype individual technology demonstrations - we see therobotics community growing and increasingly producingoutput of robots solving a multitude of individual tasks.For example, the Video Friday1 blog-articles from theIEEE Spectrum Automation blog, nowadays often linksto more than a dozen new videos weekly of differentrobots mastering different individual task. The amount ofindividual technology demonstrations is astonishing, butdemonstrations of robots that can autonomously cope witha broad range of different situations are rarely shown. Webelieve that this evolution of the robotics community isinfluenced by the current robotics software developmentframeworks, which are good tools for implementing staticrobot controllers for individual technology demonstrations,but provide little support for developing flexible controlsolutions as needed by highly versatile robots. In ROS,for example, the robot application often consists of astatic component network, usually described by a XML-file(launch file), which specifies the different components thatare to be started and also assigns configuration values tothe components [4]. Different behaviors are then triggeredby altering some of the component properties at runtimeor by injecting data into the control network. The singlestatic control network must therefore take into account allthe different behaviors of the robot, which is contrary tothe idea of modularity. Of course, further launch file canrepresent additional component networks, but an onlinetransition between these control networks is not possible,so the complete robot controller must be switched off ifanother network is needed.

As an improvement over the current state, we proposethat the individual robot behaviors should be modeledindependently of each other. During the development of

1Video Friday in IEEE Spectrum Automation blog: https://spectrum.ieee.org/tag/videofriday (last checked September, 2019)

the individual controllers, no assumptions should have tobe made about which sequences of controllers are allowedand which are not, or what the robot’s range of functionswill ultimately be. Furthermore, no rigid architecture shouldprescribe certain approaches such as plan-based or reactivecontrol, which would then have to be used to implement allthe different behaviors.

We therefore present a software for modular modelingof robotic controllers, as well as their execution andonline switching. To allow calling the individual controllersany time and in any order, the calculation of thenecessary operations for transitioning between them isaccomplished automatically at runtime. To account for thehigh computational effort, especially of complex sensorprocessing routines, the controllers can be executed ondistributed hardware.

This is an extension of the known component develop-ment frameworks. The pool of available software compo-nents provided by the frameworks is used to model thecontrollers, but a runtime management layer is added forcoordinating their execution. The proposed workflow andsoftware simplify the development of the robot software tosuch an extent that a robot system can cover any numberof different tasks without the need for additional develop-ment effort to implement transitions between tasks or toconsider any dependencies between them. Although ROSprovides many more available software components, webase our implementation on Rock for the reasons explainedin Section 2.

After giving an overview about the related workand the model-driven software development methodology,we present the metamodels for controllers, individualsoftware components and controller transitions in Section 2.The software architecture that allows to coordinate thedistributed control networks at runtime and an algorithmthat computes the transition between two controllersis explained afterwards in Section 3. To validate theproposed approach, a series of experiments was conducted,which are presented and discussed in Section 4. The lastsection concludes the work and discusses possible futurework.

1.1 RelatedWork

The design of modern robotic software developmentframeworks was already envisioned back in the mid-nineties by Steward and Khosla [5]. As others (e.g. [6])before they proposed to use software components thatprovide communication ports to let individual softwareparts exchange data. The crucial difference to previouswork is that Steward and Khosla highlighted the possibilityfor component re-use, when general software componentsprovide well-defined interfaces. In [5] they outlined how

1284 J Intell Robot Syst (2020) 100:1283–1308

https://spectrum.ieee.org/tag/videofriday

https://spectrum.ieee.org/tag/videofriday

research groups could share software components withstandardized interfaces using the internet, and assemblerobot controllers from these components without the needof programming them manually. Nowadays, this idea hasbecome a reality with the modern robot developmentframeworks mentioned in the previous section. Thishas significantly changed the general technical situationcompared to the mid-1990s. Nevertheless, another centralpoint is missing in today’s robotics frameworks, whichhas already been described in [5], so we will transferit in our work to the today’s situation: In [5], theneed for reconfiguring robot controllers to adapt todifferent situations was anticipated. The authors identifiedthat for this purpose at a higher-level of control, fullcontrol over the software component’s runtime stateand interface-connections is required, e.g. to replacecomponents and redirect the data flow accordingly. WhileROS [1] components lack this level of control, componentsfor the Orocos Real-Time Toolkit (RTT) [7, 8] or theRock framework [2] (which is based on RTT), allow forexternal coordination. The work presented in this paperis based on the possibility of coordinating componentsfrom outside. Therefore we use Rock as a basis for ourimplementation. In addition, Rock components providean offline readable component interface specification, themodel of the component. This means that without runningit, the data connection interfaces (and other interfaces) ofa component are readable for humans and software. Thismakes it easier to model controllers, since the interfaces canbe presented to the developer as a reference e.g. with thehelp of graphical or text-based tools. However, these toolsare out of scope of this paper.

A model-driven software engineering (MDE), or model-driven development (MDD) process [9] is based on abstractrepresentations (models) of certain aspects of a given systemor problem domain. As shown in Fig. 1, the models canbe result of, or input to numerous different computationalor manual processes. These processes generate, interpretor modify models, or transform them to a differentrepresentation that focuses a different concern of thesystem. Compatibility between individual processes is

Fig. 1 Example model-driven development process

ensured by the use of metamodels that specify all relevantproperties of the system and thus define the language forcreating valid models. By focusing on the representationof the problem domain, MDD highlights a representationof knowledge about a domain rather than the algorithmicsolution to a problem.

In the robotics community, e.g. the BRICS - Best prac-tice in robotics [10] and RobMoSys2 research initiativespromote the rigorous use of model-driven software develop-ment to cope with the complexity for system integration andthe generation of individual algorithmic solutions.

In this spirit, with [11] and [12], software ecosystemswere introduced, that provide a model-based workflowfor developing robotic control software. Both works allowto a certain extent the online adaptation of the modeledcontrollers. In [12] however, this is limited to the variationof configuration values for software components withoutallowing a complete change of the controller topology. Bothsystems also have in common that they are designed tosolve several different problems, such as real-time controlsystem, high-level coordination and controller design atonce. Thereby [12] offers clearer defined metamodels andinterfaces between the individual modules, whereas [11]impedes the extensibility or integration of external toolsby relying on a Ruby-embedded model representation andhaving a very tight integration between the individualsoftware parts for model representation, control andmodeling. This compromises one of MDD’s potentialstrengths that, through the use of well-defined modelsrepresentations, independent development tools can worktogether regardless of their technical realization.

A growing fraction of the robotics research communityseems to recognize the advantages of MDD: Nordmanet al. identified in a survey on domain specific modelingfor robotics [13] an increasing number of publicationsregarding model-driven development for robotics in recentyears. Of the publications included in the survey, themajority are in the field of modeling individual robotcapabilities. With our work we provide a representation thatcould be used for such modeling tools for individual robotcapabilities as the resulting common runtime representation.

Another earlier example for reconfigurable controllersis [14]. To better account for post-implementation changesof machine controllers, the authors propose to modelthe controllers using pre-installed software componentsthat are loaded at system startup and interconnectedaccording to the model. Their approach supports onlyoffline reconfiguration, i.e. the controller needs to be shutdown completely in order to load a new configuration.Nevertheless, they argue that modeling the controllersreduces development efforts when compared to traditional

2RobMoSys-website: https://robmosys.eu/

1285J Intell Robot Syst (2020) 100:1283–1308

https://robmosys.eu/

programming. Adaption of a robot controller at runtimeis supported by the work presented in [15] and [16].The focus in this work is the specification of constraintsthat define when a controller adaption has to take placerather than the representation of effect of the adaption. Thereaction is thus limited to an adjustment of properties ofthe presently running components. Both examples have incommon, that a single language specifies the conditionsunder which a change in behavior occurs, and also howthe controller is reconfigured. In [17] Klotzbucher et. alargue that these two mechanisms: (a) Detection of theneed of adaption and selecting the appropriate reaction(Coordination) and (b) applying the change on a particularsystem (Configuration), should be treated separately. Theyprovide a language that allows specifying transitions ofruntime states of components to enable the reconfigurationof the robot controller. However, no changes in the topologyof the component network are possible, so that ultimatelyall controllers for all different robot behaviors must fit intoa single rigid architecture.

We agree with the argumentation in [17] to provideseparated models for coordination and configuration.Both processes represent system dynamics at differentabstractions. Coordination is concerned with the high-leveldynamics of a task. Its modeling primitives are semanticentities that are valid for a certain application domain, suchas specific object or world conditions. The conditions aremapped to events and discrete representations of actionsthat manipulate the world state. These events and actionscan be valid for different robots when they are acting in thesame environment, even though the different robots mightbe very different in their technical implementation. Thus,implementation details should be kept at a minimum whendescribing high-level dynamics of a task. Configuration onthe other hand, describes how to implement a certain actionand thus is inherently technical. Its modeling primitives are

implementation details, e.g. software components and theirinterconnection or operations that are applied to them.

Following this terminology, this paper addresses theConfiguration: In the next section, we introduce modelsfor expressing dynamically changing control systems. Thedynamics include adjusting component properties, runtimestates, as well as changes of the overall controller topology.Afterwards, in Section 3, we propose a software architectureand implementation to carry out the modeled controllertransitions on distributed hardware.

2Modeling Online-ReconfigurableDistributed Software Systems

In MDD, metamodels define the modeling domain byspecifying certain entities that exist in the domain andtheir relevant properties and relationships. This sectionintroduces the metamodels that we use to model controllersand modify them.

A controller is described by a network consisting ofinterconnected pre-implemented software components. Thecomponents are computation units (named Tasks), thatprovide data ports for communicating with other Tasks.Task Networks can be manipulated by a discrete set ofoperations acting on the network’s Tasks. A sequence ofthese operations specifies a procedural transition betweentwo Task Networks. A declarative controller reconfigurationis realized by deriving the transition from the currentlypresent controller to a given target configuration, whereboth controller configurations are represented as TaskNetworks. The following sub-section will introduce themeta-models for valid Tasks, Task Networks and Transitionsin detail. Afterwards, Section 3 introduces an algorithmfor the automatic derivation of a Transition, between twoarbitrary Task Networks.

Table 1 Legend for UML class diagrams that describe the metamodels

Classes

Meta-model Yellow classes denote the metamodel of the system represented by the figure.Attribute Meta-models comprise of different attributes. These attributes are denoted as white classes.

Assoc. meta-model An attribute can be associated to a model conforming to a different metamodel. The referredmetamodel is visualized with a gray class.

Assoc./Attribute When an attribute is associated with an attribute of a different metamodel, this is representedby using the name pattern: “metamodel name/attribute”.

Aggregations/Associations

conformsTo The attribute is a model that conform the associated metamodel.

refersTo The attribute contains a reference to another model by storing a unique identifier of thereferred model.

instanceOf The attribute is an instance of the model that conforms to the associated metamodel.

For aggregations and associations where no multiplicity is given, the multiplicity 1 is assigned.


Task

Input Port Output Port Property Default Activity Nominal State Error State

Port

name : String

Data Type

Default Value Activity State

name : String

0..*0..* 0..* 1..*

refersTo

conformsTo

Operation

name : String

Return Value Argument

1..*

6..*

0..1 0..*

conformsTo

refersTo

refersTorefersTo

Fig. 2 Meta-model of a Task

We use UML class diagrams to represent the metamodelsin this paper. Table 1 summarizes the semantics ofthe different class- and association-types we use forrepresenting the metamodels.

2.1 Component-Based Controller Modeling

Tasks represent the atomic processing units of a TaskNetwork. They are re-usable software components such ashardware drivers, control- or data processing algorithms,etc.. The Task-model captures information about theexternal interfaces of the software component, serving twopurposes:

1. Provide technical interfaces to allow external softwareto control the software components.

2. Provide the knowledge about the presence of theinterfaces without the need to execute the component,i.e., to present the interfaces to the user or softwaretools.

To represent software components and data types, thatcan be used on the component’s external interface, themodels that are used in the Rock framework3 are adopted.For completeness, the metamodel for Rock Tasks, DataTypes and Deployments are briefly described here. Forfurther details on the Rock framework and the underlyingtechnology for developing real-time software components,Orocos-RTT4, the interested reader is invited to read [2] and[7].

As shown in the graphical representation of themetamodel Tasks in Fig. 2, Tasks consist of the followingparts:

– Port: To interact with other software components, aTask can read incoming data from its Input Ports andwrite data to its Output Ports. Each port is associatedwith a Data Type (cf. Fig. 3) specifying the only validtype that can be exchanged over the port.

3Rock-Website: https://www.rock-robotics.org/4Orocos-RTT Website: http://www.orocos.org/rtt/

– Operation: Tasks can provide Operations, i.e. proce-dures, which can be called from remote processes andsystems. With a name, a return value and arguments, themodel an Operation provides similar information as anormal function header. At runtime, calling of an opera-tion leads to the synchronous execution of an associatedfunction with the same header.

– Property: Tasks can optionally define a set of typedconfiguration parameters. Each property is identified bya name that is unique within the component, a data typeand a default value.

– Nominal State/Error State: Each Tasks executionis controlled with a state machine implementing acommon life cycle. Each component contains certainpre-defined states and permissible state transitionsthat can be used to start or stop data processing,apply configuration values, and execute standardizedfault recovery methods. The state transitions betweenthe predefined states are triggered by calling specificoperations.

More details on the life cycle will be given inSection 3.2 and Table 4.

– Activity: Runtime characteristics (Activity, cf. Figure 5)of a Task such as it’s triggering mechanism (e.g.on retrieval of new data or periodic triggering) arerelevant for the deployment of a Task. Nevertheless itis foreseen, that the component developer already pre-initializes them with a sane default value, such that aworking default deployment can be generated.

Properties and ports of a Task are associated witha Data Type. For modeling the data type, we use thetypelib5 metamodel that Orocos-RTT [8] and Rock [2]use. The model of a data type is used for frameworkfeatures such as data serialization and de-serialization,conversion to CORBA IDL format or translating valuesfrom configuration files to the runtime data types andvice versa. For (de-) serialization, typelib assumes a rigidmapping of the individual type models to runtime types

5Typelib Source Code and Documentation: https://github.com/orocos-toolchain/typelib


https://www.rock-robotics.org/

http://www.orocos.org/rtt/

https://github.com/orocos-toolchain/typelib

https://github.com/orocos-toolchain/typelib

Fig. 3 Meta-model of a DataType

Data Type

size : Integer

Numeric

Numeric Type

SInt

Compound

Field

offset : Integer

refersTo

Container

size : Integer

refersTo Enum

Value

symbol : Stringvalue : Integer

UIntFloat

0..*0..*

0..*

Task Network

DeploymentConnection

Sink Source Policy

Port Reference Data Buffer

buffer_size : Integer

Task Instance Task/Port

refersTorefersTo

Circular Buffer

buffer_size : Integer

Task Instance

Property Assignment0..*

Prototype Activity Instance Runtime State

TaskTask/PropertyValue

Task/Data Type

Activity Task/State

refersTorefersTo conformsTorefersTo

instanceOf

Fig. 4 Meta-model of a Task Network

Activity

Triggering Mechanism

Port DrivenFile Descriptor Driven

file_descriptor : String

Periodic

periodicity : IntegernewAttr : Integer

Port Reference

Task/Input Port

refersTo

Deployment

process_name : Stringhost : String

Deployed Task1..*

Task Instance

refersTo

Scheduling Policy

priority : Integer

Non-Real Time Real Time

Host

refersTo

Host

ip : String

Process Server

Fig. 5 Meta-models for deployment information


in the target language (e.g. C++). The Data Type modeldescribes four different categories of types:

– Numeric: This represents the primitive types. Threesub-categories of numeric types are discriminated:floating-point numbers, signed integers and unsignedintegers.

– Container: Represent array-like structures. A containeralways refers to a Data Type indicating the type forevery element stored inside the container.

– Enum: Relates the numeric value of a enumeration type(as in C/C++) with its symbolic representation.

– Compound: Represents complex data structures withdifferent members (Fields) of different Data Types.

To model a controller for a robot, a Task Networkis composed. To achieve this, instances of Tasks arecreated, configured, interconnected and deployed to targethardware. As illustrated in Fig. 4, for each instantiatedTask (Task Instance) in the Task Network, the propertiesare explicitly configured with Property Assignments. Thestate in the life cycle of the Task is specified with theRuntime State attribute and certain runtime characteristicsare assigned with the Activity Instance (cf. Figure 5). ThePrototype specifies which model the instantiated componentconforms to. Note that several instances of the sameTask can exist, which is used, for example, when thesame driver component is instantiated several times forredundant hardware devices. The individual instances aredistinguished from each other by a unique name.

The connections between the ports of the individualTask Instances form the topology of the Task Network.In addition to the data source and sink, a Connectionalso describes the connection policy, which can be eitherunbuffered (Data), buffered or via a ring buffer.

The implementations of individual Tasks are compiledinto libraries. With the Deployment, any number of Task

Instances are combined to form executable programs thatlink against the respective libraries containing the Taskimplementations. The Deployments are assigned to aspecific execution hardware (Host) and an RTT-scheduler(real-time or non-real-time) with a specific schedulingpriority. Each Host is associated with a Process Server,a program in charge of handling the processes on theparticular execution hardware.

When two Task Instances of the same Deploymentcommunicate with each other (intra-process communica-tion), a more performant data transfer method can be usedcompared to communication between two different pro-cesses (inter-process) or between two different computers(remote). The Rock Framework automatically ensures thatthe most suitable communication method is used.

Implementation details on the Process Server and theoverall runtime architecture are given in the Section 3.

2.2 TransitionModelling

To dynamically reconfigure the robot controller, thestructure of the running Task Network is altered. Since allcomponents conform the Task metamodel, a set of actions,that is common for all components, can be defined, todescribe a complex restructuring of a component networkwhen the actions are chained sequentially.

Figure 6 illustrates the metamodel for Transitions, whichcan contain any sequences of the following Actions:

– Deploy/Undeploy: The Deploy action represents theinstruction to execute a specific Deployment, whichcorresponds to starting a new process. The Undeployaction, on the other hand, is the instruction to end theprocess of the referenced Deployment.

– Call Operation: Represents a call to an Operation ofa Task Instance. A value must be assigned for eachargument specified for the referred Operation.

Transition

Action0..*

Call Operation

Connect PortsDeploy

Disconnect PortsTask State Transition

UndeployTask Instance

Task/Operation

ConnectionDeployment

Start

Stop

Configure

Recover

Cleanup

Tast/State

Apply Config

Property Assignment

refersTo

refersTo

refersTo refersTo

instanceOf refersTo

refersTo refersToinstanceOf

refersTo

Value Data TypeinstanceOf0..*

Fig. 6 Meta-model of a Transition


– Task State Transition: The different Task State Transi-tions refer the initiation of a runtime state transition ofa Task Instance.

– Connect/Disconnect Ports: Refers to the action ofestablishing or removing a connection between twoports.

For the different metamodels presented in this section,we implemented runtime-representations in C++, Pythonand/or Ruby and defined text-based serializations in YAMLor XML. The serialization formats are used for persistentstorage and data exchange between the tools described inthe next section. Examples for YAML representations for aTask Network and a Transition are given in Appendix A.

3 Implementation

In model-based development, metamodels, like the onesfrom the previous section, allow to model certain aspectsof a specific problem, but not necessarily restrict theprocessing that is conducted on them. In contrary, asindicated by Fig. 1, there can exist independent tools thatfocus on different aspects of the modeled system andprocess the models in various ways. This section nowintroduces a software that is responsible for the executionand runtime management of the modeled controllersas well as for the automatic calculation of transitionsbetween them. Thereby, the software makes use of allmetamodels from the previous section with ComponentNetwork and Transition being the central representationsin the implementation. Table 2 and later Table 3 formallydescribe some operations on the model representations thatare used in the implementation of the software rock-runtime.

The following sub-section gives an overview about theoverall system architecture, followed by a detailed descrip-tion of the Network Operation Solver (NetOpSolver), analgorithm that generates a sequence of actions that reconfig-ure a controller network, in the subsequent subsection.

3.1 Distributed Runtime Architecture

The task of rock-runtime is to manipulate system processes,TaskContexts and data connections in such a way that therunning control system is reconfigured in correspondencewith Task Networks which can be requested at anytime, e.g. by a high-level mission coordination or planexecution software. Figure 7 illustrates the architectureof rock-runtime comprising of the following softwareparts:

– Network Operation Solver (NetOpSolver): an algorithmto determine the Transition φmin consisting of theminimum set of operations that reconfigure thecurrently running controller Cact to match the desiredcontroller Cset (both represented as Task Networks).

– RTTTaskManager: A software module handling allinteractions with RTT components, represented by theTask Instance model. This module’s task is to realize aparticular action a ∈ φmin on the respective component.

– ProcessServer: Manages the processes on a specificruntime platform. On each computer involved in aTask Network, a ProcessServer runs which takes careof starting and stopping processes on this computerwhen the RTTTaskManager requests this by calling thecorresponding operations.

– TaskNetworkHandler: The central software part, pro-viding the interface to higher-level software. TheTaskNetworkHandler coordinates the system-wide run-time state by invoking the other mentioned softwareparts. Requests of the a new Cset or requests for apply-ing certain Transitions can be issued to the TaskNet-workHandler.

The ProcessServer and TaskNetworkHandler are imple-mented as individual Rock components (cf. Figure 7). TheRTTTaskManager and NetOpSolver are provided as C++classes in libraries that are linked to the TaskNetworkHan-dler component.

Table 2 Definition of operations on Task Network and Transition models

Definition 1 Each model conforming to any of the metamodels can uniquely be identified by an id.

Definition 2 Two Task Instances x and x∗ are equal (x = x∗), if all their attributes are equal. They are similar (c ≈ c∗), if at least their idand Prototype are equal. For two Connections e, e∗, two Deployments d, d∗, and Task Networks C, C∗ the equality operator = isdefined analogically.

Definition 3 The operator ⊕ applies a Transition φ to a Task Network. The operation C ⊕φ �→ C∗ predicts the effect of a transition. The resultis a Task Network C∗, where C∗ �= C, if φ is not empty (φ �= ∅) and minimal.

Definition 4 The operator |φ| can be applied to a Transition φ and returns the number of Actions within the Transition. A Transition φmin isminimal, if there exists no other transition φ with |φ| < |φmin| that has the same effect, when applied to the same Task Network C.


Table 3 Definition of set-operations on Task Networks

Definition 5 A Task Network can be seen as a set composed by its Task Instances x, Connections e and Deployments d.

Definition 6 The existence ∈ of a Connection e or a Deployment d in a Task Network C is given, if C contains a Connection eA = e orDeployment dA = d. The existence of a Task Instance x in a Task Network CA (x ∈ C) is given, if C includes a Task InstancexA ≈ x.

Definition 7 The set difference of two Task Networks CA and CB (or complement of CA with respect to CB) is defined by CA�CB ={x|(x ∈ CA) ∧ (x /∈ CB)}.

Definition 8 The intersection of two Task Networks CA and CB are those components xa ∈ CA and xb ∈ CB, that are similar (xa ≈ xb)and present in both Task Networks.

Each computer system involved in the distributed controlsystem runs a ProcessServer that takes care of execut-ing or terminating the processes specified by the Deployand Undeploy actions. The Task Manager and the ProcessServers on the individual runtime systems communicatewith each other using RTT operation calls. All additionalActions (such as Start, Apply Config, Connect Ports, etc.)are implemented in the by RTTTaskManager directly byusing the standardized Rock interfaces of the componentsreferred by the actions. For interacting with external soft-ware, like a plan execution program, the TaskNetworkHan-dler provides input ports and RTT-operations, on whichTaskNetworkHandler listens for Task Network and Tran-sition requests. When a certain controller configurationis requested, the TaskNetworkHandler calls the NetOp-Solver in order to generate the required Transition. TheTaskNetworkHandler keeps tracks of all TaskNetwork- andTransition-requests and maintains a Task Network Cbelief

that represents the current state of the controller, whichis also passed to the NetOpSolver (Ccur = Cbelief). TheTaskNetworkHandler provides an input port that allowsresetting Cbelief by passing the actual running componentnetwork Cact.

Fig. 7 Architecture of the rock-runtime software

3.2 Network Operation Solver

By using Definition 1 – 4, Eq. 1 describes the NetworkOperation Solver (NetOpSolver) as a function that finds theminimal set of Actions that will establish a desired targetconfiguration Cset when they are executed.

solve(Ccur, Cset) �→ φ,

where Ccur ⊕ φ = Cset, and |φ| is minimized. (1)

We implemented the NetOpSolver as a special purposealgorithm that is shown in detail in Algorithm 1. Thealgorithm identifies the differences between Cdes and Ccur,and for each mismatching item selects a predefined partialTransition, that eliminates the mismatch. The followingparagraphs give details of the NetOpSolver, that makesuse of set-operation on Task Networks that are defined inTable 3.

Line 2-4 of Algorithm 1 identify topological differencesbetween Ccur and Cset:

– C− contains the Task Instances, Connections andDeployments of Ccur , that need to be removed, becausethey are no longer exist in Cdes .

– C+ contains the sub-network of Cdes , that newly needsto be created, because it was not present in Ccur .

– C∩ contains the sub-network that is present in Ccur

and Cdes , but where the components are not equalbut similar. Here a state change in the individualcomponents life-cycle or a reassignment of properties isrequired (cf. line 17-26).

Fig. 8 Valid state transitions of the common life cycle for TaskInstances


Algorithm 1 Network Operation Solver (NetOpSolver).

Input: Initial network Ccur and the target component networkCset

Output: Minimal Transition φ where Ccur ⊕ φ = Cset

Initialize empty Transitions :1: φ ← ∅

Determine required topological changes by creating comple-ments and the intersection of Ccur and Cset

2: C+ ← Cset�Ccur

3: C− ← Ccur�Cset

4: C∩ ← Ccur ∩ Cset

Generate shutdown sequences for components in C−5: for each TaskInstance x ∈ C− do6: φ genStateTransition( x, stateOf(x), PRE OP)7: end for

Generate Disconnect and Undeploy actions8: for each Connection e ∈ C− and Deployment d ∈ C− do9: φ makeDisconnect(e)10: φ makeUndeploy(d)

11: end for

Generate actions to add new Deployments and Connectionsspecified in C+

12: for each Connection e ∈ C+ and Deployment d ∈ C+ do13: φ makeConnect(e)14: φ makeDeploy(d)

15: end forGenerate startup transitions for all Tasks in C+

16: for each x ∈ C+ do17: φ genStateTransition( x, PRE OP, stateOf(x))18: end for

Handle potential state or configuration changes in C∩19: for each TaskInstance x∩ ∈ C∩ do20: xcur ← find x ∈ Ccur,where x ≈ x∩21: xset ← find x ∈ Cset,where x ≈ x∩22: φ genStateTransition( x∩, stateOf(xcur), stateOf(xset))

If property assignment is required, also generate the neededlife cycle state transitions

23: if propertyAssignmentOf(xcur) �= propertyAssignmentOf(xset) then

24: φ genStateTransition( x∩, stateOf(xcur), PRE OP)25: φ makeApplyConfig(x∩, propertyAssignmentOf

(xset))26: φ genStateTransition( x∩, PRE OP, stateOf(xcur))27: end if28: end for

Sort individual actions in φ according to their applicability:(1. Recover, 2. Stop, 3. Disconnect, 4. Cleanup, 5. Undeploy,6. Deploy, 7. Apply Config, 8. Connect, 9. Start)

29: φ ← sortByApplicability(φ)30: return φ

The functions propertyAssignmentOf(TaskInstance) andstateOf(TaskInstance) return the corresponding attribute(Property or State) of the TaskInstance given as param-

eter. The functions makeApplyConfig(TaskInstance,PropertyAssignment), makeConnect(Connection), makeDe-ploy(Deployment) etc. create Actions for a Transition, thatmodify a Task Network such that the entity which is givenas argument is either created or removed.

It was already mentioned in Section 2 that every runningTask contains a state machine, implementing a uniform lifecycle for all software components. Figure 8 illustrates theallowed transitions (italics) between the individual states(bold) within this life-cycle. Based thereon, Table 4 liststhe sequences of actions required to transition betweenany given constellation of initial and target state of aTask. The ERROR state can only be triggered within thecomponent and not by calling an operation. The functiongenStateTransition(TaskInstance, State init, State target)generates the correct sequence of TaskStateTransition-actions to setup the state target on the given TaskInstancebased on this state chart.

Lines 23-27 of Algorithm 1 account for the conventionpresent in Rock, that the assignment of configurationparameters are applied to a component when it is in thePRE OP-state. Realizing a reconfiguration of a runningcomponent thus requires generating a state transitionto PRE OP before applying a Apply Config-action andafterwards a full state transition to the RUNNING-stateagain.

Line 29 of the Network Transition Solver ensuresthe correct order of actions and removes duplicate statetransitions. In general, actions that regress the lifecycle of acomponent or reduce the component network (componentsor connections are removed) are executed before actionsthat advance runtime states or extend the componentnetwork.

4 Experimental Results

The overhead caused by the framework for data exchangeand for interaction with the software components influencesthe feasibility of using the software framework for real-timecontrol tasks. To validate the choice of using Rock/Orocos-RTT, and the dynamic controller reconfiguration perfor-mance, various performance parameters of the system weremeasured in an experimental evaluation. A first experimentseries acquires data about the middleware’s performance inrelation to data sample and component network sizes. A sec-ond series investigates times for starting or reconfigurationcontrollers with changing component network sizes.

These theoretical experiments are supplemented byanother practical experiment which examines the perfor-mance under realistic conditions. In this experiment, dif-ferent controllers created with the proposed framework areexecuted on a real robot system and the reconfiguration


Table 4 Operations required to transition between runtime states

Start

TargetPRE OP STOPPED RUNNING ERROR

PRE OP – ApplyConfig, Configure ApplyConfig, Configure, Start x

STOPPED Cleanup – Start x

RUNNING Stop, Cleanup Stop – x

ERROR Recover, Stop, Cleanup Recover, Stop Recover –

times between them are determined. Thereby the applicabil-ity of the framework to real robotic problems as well as theperformance of the adaptation for real controllers is shown.

The experiments are executed on two different computersthat are connected with a commercial Gigabit Ethernetswitch from D-Link:

– System A: Mini-ITX (mITX) board with Intel Core i7-3610QE CPU@ 2.30GHz, 16GiB memory and a SATAconnected SSD from Samsung (550 MB/s seq. read,520 MB/s seq. write).

– System B: COM Express (COMe) Compact Pin-out Type 6 embedded system with Intel Core i7-7600U CPU @ 2.80GHz, 16GiB memory and a SATAconnected SSD from Samsung (550 MB/s seq. read,520 MB/s seq. write).

On both systems the operation system Ubuntu 18.04 isinstalled with no significant adaptions compared to itsstandard configuration.

For all experiments we composed different Task Net-works from the three Tasks shown in Fig. 9. The Message-Producer produces data samples χout of the type DataSam-ple (cf. Listing 1).

The size of the data sample depends on the length ofthe string stored in the payload variable. To create the datasample, MessageProducer generates a random string witha configurable length for the payload variable and stores atimestamp in microsecond resolution after constructing theDataSample object and immediately before writing it to theoutput port.

Component networks used in the experiments createa processing chain by connecting the output port ofMessageProducer to a varying number of MessageRelaycomponents that simply read samples from their input portand forward them to the output port. The last component in

a processing chain is the MessageConsumer that calculatesthe duration between the creation of the data sample in theMessageProducer and its retrieval in the MessageConsumer,by comparing the timestamp stored in χin to the currenttime. The transport duration for all received sample iswritten to a file.

The experiments also investigate the effect that differentdeployment configurations induce. We distinguish thefollowing three cases:

1. Intra-process communication: Each two directly con-nected Tasks are running in the same process.

2. Inter-process communication: Each two directly con-nected Tasks are running in different processes, but theprocesses run on the same system.

3. Remote communication: Each two directly intercon-nected Tasks are running on different systems, thus,network communication is required to exchange data.

In the following, we will use a simplified notationto describe the topology of Task Networks. We refer toMessageProducer, MessageRelay and MessageConsumercomponents with the symbols P, R and C. The computersystem (A, B) and the process, where the Task is deployedto, is indicated by a prefixed superscript. An arrow denotesa data connection between two components (since thereis no component involved with multiple input or outputports this notation is for the present case unambiguous). Forexample, A1P refers to a Message Producer that is deployedto process 1 on systemA. The processing chain A1P →B1 C

shows a case of remote communication where a data sampleis sent from a MessageProducer running on system A to aMessageConsumer running on systemB. In all experiments,the MessageProducer are triggered periodically and theother two components are triggered upon receiving a newdata sample.

Fig. 9 Software componentsused in evaluation experiments MessageProducer MessageRelay MessageConsumer


Listing 1 C++ type definitions for data samples χ

4.1 Data Transfer Times

In the first experiment (E1.1), we investigate how the size ofa data sample influences it’s transmissions times in differentdeployment cases. We measure the time for the two-waytransmission of a data samples χ between components.The experiment is repeated with changing sizes of χ anddifferent deployment cases. The following Eqs. 2–4 showthe used component networks.

A1P →A1 R →A1 C (2)A1P →A2 R →A3 C (3)A1P →B2 R →A1 C (4)

The payload size of χ varies between 10 B and 100 MBin multiple steps. Small sizes (< 1 kB) are included, asthey are usually used for real-time control task such as jointcontrol. Larger sizes that often find use in sensor processing(< 10 MB) are included as well, and with payload size of100 MB we also test a data sample size that is so large, thatit is of no practical use in most robotics control applications.

Figure 10 shows a plot with the mean data transfertimes collected over a period of 15 seconds for thedifferent versions of the experimental setup. As expected,the result of the experiment shows that the performanceof intra-process communication is better than that of inter-process communication, and that remote communicationcauses the highest overhead. The question the experimentaims to answer is whether the communication overhead issufficiently low to use the framework for robot control.

The data shows that for sample sizes up to multiple kB,the communication overhead is not the limiting factor toachieve control frequencies with 1 kHz in the intra-processcase.

For the inter-process case the communication overheadis also still less than 1 ms, but for a 1 kHz controllerthere is not much time left for the actual calculation, whichwould be needed in a real control application. In the remotecommunication case, the overhead alone prevents a controlfrequency of 1 kHz. However, control frequencies of 500

Hz or 100 Hz can be achieved even with sample sizes largerthan 100 kB respectively 1 MB in the intra-process case.

This however is a theoretical statement. In practice, it islikely that larger data sizes will require also more time forprocessing the data. For example, it usually takes longer toprocess a FullHD image than multiplying a joint positionvector. Thus for larger sample sizes it is more likely that theactual processing is actually the limiting factor to achievehigh control rates.

The second experiment (E1.2) investigates the impact ofan increasing number of data processing components onthe theoretically achievable control rate. We measure thetime for sending a data sample of a fixed size (100 B)through component networks that vary in the number ofMessageRelay components. The network topologies usedfor the experiment are given in Eqs. 5–7.

A1P →A1 R1 → . . .A1 Rn → A1C (5)A1P →A2 R1 → . . .An+1 Rn → A1C (6)

A1P →B1 R1 →A2 R2 → . . .Bk Rn → A1C (7)

Similar to the first experiment, again the dura-tion between the creation of χ in P and its arrivalin C is measured. The data collection is repeatedfor different number of Relay components (n =5, 10, 25, 50, 100, 150, 200, 250) and different deploymentcases. With n = 5 and n = 10, typical processing chainsizes are considered. Component networks composed from25 or 50 individual components still appear as realistic sizes,but a chained interconnection of such a number of com-ponents is a rare case in robotics. In the real experiment,which will be presented in more detail in the next subsec-tion, we show, for example, a controller that implementsan autonomous exploration behavior on a rover utilizing aLiDAR sensor for self-localization and mapping (SLAM) ofthe environment (cf. Section 4.3.1 and Appendix B.1). Thelongest processing chain in that controller contains 13 com-ponents consisting of the sensor and actuator drivers (3),sensor processing of the point cloud data (2), slam and posefiltering (2), setpoint generation and trajectory planning (2),trajectory and motion control (2) sample dispatching anddevice I/O (2).

Even though the larger values of n seem not of practicaluse for robotics applications, we include these values tothe experiment to investigate the potential for controllerswith more fine-granular component decomposition orsignificantly more complex systems than those that arecurrently common.

As in E1.1, the data of E1.2 (shown in Fig. 11) reflects theexpectation that the intra-process deployment case performsbetter compared to the other deployment cases. For each


Fig. 10 Data transfer times ofdata samples with increasingsizes

10.0 B 0.1 kB 1.0 kB 10.0 kB 0.1 MB 1.0 MB 10.0 MB 0.1 GB

Data sample size (Bytes)

0.1

1.0

10.0

100.0

1000.0

Twoway

transfer

time(m

s)

0.140 0.147 0.1630.216

0.432

6.444

201.557

0.524 0.641 0.7381.070

2.578

32.322

1000.598

1.000 1.0101.465

3.267

23.434

245.794

2868.672

Intra-Process

Inter-Process

Remote

deployment case, the transfer time is increasing nearly-linearly with the number of components, but with differentslopes of approx. 0.02, 0.14 and 0.22 ms

transport .The experiment shows that if processing chains are kept

short (< 10), a 1 kHz control frequency could be achievedin the intra-process case. For a control frequency of 100Hz, the communication overhead play no significant rolefor any practically relevant processing chain in the intra-process case. In a real robotics application a deploymentcase like the inter-process or especially the remote case,where each single data connection crosses process or systemboundaries, are quite unconventional. Nevertheless, theresults show that the 100 Hz target can be achieved forlonger processing chains, if the processing times inside thecomponents remain moderate.

4.2 Task Network Operation Times

The second series of experiments examines the controllerstartup and reconfiguration times. The experiment E2.1investigates how the number of interconnected componentsinfluences start-up/shutdown times of a Task Network. Weagain use networks from Eqs. 5 – 7 that were also usedfor E2.1. For the individual component networks, that varyin network sizes and deployment case, we measure theduration to setup the running component network, and tocompletely shut it down again. For a component networkwith n MessageRelay components, 1 + n data connectionshave to be established or removed respectively. For startinga component network, (n + 2) ∗ 3 Task State Transitionsand two property assignments have to be applied. To shut

Fig. 11 Data transfer times withincreasing length of theprocessing pipeline

0 50 100 150 200 250

Length of processing chain

0

10

20

30

40

50

60

Tim

eforprocessing

of100Byte(m

s)

0.39 1.68 2.38 3.58 4.24 5.44 6.255.22

10.54

18.31

23.36

29.19

36.09

2.80

10.73

18.30

25.99

36.01

46.51

57.88Intra-Process

Inter-Process

Remote


it down again, (n + 2) ∗ 2 Task State Transitions areneeded. The amount of Deploy/Undeploy actions varieswith the deployment case: While only one deployment mustbe started (or terminated) for the intra-process case, n + 1Deploy/Undeploy actions are required for the other twocases.

For each component network, the measurement ofstartup/shutdown times was repeated 5 times. Figure 12shows two plots with the mean execution times. Bothplots show the same data but differ in the visual sectionof the horizontal axis, such that the plot on the leftonly shows the data for smaller networks. The datashows that shutting down component networks is generallyfaster than starting them, in part due to the less requiredTask state transitions. In addition, the performance variesdramatically for different deployment cases. While acontroller consisting of 25 components grouped into asingle deployment can be started in milliseconds, it takesmore than 1s if all components are deployed locally intoindividual processes, or more than 1.5 s in the remote case.

These observations already indicate that the Deployaction is rather costly, and that it makes a noticeabledifference, if a deployment is started locally or remotely.An additional experiment (E2.2) confirms this observation.E2.2 examines the execution time for individual action typesby repeatedly executing them while taking the time for theircompletion. For example, to measure the average time of aStart action, it is ensured in advance that a Task Instance iscurrently running and is in the state STOPPED. A Transitionis then requested that contains only a single Start-action forthis Task Instance, and the time until the Transition wascompleted successfully is measured. Similar procedures arefollowed for the other action types. Figure 13 summarizesthe resulting average execution time for each action type.

0 20 40

Components in Network

0 0

0 5

1 0

1 5

2 0

2 5

3 0

Tim

e(s)

Intra-Process

Inter-Process

Remote

Start-up

Shut-down

0 100 200

Components in Network

0

5

10

15

20

25

Tim

e(s)

Intra-Process

Inter-Process

Remote

Start-up

Shut-down

Fig. 12 Time measurements for starting and shutting down componentnetwork with different sizes and deployment constellations

This test identifies which operations are more costly thanothers and how the local and remote execution of the actionsdiffer. The State Transition Actions except Configure allneed around 0.5ms with an overhead of 1.3ms whennetwork communication is involved. The action Configureis much slower, because in addition to the operation call, thehandle of the Task Context is refreshed by the CNDHandlerafterwards. This is necessary because additional ports canbe created during the configuration of the component,which can only be accessed after the Task Context handlehas been renewed. This is a rather costly operationand also necessary for the “Deploy” action, which islikewise relatively slow. However, terminating Deploymentswith the Undeploy action takes even longer that startingthem.

A further experiment (E2.3) is concerned with the timeneeded to reconfigure controllers. A processing chain withn relay components R (cf. Eqs. 8 and 10) is reconfiguredonline such that half of its MessageRelay components arereplaced with different instances R′ of the MessageRelaycomponent (cf. Eqs. 9 and 11).

A0P →B1 R1 → . . .Bn Rn → A0C (8)A0P →B1 R1 → . . .Bn R n

2→Bn+1 R′

1 → . . .Bn+ n

2 R′n2

→ A0C (9)

A0P →A0 R1 → . . .A0 Rn → A0C (10)A0P →A0 R1 → . . .A0 R n

2→A0 R′

1 → . . .A0 R′n2

→ A0C (11)

The experiment compares two different cases:

1. The transition of Eqs. 8 to 9 is the worst case.Since each component is running in a separateDeployment, and all deployments that are subject to thereconfiguration are on a remote system, many costlyremote Deploy and Undeploy actions are required toperform the transition.

2. The transition of Eqs. 10 to 11 is the best-case scenario.Here all components are running on the same computerwithin the same process.

While the worst-case scenario requires n/2 Deploy andUndeploy actions of remote processes in the transition, noDeploy or Undeploy actions are needed in the best casescenario, since all involved components are part of a singlelarge Deployment, which is already started with Eq. 10 andmay not be terminated as long there are still componentsfrom the deployment running.

Both cases are compared to the case where a static con-troller reconfiguration (restart) is performed, i.e. betweenEqs. 8 and 9 a transition to an empty network is carried out.

The experiment was executed multiple times for eachalternative while measuring the time for completing thereconfiguration. Figure 14 shows the mean execution times


Fig. 13 Time to perform anindividual operation of acomponent

Deploy

ApplyConfig

Configure

Start St

op

Cleanup

Undeploy

Connect

Disconnect

1.0

10.0

MeanTim

elog(ms)

2.6

1.2

12.9

0.5 0.40.5

4.3

1.6

0.6

7.7

3.4

16.7

1.8 1.91.7

10.2

3.4

2.1

Local

Remote

for each reconfiguration alternative. The worst-case online-reconfiguration can be carried out in less than two secondfor usual component network sizes with less than 50components. In the best-case scenario, this value is reducedto 320ms.

In particular, the Deploy/Undeploy and Configureactions have execution times that make it impossible toachieve network reconfiguration in a single control cycle forthe control frequencies common in robotics (i.e. 10-1000Hz). While the data suggests that a complete reconfigurationat a low control frequency for simpler controllers couldtheoretically be performed in one cycle, it should be notedthat there is no guarantee that no real-time violations willoccur. In some cases, however, these violations may causeproblems with system stability.

0 10 20 30 40 50

Number of components

0 0

0 5

1 0

1 5

2 0

2 5

3 0

3 5

4 0

Tim

e(s)to

exchange

halfof

components

Dynamic, worst case

Static, worst case

Dynamic, best case

Static, best case

0 50 100 150 200 250

Number of components

0

5

10

15

20

25

30

35

40

Tim

e(s)to

exchange

halfof

components

Dynamic, worst case

Static, worst case

Dynamic, best case

Static, best case

Fig. 14 Time to reconfigure a component network by exchanginghalf of its components compared to stopping and starting the newcomponent network

4.3 Case Study with a Real Robot

The validation tests from Sections 4.1 and 4.2 examine thetheoretically expected runtime performance of the proposedsystem through abstract experiments. The components inthe experiments intentionally do not do significant compu-tational operations, so that only the framework’s overheadis measured. A further experiment investigates how theruntime performance scales to real robot application sce-narios. For this purpose we implemented the followingfour different controllers for a real robot and measured thereconfiguration times between all different controllers:

– Search & Explore (S&E): An area exploration behaviorwith simultaneous object detection.

– Goal Navigation (GNav): Navigation to a goal which isdetected by camera.

– Manipulation (Manip): A visual servoing controller toguide the arm towards an object.

– Manipulator Tele-Operation (MTele): Control of themanipulator with a 3D mouse.

As target platform we chose the system Artemis [18]which is depicted in Fig. 15. Artemis is a six-wheeled rover,with the wheels mounted on passive rockers to compensatefor ground irregularities. It is equipped with a sensor mastthat holds a LiDAR, an IMU and three Full HD USBcameras. A 6 DOF manipulator with a under-actuated andsensorized gripper is attached to the front of the robot, wherealso a tilting laser scanner and two further cameras USBcameras are mounted.

All onboard computation is realized on System A,that was introduced earlier: an Intel i7-3610QE CPU @2.30Ghz with 16Gb RAM, hosted on a mini-ITX boardfrom Kontron. The operating system Ubuntu 18.04 andthe software subject to testing are installed on a Samsung


Fig. 15 The robot Artemis

SSD. The robot is controlled through an SSH connectionestablished via WiFi using an ASUS router that creates a 2.4GHz and 5 GHz WiFi network specifically for the robot.

The upcoming paragraphs first introduce the individualcontrollers followed by the statistical evaluation of thisexperiment. We use a graphic representation to explain thecontrollers (see Fig. 16). The Task Instances are shownas boxes with rounded corners, with the unique ID of theTask Instance written in bolt letters in the upper part ofthe component. Below, the prototype of the componentis shown (e.g. example::Task). To allow a more compactrepresentation of complex Task Networks, several TaskInstances can be grouped in a single box. In this case,the number of Task Instances within the group is writteninstead of the prototype (e.g. 5 Components). Input ports ofa component are always displayed on the left side, outputports always on the right side and data connections aredisplayed as an arrow between an output and an input port.In most cases, we do not show ports of a component that arenot connected. Additional information of the Task Network

group(5 Components)

state: RUNNING

input_port output_port

task_instanceexample::Task

state: RUNNING

input_port output_port

Fig. 16 Example of a graphical notation for a Task Network

model, such as task or connection properties or deploymentinformation, is not included in the visual representation.

This paper is not concerned with evaluating theperformance of the implemented controllers, but with theframework that manages these controllers. However, forillustration we have executed them all in an informalexperiment and show in Fig. 17 some impressions from thereal-life execution of the four different controllers on therobot Artemis.

4.3.1 Search & Explore

This controller (see Fig. 18) controls the robot in such away that it explores and maps an unknown area and at thesame time searches for a specific object. To achieve this, thecomponent area explorer generates target coordinates at theborders of the currently known map as input for a navigationplanner (ugv nav planner). The map is provided by a graph-based SLAM solution6 based on the g2o library [19] usingthe LiDAR and IMU on the sensor mast. By continuouslygenerating target coordinates at the outer borders of theknown area, the map is extended to previously unknownregions.

During the exploration, the images from the frontalcamera mounted on the sensor mast are processed by acomponent that executes the ArUco algorithm [20, 21] onthe camera images to detect the red box with the cup ontop, which is visible in Fig. 17. (arcuco detector). For thispurpose, the box has been specially prepared with an ArUcomarker so that it can be detected.

6https://github.com/dfki-ric/slam3d


https://github.com/dfki-ric/slam3d

Fig. 17 Pictures taken whileexecuting the differentcontrollers

The Search & Explore controller consists in total of 33Task Instances that are distributed over 8 Deployments.There are 49 port connections between the components. Thefull controller is shown in Appendix B.1.

4.3.2 Goal Navigation

The Goal Navigation controller is depicted inFig. 19. When executed, a data processing pipeline

manipulator(10 Components)

aruco_detector(2 Components)

pose

slam(7 Components)

mappose

rover(8 Components)

motion_command joint_state

area_explorerugv_nav4d::AreaExploration

map

goal_out_bestpose_samples

planner_state

ugv_nav_planner

map

trajectory

goal_pose_relative

start_pose_samples

state

ugv_nav4d::PathPlanner

trajectory_followertrajectory_follower::Task

trajectory

motion_commandrobot_pose

others(3 Components)

Fig. 18 Simplified visual representation of the Search & Explore controller



pose

rover_waypoint_following(6 Components)

marker_pose

navigation_goaljoint_state

ugv_nav_planner(2 Components)

map command

goal_pose_relative

start_pose_samples

manipulator(10 Components)


slam(7 Components)

mappose

rover(8 Components)

motion_command joint_state

Fig. 19 Simplified visual representation of the Goal Navigation controller

(rover waypoint following) computes goal coordinates infront of the object detected by the arcuo detector. The dataprocessing pipeline adds an offset to the detected objectpose and converts it from the camera coordinate systemto the body frame of the robot, which is located at thebottom of the sensor mast, because the navigation plannerexpects its input values in that frame. A trajectory controllerensures that the generated trajectory is followed and themotion controller converts euclidean motion commandsinto drive velocities and steering angles for the wheels.

To ensure that the planner is not steadily flooded withnew goal pose request every time the object is repeatedlydetected on a new camera image, a special component filters

repeated samples and allows only to pass a single sample ofthe object coordinates.

The Goal Navigation controller consists in total of 41Task Instances that are distributed over 17 Deployments.There are 58 port connections between the components. Thefull controller is shown in Appendix B.2.

4.3.3 Manipulation

The manipulation controller is shown in Fig. 20. Itimplements an eye-in-hand 3D visual servoing controller forthe manipulator. A camera in the gripper is used for ArUcorecognition, and a filter component updates the recognized


pose

waypoint_following(8 Components)

joint_state cart_cmd

marker_pose

manipulator_control(4 Components)

command joint_state

rover_and_slam(17 Components)


joint_limit_avoidancectrl_lib::JointLimitAvoidance

feedback control_output

wbc(4 Components)

jnt_state jnt_cmd

limit_cmd

cart_cmd

Fig. 20 Simplified visual representation of the Manipulation controller


Fig. 21 Simplified visualrepresentation of theManipulator Tele-Operationcontroller

spacemouse_driver(3 Components)

state: RUNNING

manipulator_cmd

gripper_cmd

manipulator_control(4 Components)

command

joint_stategripper_cmd



wbc(6 Components)

jnt_state jnt_cmd

limit_cmd

jnt_cmd

pose with the movements of the manipulator since the lastrecognition result, based on the forward kinematics of themanipulator, which is computed with the KDL7 library athigh frequency. In this manner, a sequence of waypointsexpressed in the reference system of the detected object istraced and are transformed into the reference system of therobot’s manipulator, so that they can be used as setpointsfor the Cartesian controller controlling the manipulator(waypoint following). Besides the Cartesian controller, ajoint limit avoidance controller prevents getting stuck injoint limits. The output of both simultaneously executedcontrollers is merged in a constraint-based programmingapproach similar to [22] (wbc).

The Manipulation in total consists of 40 Task Instancesthat are distributed over 16 Deployments and contains 60connections. The full controller is shown in Appendix B.3.

4.3.4 Manipulator Tele-Operation

The Manipulator Tele-Operation controller is shown inFig. 21. Here an operator uses a 3D mouse (SpaceMousefrom 3Dconnexion) to create reference twists for the endeffector of the manipulator. The resulting reference motionis again merged within the wbc component, with the resultsof the joint limit avoidance controller.

The Manipulator Tele-Operation controller in totalconsists of 14 TaskInstances that are distributed over6 Deployments and contains 25 connections. The fullcontroller is shown in Appendix B.4.

4.3.5 Results

Each possible transition between two different controllerswas executed 10 times while measuring the time from

7https://www.orocos.org/kdl

requesting the controller until the reconfiguration wascarried out completely. Table 5 summarizes the meanreconfiguration times and Table 7 shows the numbers ofactions required to realize each controller reconfiguration.Finally Table 6 shows for each transition the three most timeconsuming actions.

The mean transition times between the controllers rangefrom 0.11s to 4.16s with the transition GNav to S&Ebeing by the quickest and all transitions to MTele beingby far the slowest. When comparing the actions requiredfor the transition from GNav to S&E (see Table 7) withthe expected execution times under ideal conditions fromFig. 13, one can see that the actual transition takes about1.6 times longer, with most of the time spent configuringthe area explorer component (cf. Table 6). Transitioning tothe MTele controller is drastically slowed down by stoppingthe driver components for the robot’s USB cameras, whichstops frame grabbing and closes the devices and its devicefile descriptor.

The additional time required for a real operation com-pared to an ideal operation from Fig. 13 results mainly fromthe calculations that have to be performed within the com-ponent implementation. However, it is also apparent fromTable 6 that for some different applications of the sameactions, there is a large discrepancy in their execution time.A particularly drastic case is the time for the ApplyConfig

Table 5 Controller reconfiguration times

From

ToS&E GNav Manip MTele

S & E - 0.52s 0.55s 4.08s

GNav 0.11s - 0.59s 4.06s

Manip 0.18s 0.62s - 4.16s

MTele 2.01s 2.29s 2.23s -


https://www.orocos.org/kdl

Table 6 Most time-consuming actions for each transition

From→To Action Type TaskInstance(s) Time

S&E→ GNav ApplyConfig gnav FK 0.333sConfigure gnav FK 0.024sConfigure gnav SP 0.010s

S&E→ Manip ApplyConfig manip FK 0.324sConfigure manip FK 0.020sConfigure wbc 0.018s

S&E→ MTele Stop usbcam tower front 1.294sStop usbcam front 1.290sStop usbcam gripper 1.278s

GNav→ S&E Configure area explorer 0.032sApplyConfig area explorer 0.005sStart area explorer 0.004s

GNav→ Manip ApplyConfig manip FK 0.317sConfigure wbc 0.025sConfigure manip FK 0.017s

GNav→ MTele Stop usbcam gripper 1.242sStop usbcam front 1.238sStop usbcam tower front 1.221s

Manip→ S&E Configure area explorer 0.028sConfigure wbc 0.024sStop wbc solver 0.006s

Manip→ GNav ApplyConfig gnav FK 0.325sConfigure gnav FK 0.020sConfigure wbc 0.015s

Manip→ MTele Stop usbcam gripper 1.276sStop usbcam tower front 1.876sStop usbcam front 1.186s

MTele→ S&E ApplyConfig area explorer 0.708sStart usbcam gripper 0.276sStart usbcam tower front 0.252s

MTele→ GNav ApplyConfig aruco detector 0.958sStart usbcam gripper 0.276sStart usbcam tower front 0.255s

MTele→ Manip ApplyConfig aruco detector 0.953sStart usbcam tower front 0.189sStart usbcam gripper 0.184s

action on the area explorer component in the MTele→S&Etransition. In this transition, 708ms are required for the actions,instead of 28ms during theManip→S&E transition. All tran-sitions to or from MTele require a large number of actions,because the Task Network is much smaller than the others,which are more similar to each other. In addition, duringthe execution of the numerous actions, many componentswill continue to run, thereby consuming resources. Usingthe htop tool, we have seen a significant increase in CPUload during the reconfiguration process from/to MTele andsuspect this to be the cause of the discrepancy.

In summary, the experiment shows that the system canswitch between completely different behaviors such asmanipulation or autonomous exploration in about half a se-

cond, which for an outside observer is perceived as an instan-taneous response to the request. But of course, costlyoperations that, e.g. involve interaction with slow hardwaredevices, or sub-optimal implementations within the compo-nents can considerably delay the reconfiguration process.

5 Conclusions and FutureWork

This paper introduced a software system to model robotcontrollers from software components, execute them ondistributed hardware and switch between them dynamically.The proposed software facilitates the modular developmentof various behaviors by providing a declarative descriptionof the corresponding robot controllers, thereby relievingthe developer of the task of implementing procedures forswitching between the behaviors. The proposed methodallows to implement different behaviors of the robotindependently and to call them at any time regardless of thecurrent state of the robot, thus enabling the development ofrobots with a wide range of different capabilities.

We presented the metamodels of the model-driven deve-lopment approach, the runtime architecture for distributedcontroller execution and an algorithm for generating transi-tions between arbitrary controller networks. The performanceof the system was analyzed with a series of experiments. Inan additional experiment with a real robot, for which severalcontrollers were implemented with the proposed method,the feasibility for real robot control problems was shown.

The experiments show that the overhead caused by thecomponent development and communication frameworkRock/RTT is in an area that does not significantly impedecomplex real-time controllers composed of numerous com-ponents on distributed hardware. Reconfiguring the com-ponent network, on the other hand, requires several controlcycles, and there are no framework-side means to ensuresystem stability during this process. This problem was alsoidentified in [5], and the authors suggest implementing alocally stable mode in key software components.

In the locally stable mode, the components ignore all datainput from other components and instead execute internallycoded feedback loops that maintain the integrity of thesystem [5].

If a component is running and is not the subject ofa reconfiguration action, its execution is not affectedby reconfiguration activities on other components in thecomponent network. Because of this property, which resultsfrom RTT scheduling, we suggest that instead of activatinga locally stable mode in selected components, a basicstability control subsystem that ensures system integrityshould be kept running all the time. This is achievedby integrating the subsystem into each of the componentnetworks used. In our practical example with Artemis,


Table 7 Number of actions required for transitioning between controllers

From

ToS&E GNav Manip MTele

S & E − 0 Undeploy 0 Undeploy 5 Undeploy4 Disconnect 4 Disconnect 32 Disconnect9 Deploy 8 Deploy 3 Deploy9 Apply config 12 Apply config 5 Apply config13 Connect 15 Connect 8 Connect20 State changes 34 State changes 58 State changes55 Total 73 Total 111 Total

GNav 9 Undeploy − 9 Undeploy 14 Undeploy13 Disconnect 13 Disconnect 41 Disconnect0 Deploy 8 Deploy 3 Deploy1 Apply config 12 Apply config 5 Apply config4 Connect 15 Connect 8 Connect20 State changes 50 State changes 74 State changes47 Total 107 Total 145 Total

Manip 8 Undeploy 8 Undeploy − 13 Undeploy15 Disconnect 15 Disconnect 43 Disconnect0 Deploy 9 Deploy 3 Deploy5 Apply config 13 Apply config 6 Apply config4 Connect 13 Connect 8 Connect34 State changes 50 State changes 76 State changes66 Total 108 Total 149 Total

MTele 3 Undeploy 3 Undeploy 3 Undeploy −8 Disconnect 8 Disconnect 8 Disconnect5 Deploy 14 Deploy 13 Deploy24 Apply config 32 Apply config 32 Apply config32 Connect 41 Connect 43 Connect58 State changes 74 State changes 76 State changes130 Total 172 Total 175 Total

The sum of all individual actions for each transition is shown in bold face

system stability is ensured by an online trajectory generationcomponent (trajectory generation, cf. Appendixs B.1–B.4)that is connected upstream of the joint controllers. Thiscomponent permanently calculates dynamically executablemotion commands at control rate, even if the setpoints areonly sporadically generated by the higher-level controller[23]. The permanent presence of the online trajectorygenerator ensures that the robot joint movement remainsjerk-free, even if the real-time conditions are violated duringsetpoint generation, e.g. because the setpoint generatoris replaced due to a reconfiguration of the componentnetwork. In addition, the system will come to a standstillif the setpoints are not renewed for a longer, configurabletime span, by generating zero velocities when the jointcontrollers are driven speed-controlled. By integratingadditional safety-relevant components into the stabilitysubsystem, such as a collision avoidance component, evenlonger reconfiguration time spans could be bridged.

While the experiments showed satisfactory performance,a further reduction of the processing costs caused by the

framework overhead would be desirable. An easy way toachieve a performance gain for reconfiguring controllerson multi-CPU systems is to parallelize the application of aTransition.

Currently rock-runtime only supports x86 architecturesas execution platform. In principle all execution platformscould be targeted, that are supported by the underlyingcommunication framework, as long as the ProcessServercan be compiled and executed or re-implemented for thatplatform. There are first results in porting the Rock systemto ARM architectures as well (cf. [24]), but for rock-runtimethis was not yet done so far.

An interesting addition is the off- and online validationof the modeled controllers. For example, a semanticanalysis to identify invalid or suboptimal patterns in thedata flow or deployment setup could be used to detecterrors in the controller modeling process earlier. Theframework already measures the execution time for allreconfiguration actions. This data could be analyzed byadditional tools to give component developers hints on how


to optimize their components further, or to provide offlineestimates of expected reconfiguration times. Furthermore,the framework could be extended by the acquisition ofexecution speeds in normative operation of the components,e.g. to determine mean and worst case execution timesfor individual software components, on the basis of whichan offline estimation of the processing time for entireprocessing chains within a controller is possible.

With a permanent comparison of the current componentnetwork with the last requested one, an online integritycheck can be performed. For this purpose, the underlyingframework must provide information about all running com-ponents and their data connections (runtime introspection).The TaskNetworkHandler module could then be extendedaccordingly to detect differences between the expected andthe actual system state and as a reaction display the erroror perform extended safety and error handling operations.With the latest developments in Rock, a runtime intro-spection of the running component network can already beperformed, so that the requirements for the framework foronline integrity checking are already fulfilled.

Furthermore, it is possible to improve accessibilityand usability by providing additional tools for composingcontroller networks such as GUIs or domain-specificscripting languages.

Acknowledgements The authors would like to thank all developersof the Rock and Orocos RTT framework and especially SylvainJoyeux and JanoschMachowinski for their fundamental work on Rock.Furthermore, we thank the members of the student project THOROfor their support in the validation tests on the robot Artemis and Prof.Hendrik Wohrle for his valuable input in writing the paper.

This work on this paper was performed within the project D-Rock and Q-Rock, funded by the Federal Ministry of Educationand Research (BMBF) under grant number 01-IW-15001 and 01-IW-18003.

Funding Open Access funding provided by Projekt DEAL.

Open Access This article is licensed under a Creative CommonsAttribution 4.0 International License, which permits use, sharing,adaptation, distribution and reproduction in any medium or format, aslong as you give appropriate credit to the original author(s) and thesource, provide a link to the Creative Commons licence, and indicateif changes were made. The images or other third party material inthis article are included in the article’s Creative Commons licence,unless indicated otherwise in a credit line to the material. If materialis not included in the article’s Creative Commons licence and yourintended use is not permitted by statutory regulation or exceedsthe permitted use, you will need to obtain permission directly fromthe copyright holder. To view a copy of this licence, visit http://creativecommonshorg/licenses/by/4.0/.

Appendix A: Examples for SerializedTransition and Task NetworkModels

Listing 2 Example Transition in YAML format

Listing 3 Example Task Network in YAML format


http://creativecommonshorg/licenses/by/4.0/

http://creativecommonshorg/licenses/by/4.0/

Appendix B Example Applications

B.1 Search & Explore Controller

bogie_right_driverndlcom_wheelmodules::WheelModuleTask

ndlcom_message_out

ndlcom_message_in

joints_command joints_status

bogie_right_task_serialserial_ndlcom::Task

ndlcom_message_out

ndlcom_message_in

bogie_dispatcherjoint_dispatcher::Task

bogie_left bogie_right_command

bogie_front motion_status

bogie_right bogie_left_command

command_in bogie_front_command

manipulator_dispatcherjoint_dispatcher::Task

manipulator_driver_in arm_status

arm_command manipulator_command_out

manipulator_driverndlcom_aila_joints::AILAJointTask

ndlcom_message_in

ndlcom_message_out


wbcwbc::WbcVelocityTask

ref_gripper_cart_pos_ctrl

status_joint_pos_ctrl

ref_joint_pos_ctrl hierarchical_qp

joint_state status_joint_limits

solver_output

ref_joint_limits

trajectory_generationtrajectory_generation::RMLVelocityTask

joint_state command

target

area_explorerugv_nav4d::AreaExploration

map goal_out_best

pose_samples

planner_state

pose_estimationsimple_pose_integrator::Task

pose_samples_in pose_samples

dynamic_transformations

ugv_nav_plannerugv_nav4d::PathPlanner

map trajectory2D

goal_pose_absolute state

start_pose_samples

waypoint_providerwaypoint_provider::JointWaypointProvider

current_position current_target joint_control

ctrl_lib::JointPositionController

setpoint control_output

feedback

manipulator_serialserial_ndlcom::Task

ndlcom_message_in

ndlcom_message_out

aruco_detectoraruco::MarkerBoardDetector

image



wbc_solverwbc::HierarchicalLSSolverTask

hierarchical_qp solver_output

motion_controllermotion_controller::Task

motion_command actuators_command

actuators_statustrajectory_follower

trajectory_follower::Task

trajectory motion_command

robot_pose

cartesian_controlctrl_lib::CartesianPositionController

control_output

odometryodometry::LatOdom

actuator_samples

odometry_samples


xsensimu_xsens::Task

orientation_samples

bogie_front_driverndlcom_wheelmodules::WheelModuleTask

ndlcom_message_out

ndlcom_message_in


bogie_front_task_serialserial_ndlcom::Task

ndlcom_message_out

ndlcom_message_in

pointcloud_filterslam3d::PointcloudFilter

input output

slamslam3d::PointcloudMapper

scan mls

dynamic_transformations robot2map

depth_map_converterslam3d::ScanConverter

depth_map cloud

velodynevelodyne_lidar::LaserScanner

laser_scans

bogie_left_task_serialserial_ndlcom::Task

ndlcom_message_out

ndlcom_message_in

bogie_left_driverndlcom_wheelmodules::WheelModuleTask

ndlcom_message_out

ndlcom_message_in


usbcam_tower_frontcamera_usb::Task

frame



B.2 Goal Navigation Controller


input output


scan mls



map trajectory2D

goal_pose_relative

start_pose_samples



robot_pose


depth_map cloud


laser_scans





feedback


manipulator_driver_in arm_status

arm_command manipulator_command_out


ndlcom_message_in

ndlcom_message_out







solver_output

ref_joint_limits


joint_state command

target


ndlcom_message_in

ndlcom_message_out

s_st

majoint_limit_avoidance

ctrl_lib::JointLimitAvoidance





control_output


ndlcom_message_out

ndlcom_message_in



ndlcom_message_out

ndlcom_message_in



command_in bogie_left_command

bogie_right motion_status

bogie_front bogie_front_command

drive_to_aruco_FKrobot_frames::ChainPublisher

input robot_interaction_fk

sensor_fk

control_chain_fk

drive_to_aruco_Ttransformer::TransformationMonitor

dynamic_transformations setpoint

sp_feedback

drive_to_aruco_filterfilter_lib::MovingSensorFilter

sensor_sample estimated_sensor_sample

sensor_transform




drive_to_aruco_spwaypoint_provider::CartesianWaypointProvider

dynamic_transformations current_target

dr_pro

dy

drive_to_aruco_proxytransformer::TransformationProxy

input output

t

ck

o_W

tr

drive_to_aruco_obj_FKrobot_frames::ChainPublisher

input interaction_frame


image pose



actuators_status


actuator_samples

odometry_samples



orientation_samples


ndlcom_message_out

ndlcom_message_in



ndlcom_message_out

ndlcom_message_in


ndlcom_message_out

ndlcom_message_in


ndlcom_message_out

ndlcom_message_in


usbcam_tower_frontcamera_usb::Task

frameothers

(6 Components)


B.3 Manipulation

switch_up_cs_sp_convtransformer::RBSToCSConverter

input output



feedback


input output


scan mls


ut

mointcl


current_position current_target

joint_controlctrl_lib::JointPositionController


feedback


ndlcom_message_out

ndlcom_message_in



ndlcom_message_out

ndlcom_message_in



bogie_front motion_status

bogie_right bogie_left_command

command_in bogie_front_command


manipulator_driver_in all_status

arm_command arm_status

manipulator_command_out


ndlcom_message_in

ndlcom_message_out







solver_output

ref_joint_limits

switch_up_FKrobot_frames::ChainPublisher

input robot_interaction_fk

sensor_fk

control_chain_fk

switch_up_obj_FKrobot_frames::ChainPublisher

input interaction_frame


joint_state command

target


map trajectory2D

start_pose_samples






robot_pose


ndlcom_message_in

ndlcom_message_out

switch_up_Ttransformer::TransformationMonitor

dynamic_transformations setpoint

sp_feedback

ctrl_feedback

switch_up_spwaypoint_provider::CartesianWaypointProvider

dynamic_transformations current_target

Mo

oin

switch_up_cs_fb_convtransformer::RBSToCSConverter

input output

upma

se

ck


image pose

switch_up_filterfilter_lib::MovingSensorFilter

sensor_sample estimated_sensor_sample

sensor_transform







actuators_status

ef_jot

rolntro


actuator_samples

odometry_samples



depth_map cloud

usbcam_grippercamera_usb::Task

frame


orientation_samples


ndlcom_message_out

ndlcom_message_in



ndlcom_message_out

ndlcom_message_in


laser_scans


ndlcom_message_out

ndlcom_message_in


ndlcom_message_out

ndlcom_message_in


ul

s

s


B.4 Manipulator Tele-Operation Controller





feedback

spacemouse_drivercontroldev::Mouse3DTask

raw_command

spacemouse_gripper_controllerarm_control::GripperTeleOp

raw_command gripper_controlspacemouse_converter

arm_control::RawToCartesianState

raw_command cartesian_control

joint_control_gripperctrl_lib::JointPositionController


gripper_command arm_status

manipulator_driver_in

manipulator_command_out

arm_command


target command

joint_state




joint_state hierarchical_qp

ref_joint_pos_ctrl

status_gripper_cart_pos_ctrl

solver_output status_joint_limits

ref_joint_limits

weight_joint_limits


ndlcom_message_in

ndlcom_message_out



ndlcom_message_in

ndlcom_message_out





feedback


feedback activation

control_output

s_sta

ma


References

1. Quigley, M., Gerkey, B., Conley, K., Faust, J., Foote, T., Leibs,J., Berger, E., Wheeler, R., Ng, A.: ROS: an open-source RobotOperating System. In: ICRA workshop on open source software,vol. 3, pp. 1–5 (2009)

2. Joyeux, S., Schwendner, J., Roehr, T.M.: Modular software for anautonomous space rover. In: Proceedings of the 12th InternationalSymposium on Artificial Intelligence, Robotics and Automationin Space (i-SAIRAS, 2014), (Montreal, Quebec, Canada), pp. 1–8(2014)

3. Metta, G., Fitzpatrick, P., Natale, L.: YARP – yet another robotplatform, Version 2.3.20. Int. J. Adv. Robot. Syst. 3(1), 43–48(2013)

4. Santos, A., Cunha, A., Macedo, N., Arrais, R., dos Santos,F.N.: Mining the usage patterns of ROS primitives. In: in 2017IEEE/RSJ International Conference on Intelligent Robots andSystems (IROS), (Vancouver, BC), pp. 3855–3860. IEEE, Sept(2017)

5. Stewart, D.B., Khosla, P.: The chimera methodology: Designingdynamically reconfigurable and reusable real-time using port-based objectssoftware. Int. J. Softw. Eng. Knowl. Eng. 6(2),249–277 (1996)

6. Lyons, D.M., Arbib, M.A.: A formal model of computation forsensory-based robotics. IEEE Trans. Robot. Autom. 5, 280–293(June 1989)

7. Soetens, P., Bruyninckx, H.: Realtime hybrid task-based controlfor robots and machine tools. In: Proceedings of the 2005 IEEEInternational conference on robotics and automation, (Barcelona,Spain), pp. 259–264 (2005)

8. Soetens, P.: A Software framework for real-time and distributedrobot and machine control. PhD thesis, Issue: May ISBN:9056826875 (2006)

9. Bezivin, J.: On the unification power of models. Softw. Syst.Modeling 4(2), 171–188 (2005). ISBN: 1619-1366, 1619-1374

10. Bischoff, R., Guhl, T., Prassler, E., Nowak, W., Kraetzschmar,G., Soetens, P., Haegele, M., Pott, A., Breedveld, P., Broenink,J., Brugali, D., Tomatis, N.: BRICS - Best Practice in Robotics.In: ISR 2010 (41st International symposium on robotics) andROBOTIK 2010 (6th german conference on robotics), (Munich,Germany), VDE, pp. 968–975 (2010)

11. Joyeux, S., Albiez, J.: Robot Development: from Components toSystems. In: 6Th national conference on control architectures ofrobots, (Grenoble, France), INRIA Grenoble Rhone-Alpes May,pp. 1–15 (2011)

12. Schlegel, C., Lotz, A., Lutz, M., Stampfer, D., Ingles-Romero,J.F., Vicente-Chicote, C.: Model-driven software systems engi-neering in robotics: covering the complete life-cycle of a robot.Inform. Technol. 57(2), 85–98 (2015). ISBN: 1611-2776

13. Nordmann, A., Hochgeschwender, N., Wigand, D., Wrede, S.: Asurvey on domain-Specific modeling and languages in robotics. J.Softw. Eng. Robot. 7, 75–99 (2016)

14. Wang, S., Shin, K.: Reconfigurable software for open architecturecontrollers (2001)

15. Ingles-Romero, J.F., Lotz, A., Chicote, C.V., Schlegel, C.: Dealingwith run-Time Variability in Service robotics: Towards a DSLfor non-Functional Properties arXiv:1303.4296 [cs], pp. 1–8, Mar(2013)

16. Fleurey, F., solberg, A.: A domain specific modeling languagesupporting specification, simulation and execution of dynamicadaptive systems. In: Schurr, A., Selic, B. (eds.) Model DrivenEngineering Languages and Systems, vol. 5795, pp. 606–621.Springer, Berlin (2009)

17. Klotzbucher, M., Biggs, G., Bruyninckx, H.: Pure Coordina-tion using the coordinator–Configurator Pattern, ArXiv, vol.abs/1303.0066, pp. 11–4, Feb arXiv:1303.0066 (2013)

18. Schwendner, J., Roehr, T.M., Haase, S., Wirkus, M., Manz, M.,Arnold, S., machowinski, J.: The artemis rover as an example formodel based engineering in space robotics (2014)

19. Kummerle, R., Grisetti, G., Strasdat, H., Konolige, K., Burgard,W.: G2O: A General Framework for Graph Optimization. In:2011 IEEE International Conference on Robotics and Automation,(Shanghai, China), IEEE, May, pp. 3607–3613 (2011)

20. Garrido-Jurado, S., Munoz-Salinas, R., Madrid-Cuevas, F.,Medina-Carnicer, R.: Generation of fiducial marker dictionariesusing mixed integer linear programming. Pattern Recogn. 51,481–491 (2016)

21. Romero-Ramirez, F.J., Munoz-Salinas, R., Medina-Carnicer, R.:Speeded up detection of squared fiducial markers. Image VisionComput. 76, 38–47 (2018). ISBN: 0262-8856

22. Schutter, J.D., Laet, T.D., De Schutter, J., De Laet, T., Rutgeerts,J., Decre, W., Smits, R., Aertbelien, E., Claes, K., Bruyninckx,H.: Constraint-based task specification and estimation for sensor-based robot systems in the presence of geometric uncertainty. Int.J. Robot. Res. 26(5), 433 (2007). Publisher: SAGE Publications

23. Kroger, T.: Opening the door to new sensor-based robotapplications - the reflexxes motion libraries. In: 2011 IEEEInternational Conference on Robotics and Automation, (Shanghai,China), pp. 1–4, IEEE May (2011)

24. Roehr, T.M., Willenbrock, P.: Binary packaging for the robotconstruction kit (2018)

Publisher’s Note Springer Nature remains neutral with regard tojurisdictional claims in published maps and institutional affiliations.

Malte Wirkus received his Diploma in Computer Science at theUniversity of Bremen in 2010. He joined the Robotics InnovationCenter (RIC) of the German Research Center for Artificial Intelligence(DFKI GmbH) in 2010. In different research and industry projects, hegained experiences in the fields of robotic mobile manipulation, multi-agent architectures, human-robot collaboration and space robotics.With his current scientific research interest in control architectures andframeworks for robot application development, he works as researcherand project leader at DFKI-RIC.

Sascha Arnold received the Dipl.-Inf. degree in computer sciencefrom the University of Bremen, Bremen, Germany, in 2014. Histhesis was about robust 3-D environment modeling using pose graphoptimization on LiDAR data. He is currently with German ResearchCenter for Artificial Intelligence (DFKI), Kaiserslautern, Germany, asa Researcher. His research interests include localization and mappingin challenging domains, digital signal processing, and sensor fusion,and their application in space and underwater robotics.

Elmar Berghofer received his Diplom (masters degree) in computerscience from the University of Bielefeld, Germany, in 2011. His thesisconcerns object recognition based on multi-modal sensor information.He joined the German Research Center for Artificial IntelligenceDFKI, in Germany in 2011. He gained here experience in research,project management and acquisition. His research interests include,the field of machine learning, in particular object classification, sensorfusion, and on-line learning and currently focuses on the field of datastream mining.


http://arxiv.org/abs/1303.4296

http://arxiv.org/abs/1303.0066

online reconfiguration of distributed robot control systems ......a further experiment demonstrates...

Documents