Announcing a ROS package generator

General
1

Hello ROS Community,

I would like to share the ROS package generator that we developed at Tecnalia during the ROSIN project.

The ROS package generator is a template-based generator that, given the current templates, can create automatically complete ROS packages (and not only the traditional CMakeLists.txt and package.xml).

The developer only has to define in an XML file the desired ROS communication interface, and all the ROS layers are automatically created for you! You just need to focus on the core intelligence of your node, i.e. how to process incoming information to generate appropriate behaviour and outcoming interaction.

At start, a bit of time may be needed to capture the generated code structure, but once accepted, development of packages is significantly accelerated, as you can see in the demonstration video.

Templates are provided for cyclic nodes, pure service servers, pure messages/services definition packages, and pure testing packages. Main ones are declined for generating C++ and python packages. Templates are customizable, and you can even create yours, using the tools provided, or directly using jinja.

We think this development could be of interest to some of you. We would be also happy if you have any opinion on it, suggestion for template extension / adjustments …

Last thing: the templates are for ROS 1, although there is nothing that should prevent from creating templates for ROS 2 as well.

More information can be found on the github repository.

Thanks

Anthony, and the robotic team @ Tecnalia

10 Likes
2

If I understand what is going on correctly this looks pretty cool. From what I can gather this package uses an input XML file with some pre-defined node types. All the user does is specify the node types the message type names. From there the tooling will generate all of the source and message definition files, stub them out with code, and put them in the right place? Did I also see some message type inference in there too?

1 Like
3

Interesting project! The ability to declare a communication interface like you’re using here is something that we’re in the process of standardizing if you’d like to provide some input:

2 Likes
4

Thanks for your comment!
You are right, the templates define the interaction means they handle (like topic, services, action…), then the user sets in the XML file the interaction he needs, and its ROS type (like a service of type std_srvs/Trigger). Current template then prepare all code to define the interaction means, and prepare the functions in which the user should implement the logic he wants.

There is no type inference, strictly speaking. We just take advantage of the standardised way of defining message/service/action types, both in C++ and python.

5

Thanks @kyrofa for pointing me on the IDL.
I’ll have a look at it, definitely!

3 Likes