Towards an Advanced ROS Package Generator

Anthony Remazeilles and Jon Azpiazu

TECNALIA, Paseo Mikeletegi, Parque Tecnol

ogico, San Sebastian, Spain

Keywords:

Robotics, Software Engineering, Code Generation.

Abstract:

This paper describes a tool for generating ROS packages and nodes. Compared to the relatively basic tra-

ditional package creation method, this tool can generate a whole node structure, including its life-cycle and

the exposed interface to other ROS nodes. Following a separation of concerns, the developer only deﬁnes the

interaction means in a XML ﬁle, and the tool provides the whole skeleton of the nodes, including the interface

creation and management. This way, the developer can focus on his real added value, the implementation of

the node logic. Compared to advanced node management frameworks proposed in literature, the tool pro-

posed does not require the developer to understand and agree on complex high-level architecture models. The

developer only has to select a template model, and to provide the desired interface to get the code generated.

The package generation is made possible thanks to package templates, and we provide with the generator tool

two templates for creating nodes either in C++ or Python. The user has also the possibility to design his own

template, so that he can develop the one that best ﬁts his needs and best practices. The package generator code

is accessible on public repository hosting facilities.

1 INTRODUCTION

The Robot Operating System (ROS) (Quigley et al.,

2009) has become the standard framework for devel-

oping robotic solutions. Its popularity in the research

community does not need to be demonstrated any-

more and initiatives like ROS-Industrial promote its

use in the context of industrial applications.

Surprisingly, in comparison to the outstanding

number of applications developed with ROS, there is

very little material for creating the basic component

of a ROS development, named ROS package. A ROS

package is usually created using terminal commands

such as catkin create pkg which enables introducing

meta information about the package to generate (list

of dependencies, author email, etc). Once executed, a

folder is created containing the ﬁles package.xml and

CMakelists.txt that are partially ﬁlled out according to

the command arguments. These two ﬁles are the ba-

sics that deﬁne a ROS package. Then, the compo-

nent creation is left entirely to the developer. On one

hand, this is positive since the developer has a com-

plete freedom for the implementation. On the other

hand, we can highlight the following drawbacks:

Loss of Time: Every time a new package or node

is created, the developer has to do it from scratch.

Clever copy and paste may be used to get inspira-

tion from previously designed nodes but this is usu-

ally error-prone. The developer is very likely to loose

time in re-implementing the basic layers of the node.

Implementation Quality: There is a lot of docu-

mentation proposing good practices on packages and

nodes structure. Nevertheless, their use depends on

the developer, according to his programming knowl-

edge and expertise, his time constraint or motivation.

Thus, for any of these reasons, it is probable that a

developer may take some inappropriate implemen-

tation decisions. Also, a developer team may have

some preferred implementation schemes (documen-

tation style, header contents, communication models,

...). But there is no simple solution to generate pack-

ages or node skeletons from these guidelines.

Node Life-cycle Hidden in Source Code: The life-

cycle of a node refers to its different stages of execu-

tion (a more detailed description is given later). This

information is crucial to understand how to use the

node and interact with it, and should be detailed in

the documentation. It is thus up to the developer to

provide a good and updated description. Otherwise, it

may be needed to dig into the code to ﬁgure out how

the node behaves, which can be very time-consuming.

Node Interface Hidden in Source Code: The node

interface (communication mechanisms exposed to

other ROS nodes) is usually described in the node’s

Remazeilles, A. and Azpiazu, J.

Towards an Advanced ROS Package Generator.

DOI: 10.5220/0007834002430250

In Proceedings of the 16th International Conference on Informatics in Control, Automation and Robotics (ICINCO 2019), pages 243-250

ISBN: 978-989-758-380-3

243

documentation. If it is not documented, an alternative

is to run the node, and use ROS introspection tools to

ﬁgure it out. Nevertheless, it may not be evident to

infer the complete interface this way.

Code Evolution and Reuse Potentially Complex:

The two previous points highlighted the potential dif-

ﬁculties for users to understand how to use an existing

node. The evolution of the code (by other developer,

but even by the author) may also be complex if the

