Summary

What if you could avoid writing nodes from scratch every time you create a package? What if you could just create a new node by defining its interface and then have all the ROS communication primitives automatically created for you, so that you can focus on the core logic of your component? What if you could still update your interface once you have created your node? What if you could even create your own package and node template, so that you could create nodes that exactly fit your needs? Well that´s what the ROS package generator proposes!

https://github.com/tecnalia-advancedmanufacturing-robotics/ros_pkg_gen

Extended description

The objective of this package is double. On one side, it enables a ROS user, hereafter called Developer, to create a package and its nodes automatically from the definition of the nodes interfaces. On the other side, it enables advanced users or Designers to define package and node templates, based on their expertise, requirements and best practices, so that Developers can reuse these templates to generate new packages and nodes following that model automatically.

The available templates are designed to make a clear separation in between (i) the node interface implementation and management (based on ROS communication primitives, such as topic, services, actions, parameters….) and (ii) the node´s core logic that processes input received to generate the appropriate output. In addition, the node pattern handles the node life-cycle (which in the current patterns consists of a cyclic process of the input messages for generating the messages to publish, while the other communication primitives are handled on demand).

After selecting an appropriate package template, the Developer has to define the specific ROS interface used by each node in a XML file. Based on that definition, the selected package and node template pattern is processed to generate an instance that fits to the interface and specification provided by the Developer. Once his package is generated, the Developer only has to focus on the node logic, the real added value of his work. By introducing his contribution into well-defined areas in the files, the Developer still has the possibility to update the node interface once created. All Developer contributions written in these specific locations are maintained during the package and node updates.

This work is not the first attempt to propose a ROS package generator, the BRIDE tool from the European projects BRICS, the ROSMODE frameworks from the Vanderbilt University, or ROSLab from the University of Pennsylvania are other examples of works in that directions. Although these works sound promising, we could highlight some disadvantages. In some of these works, like ROSLab and BRIDE, the node pattern is strongly embedded into a complex modelling framework so that it is difficult to propose any variation of the package / node pattern. In other works, like ROSMODE, the advanced architecture proposed is even another modelling layer on the top of the basic ROS infrastructure, that requires not only to spend a significant time to understand it well, but also requires to adhere completely to the modelling decisions.

In our package generator, the package / node pattern is not enforced at all. We currently propose two patterns, one for Python nodes and another for C++ nodes, following a cyclic message processing and generation model. But the package generator is designed to accept new package / node patterns. This enables a template Designer to define the pattern that exactly matches his needs, constraints, preferences, etc., using very light markup on top of a template of the package that closely mirrors the generated output package. The developer can even restrict the type of ROS communication primitives to use, or include specific ones he created.

See also our short paper “Towards an Advanced ROS Package Generator” as presented on Wednesday, July 31st 2019 at the 16th International Conference on Informatics in Control Automation and Robotics (ICINCO 2019).