current implementation is not well described and if it

does not follow best practices. Even little extensions

of the functionality or interface may lead to signiﬁ-

cant development time for (i) understanding the code,

and (ii) reshaping the structure to follow better imple-

mentation strategies.

Based on this analysis, we propose a novel ROS

package generator to speed up and ease ROS develop-

ment

The package generator relies on package tem-

plates, but any advanced developer can implement

his own one, based on his needs and programming

policies. For the user, the package generation only

requires the selection of the template, and a speci-

ﬁcation ﬁle describing the interface of the package.

The package generator then automatically provides a

whole package by adjusting the template according to

the speciﬁcations. The component skeleton obtained

enables the developer to focus on his real contribu-

tion, that is the node logic implementation. The tool

is also provided with update mechanisms enabling the

developer to update the interface of the package gen-

erated without loosing the code already inserted.

Next Section presents the literature related to ROS

packages and nodes creation. Section 3 describes the

component we have developed, and in Section 4 we

show how it can be used with the templates provided,

and how new templates can be created. Conclusions

and future work are mentioned in the last Section.

2 STATE OF THE ART

Several high-level tools exist for automating the cre-

ation of ROS nodes and packages. They reduce the

cost of code production by using hidden code tem-

plates or skeletons. If the proposed template ﬁts his

needs, the developer can focus on the logic implemen-

tation and let the automation tool prepare the rest of

the architecture.

ROSLab is a high-level programming language

(Bezzo et al., 2014) that is an extra layer added on the

top of ROS to simplify the lower level code genera-

tion. In a Java-based graphical interface it enables to

See Repository https://github.com/tecnalia-advanced

manufacturing-robotics/ros pkg genros pkg gen in github

connect nodes through their communication interface

to create a complete application. The underlying code

generation uses ROSGen component implemented in

Coq (Meng et al., 2015). Unfortunately, that solution

has not been maintained since 2017.

ROSMOD (Robot Operating System Model-

driven development tool suite) also provides graphi-

cal tools for rapid prototyping and deploying large-

scale applications (Kumar et al., 2016). It follows

a component-based approach structure, and is said

to be a reﬁnement of the ROS component model.

ROSMOD intends to reduce the amount of time and

effort developers spend installing, conﬁguring, and

maintaining applications. Nevertheless, it requires

agreeing with the proposed component model, that is

slightly different from the traditional ROS one, which

may be acknowledged only by advanced developers.

BRIDE (BRICS Integrated Development Environ-

ment) is one the main outcomes of the European

project BRICS (Bischoff et al., 2010; Bubeck et al.,

2014). Following a Model Driven Engineering ap-

proach, it provides an abstract representation of com-

ponent interfaces and behaviors, as well as an auto-

matic model validation and code generation (in ROS

or Orocos). BRIDE is integrated as an Eclipse plu-

gin, so that the developer can graphically design

nodes and their communication interface. The devel-

opment is following the spirit of Component-Based

Software Engineering, targeting quality, technical and

functional reusability (Brugali and Shakhimardanov,

2010). Considering that a software component is de-

ﬁned to be a unit of composition with contractually

speciﬁed interfaces and explicit context dependencies

only, BRICS stresses the clear distinction in between

the interface (framework speciﬁc) and the implemen-

tation of the component functionalities (framework

independent). From the deﬁnition of a component in-

terface, BRICS prepares the ROS node structure and

the communication tools, and places in a separate ﬁle

the skeleton of the code to be ﬁlled by the user. The

concepts followed by BRICS are of major importance

for developing stable components with clear inter-

faces. Unfortunately, the developments have stopped

since 2017 and at the ROS Indigo release. Further-

more, changing the life-cycle or the generic structure

of the ROS component pattern requires strong exper-

tise in Java programming and Eclipse plugin develop-

ment.

So far, it is not evident whether any of these solu-

tions has been broadly accepted and / or used. We see

two limitations that could explain such lack of com-

munity acceptance. First of all, these tools rely on

meta models of software architecture placed on the

top of ROS ecosystem. Even if their technical sound-

ICINCO 2019 - 16th International Conference on Informatics in Control, Automation and Robotics

244

ness and quality may be relevant, they nevertheless

require a (too) signiﬁcant effort from the developers

to learn, and thus to be willing to use these solutions.

Our package generator only requires selecting a tem-

plate based on ROS concepts (like the life-cycle) and

ﬁlling a XML ﬁle deﬁning the desired interface. Sec-

ondly, the maintenance of some of these software un-

fortunately stopped with the closure of the projects

they came from. To maintain these developments, a

signiﬁcant effort to understand the framework imple-

mentation is required since the component patterns

are usually deﬁned implicitly in the source code.

The package templates used by our generator are

not embedded in the generator code, and new tem-

plates can be created following instructions similar

to templating languages, easing the adaptation of the

patterns to developer needs. Also the package gen-

erator is implemented in Python, which is a common

programming language within the ROS community.

As already stated, it is very important to deﬁne

explicitly the interface of a node. But it is also cru-

cial making clear what is its life-cycle. Even though

part of it may be inferred from the interface deﬁni-

tion, critical aspects may not be easily inferred , such

as when the node computation starts, can (should) we

stop and resume the node activity during the appli-

cation, and so on. A particular care is taken with

such matters in ROS2, through the concept of man-

aged nodes (ROS, 2018). Managed nodes implement

a state machine indicating whether the node is uncon-

ﬁgured (just instantiated), inactive (conﬁgured but not

running), active (performing its computation) or ﬁnal-

ized (before destruction). The deﬁnition of a managed

node requires implementing the different transitions

from one state to another. By structuring the node’s

life-cycle, the use of managed nodes is less depen-

dent on the developer’s implementation choices. This

should deﬁnitely ease monitoring applications and the

reuse of components. Nevertheless, the duty of creat-

ing nodes and deﬁning the communication interface

remains on the user’s side, so that a package genera-

tor tool would still be of interest.

3 THE PACKAGE GENERATOR

Our package generator leads to the following work-

ﬂow (from the source folder of a ROS workspace):

# d e f i n i t i o n o f t h e p a ck a ge s p e c i n a f i l e

$ g e d i t m y g r eatp a c k age . r o s p a c k a g e

$ r o s r u n p a c k a g e g e n e r a t o r g e n e r a t e p a c k a g e \

m ygre a t p acka g e . r o s p a c k a g e python m o d e l u p d a t e

mygreatpackage.ros package is a XML description

of the package speciﬁcation, including all nodes to

be created and their desired respective interfaces

(an example of such ﬁle is provided on Fig. 1).

python model update is the name of the template to

be used to generate the new package.

Once executed, a complete skeleton of the pack-

age and included nodes is generated automatically,

including the deﬁnition and implementation of the in-

terface as well as the nodes’ life cycle, according to

the package model selected. The package documenta-

tion with all nodes speciﬁcation (interface, node life-

cycle) is also automatically generated. The developer

just has to write the node intelligence, in well des-

ignated speciﬁc regions. If he decides to change the

interface (for example adding a topic subscription),

the XML description ﬁle is updated and the previ-

ous command relaunched. The user contribution in

the tagged areas is kept, as well as additional ﬁles not

present in the template if the developer explicitly re-

quires it. The Developer still can change the imple-

mentation anywhere, diverging from the original node

pattern. In such case, the update functionality could

not be used anymore.

Next Section provides some terminology and Sec-

tion 3.2 gathers the requirements that guided the tool

design. Then Section 3.3 details the needed informa-

tion to launch the package generation, while Section

3.4 describes the package generator implementation.

3.1 Package Generation Terminology

We start with the deﬁnition of different concepts we

will frequently use.

Template Package: set of ﬁles, in any of the ROS

known languages, constituting a package skeleton

(like python model update in the previous example).

Each ﬁle of the template is composed of (i) code to be

reproduced as is in the generated ﬁle, (ii) tags to be

interpreted by the code generator and (iii) speciﬁc ar-

eas indicating where the Developer should insert the

node’s intelligence.

Template Designer: person developing a template

package. He is in charge of deciding how the XML

speciﬁcation ﬁle is affecting the code skeleton, and

where the Developer should provide the node logic.

The Template Designer provides the whole package

and node pattern, from the node interface to its life-

cycle, and can also automate the generation of the

documentation. He can also restrict the possible inter-

face (by implementing only a subset of the ROS com-

munication tools). It requires a deeper understanding

of the package generator mechanism.

Package Developer: person who wants to create a

new ROS package. His responsibility is (i) to select

the suitable template, (ii) to deﬁne the package spec-

iﬁcation accordingly to the template documentation,

Towards an Advanced ROS Package Generator

245

Figure 1: XML Package speciﬁcation ﬁle example.

and, once the package is created, (iii), to add the node

logic to the generated code.

Node Logic: code added by the Developer to the gen-

erated package. If we assume that the package tem-

plate takes care of the node interface and its life-cycle,

the node logic should only consider the implementa-

tion of the node computation.

Node Interface: list of communication means a node

is proposing to the rest of the ROS nodes. It is based

on all standard ROS tools, i.e. topics, services, ac-

tions, parameter and dynamic parameters, tf. Ideally,

the template should be designed to make a clear sep-

aration between the interface management (like sub-

scriber creation and callback), and the exchanged in-

formation use or generation (like processing a mes-

sage received to produce a message to send). Also the

template should handle the interface description in the

documentation ﬁle (Readme.md ﬁle).

Node Life-cycle: behavior of the node from its cre-

ation to its termination. Every ROS node has a life-

cycle, although it may not be clearly described (and

implemented). The Template Designer is ideally re-

sponsible for deﬁning the node life-cycle, through the

proposed template. He should therefore mention it

in the template description, and handle it in the node

skeleton. This way, a Developer knows by selecting a

template how the life-cycle will be, and, once a pack-

age is generated and ﬁlled by the Developer, a user of

the package will have a clear description of the com-

ponent’s behavior.

It is clear that a strong responsibility is placed on

the Designer’s shoulders. Indeed, the quality of the

template, the node life-cycle and interface implemen-

tation and description strongly rely on him.

3.2 Package Generator Objectives

The package generator has been implemented for ad-

dressing the following objectives:

Automatic Code Generation, including node life-

cycle pattern and node interface: after the package

generation, the Developer focuses on the node logic.

Node Creation based on the Interface: the Devel-

oper should only deﬁne the expected input and output

information to create a node. In the templates pro-

vided, the XML conﬁguration mainly focuses on the

interface. Code related to the interface creation and

management is then automatically created.

Separation of Concerns: this is related to a clear dis-

tinction of the interface deﬁnition and management

and its implementation. This separation is totally de-

pendent on the templates, not on the code generation.

The templates proposed follow this leitmotiv, by ex-

plicitly using different ﬁles for the two aspects.

Adjustability/customizability: the template model

is not hard-coded in the package generator, and new

ones can be added. We provide right now two tem-

plates, one for C++ nodes and another for Python

nodes. A Template Designer could use these models

as example to produce templates more suitable to his

need. Template creation enables teams to agree and

follow common patterns. Also, by using code gen-

eration tools instead of inheritance mechanisms, the

Developer has access to all the code in his package,

and can, if he sees the needs, change any part of the

generated code.

Keep It Simple: the use of the package generator is

made simple to ease its adoption by the community.

3.3 User Input Information

The generation of a package requires two informa-

tion: (i) a speciﬁcation ﬁle and (ii) the name of the

selected template. The speciﬁcation ﬁle is a XML

ﬁle which structure is strongly inspired by the BRIDE

model. An example of speciﬁcation ﬁle is presented

in ﬁgure 1. The package attributes, including its

name, are meta-data associated to the package, used

to ﬁll the package.xml ﬁle and the documentation.

The package tag contains a node tag per node to be

ICINCO 2019 - 16th International Conference on Informatics in Control, Automation and Robotics

246

generated (so far all nodes follow the same pattern).

The attributes of a node provide speciﬁcations for it.

In the current templates, the Developer can specify

the node name and the update frequency.

Inside the node tag is then described the node’s

interface. In the provided templates, the Developer

has access to all standard ROS communication means,

i.e publishers, subscribers, parameters and dynamic

parameters, service clients and servers, action clients

and servers, tf listeners and broadcasters.

Most of the interface components are described

by the same attributes, i.e. name, type and descrip-

tion. The ﬁrst two attributes are required for the auto-

matic generation of the interface code, while the latter

is needed for the documentation generation.

Finally, a set of dependencies are provided. Cur-

rent templates automatically add these packages to the

ﬁles CMakeLists.txt and package.xml. When the XML

ﬁle is loaded, we also check the packages used by the

interface, so that additional dependencies may be au-

tomatically added accordingly.

3.4 Package Generator Details

The package generator, implemented in Python, is

composed of the following ﬁles (see Fig. 2):

• package generator.py: orchestrates the whole

package generation, given a template directory,

and a XML package description.

• package xml parser.py: is responsible for parsing

the XML package description.

• code generator.py: generates a ﬁle from a XML

node description and a ﬁle template.

• update mgt.py: provides the update functionality

for packages already created.

The script package generator.py orchestrates the

whole package generation, following the package

template. A package template is a regular directory

which typical contents are presented on ﬁgure 3. It

must contain two folders: conﬁg and template. The

ﬁrst one provides conﬁguration information, while the

second gathers the skeleton of all ﬁles to be generated.

In the conﬁguration folder, the ﬁle dictionary.yaml

deﬁnes the tags a Developer can use in his XML con-

ﬁguration ﬁle. The Designer deﬁnes here each possi-

ble interface, with the related attributes. In the exam-

ple in ﬁgure 4, the provided interfaces are very sim-

ilar to the standard ROS ones, but the Designer can

also add new concepts, or even reduce the number of

interfaces allowed if appropriate. Note that, on the

Developer side, a tool is provided to generate a XML

speciﬁcation skeleton with all the accepted interfaces

by the template. Finally, the ﬁle functions.py enables

Figure 2: Main components of the package generator.

the Designer to add simple functions that can be used

during the code generation (mentioned later on).

The global script package generator.py invokes

the script package xml parser to load and pre-process

the package description, and then handles the gen-

eration of all template ﬁles by calling the script

code generator.py. If the XML conﬁguration ﬁle con-

tains several nodes, ﬁles containing node in their

name (node common.cpp and node ros.cpp in the ex-

ample on Figure 3) are generated for each node spec-

iﬁed, while the other ﬁles are only generated once.

Figure 3: Typical contents of a package template.

Figure 4: Speciﬁcation of the dictionary handled by a given

package template (ﬁle dictionary.yaml).

The script code generator.py requires a template

ﬁle, the speciﬁcations of the global package as well

Towards an Advanced ROS Package Generator

247

as the speciﬁcations of one node. The template ﬁle is

scanned, looking for speciﬁc markers. Currently, for

simplicity, the markers are all of format {instruction}.

The instructions are purely related to the different tags

the Developer can introduce in his XML ﬁle. More

exactly, for all interface types, the Designer is pro-

vided with the generator instructions {iﬁnterface} and

{forallinterface}. As an example, let us assume that a

template ﬁle contains the following code:

{ i f p u b l i s h e r }

/ / d e f i n i n g a l l p u b l i s h e r s

{ e n d i f p u b l i s h e r }

{ f o r a l l p u b l i s h e r }

r o s : : P u b l i s h e r {name} = n . a d v e r t i s e <{t ype }>(” { name } ” , 1 ) ;

{ e n d f o r a l l p u b l i s h e r }

The comment line will only be generated if at least

one publisher is deﬁned. The publisher deﬁnition will

be repeated for all the publishers deﬁned, using the

values of the attributes name and type found in the

XML description of this node.

The script code generator.py also handles instruc-

tions of type {apply-func}. It will apply the function

func with the interface attributes as input parameters.

For example, the type of an interface is provided in the

XML ﬁle with the format PackageName::Type, i.e as

we would use it in regular C++ code. Dedicated func-

tions are introduced for mapping this type to Python

formats, for extracting the package, the type, etc. All

these functions are deﬁned in the conﬁguration ﬁle

functions.py provided with the package template.

If the Developer executes again the package gen-

eration after its creation, the package

generator de-

tects the presence of the package already created, and

assumes that an update of that package is requested.

A copy of the current package is placed in a temporal

folder, and all ﬁles are then generated, and compared

to their previous version. More exactly, the script up-

date mgt.py focuses on the areas delimited as follows:

# p r o t e c t e d reg i o n u s e r u p date b e g i n #

r o s py . l o g i n f o ( ” U pdat e Re c e i v e d v a l u e : {} ” . f o r m a t ( d a t a .

i n c o u n t e r ) )

# p r o t e c t e d re g i o n us e r u p d a t e en d #

All Developer’s code inserted between these tags is

indexed and reinserted in the new code generated.

That way the code already inserted by the Developer

is maintained upon update.

4 USE AND LESSONS LEARNED

As an illustration of use of the package generator, we

have implemented two package templates. Both pro-

vide a standard node template with a clear life-cycle

that can already handle a large variety of develop-

ments. They can also help Template Designers im-

plementing their own models.

Next Section describes their implementation,

while Section 4.2 provides insight on the lessons

learned during the template design and use for real

packages. Finally we will compare the tool outcomes

to the objectives initially deﬁned in Section 3.2.

4.1 Templates Provided

The two templates provided are similar in term of be-

havior. They enable generating packages with nodes

respectively in C++ and Python. We focus on the C++

version, as most of the description holds for both.

Following the separation of concerns strategy, we

distinguish the node communication and coordination

from the computational part. The Developer’s contri-

bution is only expected in the latter, all other aspects

are automatically generated. In terms of life-cycle

pattern, the proposed scheme is a periodical update, in

which at each iteration of the main loop, the computa-

tional layer gets the latest messages received (through

message subscription) to generate the related output

to be transmitted (through message publication).

The separation of concerns is materialized by the

presence of two ﬁles per node:

• ros/src/[node name] ros.cpp ROS interface and

life-cycle implementation. It deﬁnes the class

Ros[NodeName].

• common/src/[node name] common.cpp will con-

tain the node logic provided by the Developer,

mainly by ﬁlling a class named [NodeName]Impl.

The class Ros[NodeName] deﬁnes the ROS com-

munication interface. It contains also attributes re-

lated to classes deﬁned in [node name] common.cpp:

• [NodeName]Conﬁg: contains the (dynamically

adjusted or not) parameters.

• [NodeName]Data: constains the input messages

received and the output messages to be sent.

• [NodeName]Impl: will contain the Developer im-

plementation of the node.

File [node name] ros.cpp contains the main func-

tion. After creating an instance of Ros[NodeName]

and a conﬁguration step an inﬁnite loop is started.

All messages received are stored in an object of type

[NodeName]Data. At each iteration, the method up-

date of the class NodeNameImpl is called:

v o i d Nod eImp l : : u p d a t e ( [ NodeName ] D a t a &d a t a , [ NodeName ]

Co n f i g c o n f i g )

The parameter data contains the latest messages re-

ceived through subscription. Based on this input, the

method update implemented by the Developer can

prepare messages to be sent and store them in speciﬁc

ICINCO 2019 - 16th International Conference on Informatics in Control, Automation and Robotics

248

attributes of the variable data. The publication is han-

dled by the instance of the class Ros[NodeName] at

the return of this update method. The parameter con-

ﬁg contains all the application parameters (from the

parameter server, or handled through dynamic recon-

ﬁgure). This way, in a classical publisher / subscriber

scheme, this update function provides to the Devel-

oper all needed input to prepare the output.

The Developer’s contributions are only expected

within the ﬁle [node name] common.cpp, in locations

speciﬁed with the user contribution tag. The Devel-

oper may still update the code elsewhere but the up-

date mechanism will not keep these changes then.

In the ﬁle [node name] common.cpp, the class

[NodeName]Passthrough gathers components vio-

lating the interface / implementation separation

paradigm. We deﬁne in it all interface components

that may be directly accessed from the Developer’s

side. Furthermore, in the [NodeName]Data class, all

input messages are associated with a boolean ﬂag in-

dicating whether the data has been updated since last

update call. The Developer can use such information

for the preparation of the output material. Similarly,

a boolean ﬂag is associated to all output messages, so

that the Developer can inform whether it is necessary

to publish any data after the update completion.

An extensive documentation ﬁle template is pro-

vided, to get a complete description of all the commu-

nication means provided by each node. It is automat-

ically generated from the XML description ﬁle, and

speciﬁc user contribution areas are prepared to enable

the Developer extending the information.

Finally the ROS ﬁles related to the build opera-

tion, package.xml and CMakelists.txt, are also con-

templated in the package template, and automatically

ﬁlled from the XML description. A package freshly

created is thus already ready to be built, without mod-

ifying any of the generated ﬁles.

4.2 Lessons Learned

We are using the package generator in several running

projects. In Python for example the code generated

can represent around 80% of the total node code, and

a quite complete interface description is directly ex-

tracted from the XML speciﬁcation.

The proposed templates are usually sufﬁcient to

handle most of the packages needs, but we also gen-

erated more dedicated templates to better represent

some speciﬁc models, such as pure service or action

nodes, pure messages and services deﬁnition pack-

ages, ﬁlter nodes, ... We usually start with the default

template and then decide whether the adaptations we

feel necessary should be added to the default model

or are worth the creation of a new template.

The update mechanism has also shown to be ef-

ﬁcient for updating already created packages after an

adjustment of the template itself. This occurred for in-

stance when we inserted the ﬂags for signalizing the

update of input messages or for signaling if output

messages should be published. All packages created

before could be directly upgraded with such function-

ality by re-executing the package generator.

The capability of deﬁning ad-hoc interface at-

tributes has also enabled to characterize and formal-

ize different communication models. For instance, in

several projects we have seen that waiting the update

period for processing or publishing messages may be

restrictive. We have thus decided to implement a ded-

icated interface, named directPublisher and directSub-

scriber. These message communication managers are

regular ROS publishers and providers that are han-

dled out of the update mechanism (within class [Node-

Name]Passthrough), for speciﬁc interactions that can-

not wait for an update cycle.

Finally we observed that when using such tem-

plate mechanism, the Developer has to think of the

component he wants to create before starting imple-

menting it. Which template and related life-cycle best

ﬁts to a given task? What is the targeted interface?

These questions have to be addressed yet from the

beginning, and the update mechanism always gives

a chance to adjust the decision initially taken.

4.3 Completion of Initial Objectives

We highlighted in Section 3.2 ﬁve objectives. The au-

tomatic code generation is deﬁnitely achieved. Once

the package generation is launched, the Developer

only has then to insert the node logic. All the ROS

connectivity is automatically generated. There is a

signiﬁcant improvement with respect to the standard

catkin create package command.

The generation of the node life cycle, the node

interface, as well as the node creation based on the

interface is effectively happening with the package

templates we provide. We also explicitly separate the

ROS interface and node cycle from the node intelli-

gence by placing them within different ﬁles.

Nevertheless, the completion of these objectives

totally relies on the template provided by the De-

signer. On one hand we can argue that the Designer

may then deﬁne a template that violates these objec-

tives. On the other hand, this gives total freedom to

the Designer for deﬁning the template that matches

exactly the need of his team.

The possibility of deﬁning new templates is also

demonstrated as we already propose two differ-

Towards an Advanced ROS Package Generator

249

ent templates for two different languages, C++ and

Python. The Designer can deﬁne not only his own

template, but also the interface itself, with the related

tags and attributes the Developer should use in the

XML ﬁle.

With respect to the last objective, keep it simple, it

is achieved on the Developer side considering the lim-

ited information requested to trigger the code genera-

tion: the appropriate template, and the targeted node

interface. The Template Designer may have a more

complex job, for deﬁning the appropriate template.

Nevertheless this has to be counterbalanced with the

saved time by reducing the effort needed for code

maintenance, refactoring etc., that is likely to happen

otherwise, even if the team has a code policy.

To ﬁnish, we consider the possibility to change

the generated code as a positive point. The generated

code is not using advanced meta model that may be

complex for the Developer to tweak if the situation

requires it. Our generated code can still be changed

by the Developer, even though this is not preferable.

5 CONCLUSIONS

We described a ROS package generator that generates

complete package and node code based on a given

template and a simple XML description of the desired

interface. This tool is not restricted to a unique pack-

age template, and Designers have the possibility to

implement new templates. The template creation is

relatively simple, and uses instructions automatically

adjusted to the template characteristics. Also we pro-

vide an update mechanism so that a Developer can

adjust or extend the proposed interface, without loos-

ing the node logic previously introduced.

Several extensions are envisioned to enhance the

capabilities of the package generator. One of them is

to enable the generation of other ROS components.

Currently only ROS nodes are created, which is en-

forced by the use of the special tag node in the XML

dictionary. By enabling other types of tags, we be-

lieve the code generator could easily be extended to

other structures, such as ROS controllers.

The code generator started with a simple but efﬁ-

cient in-house templating language derived from the

interface parameters. We are strongly considering

more mature code generator tools, such as Jinja, that

would give access to more complex code generation

scheme in the package templates.

We are also considering migrating the generation

layer, currently at the level of the package, to a lower

layer, at node level, or more generally speaking at

component level. That would enable mixing different

templates in a given ROS package, like for example a

ROS node in C++, another one in Python . . .

It would be interesting porting the package gen-

erator to ROS2. The package code is almost pure

Python, using quite limited ROS functionality. Such

migration should be quite straightforward.

Finally, it would be an added value to provide re-

lated plugins for some code editors. This would help

the writing of the package conﬁguration ﬁle, provid-

ing appropriate text completion to the Developer.

ACKNOWLEDGEMENTS

Supported by the Elkartek MALGUROB and the

ROSIN project under the European Union’s Horizon

2020 research & innovation programme, grant agree-

ment No. 732287. The authors would like to thank

Dr. Andrzej Wasowski for the helpful suggestions re-

garding the structure and contents of this article.

REFERENCES

Bezzo, N., Park, J., King, A., Gebhard, P., Ivanov, R., and

Lee, I. (2014). Demo abstract: ROSLab — A modular

programming environment for robotic applications. In

ACM/IEEE ICCPS, pages 214–214, Berlin, Germany.

Bischoff, R., Guhl, T., Prassler, E., Nowak, W., Kraet-

zschmar, G., Bruyninckx, H., Soetens, P., Haegele,

M., Pott, A., Breedveld, P., Broenink, J., Brugali, D.,

and Tomatis, N. (2010). BRICS - Best practice in

robotics. In ISR / ROBOTIK, pages 1–8.

Brugali, D. and Shakhimardanov, A. (2010). Component-

Based Robotic Engineering (Part II). IEEE Robotics

Automation Magazine, 17(1):100–112.

Bubeck, A., Weisshardt, F., and Verl, A. (2014). BRIDE - A

toolchain for framework-independent development of

industrial service robot applications. In ISR/Robotik,

pages 1–6, Munich, Germany.

Kumar, P. S., Emﬁnger, W., Karsai, G., Watkins, D., Gasser,

B., and Anilkumar, A. (2016). ROSMOD: A Toolsuite

for Modeling, Generating, Deploying, and Managing

Distributed Real-time Component-based Software us-

ing ROS. Electronics, 5(3).

Meng, W., Park, J., Sokolsky, O., Weirich, S., and Lee, I.

(2015). Veriﬁed ROS-Based Deployment of Platform-

Independent Control Systems. In NASA Formal Meth-

ods, volume 9058, pages 248–262.

Quigley, M., Conley, K., Gerkey, B., Faust, J., Foote, T.,

Leibs, J., Wheeler, R., and Ng, A. (2009). ROS: an

open-source Robot Operating System. In ICRA Work-

shop on Open Source Software.

ROS (2018). ROS2 overview - Managed Nodes. https://

index.ros.org/doc/ros2/Managed-Nodes/. Ac-

cessed: 2018-11-22.

ICINCO 2019 - 16th International Conference on Informatics in Control, Automation and Robotics

250