Auto-generating ROS nodes from another node?
Hello,
I am trying to create a program that, when given parameters (such as topic name, msg type, subscriber/publisher specification, publishing freq, etc.) will be able to read the parameters and generate nodes.
http://wiki.ros.org/ROSNodeTutorialC%... Looking at this tutorial, it seems that it is possible to define a ROS Node template. So my question is, is it possible within a single process (in main) to autogenerate multiple nodes from the same template? Say, I create an array of "node_examples" as in the tutorial and just substitute different names and parameters to each of them and then run them simultaneously?
Thank you in advance!
While anything is possible (as long as you put sufficient effort and time into it), could you provide some context, describe your motivation?
Many of the "parameters" you mention sound like actual parameters (ie: ROS parameters), so they would not need to be part of a template, as any node can read them at runtime, during initialisation. It is even possible to create subscribers which can accept any message type. But whether that would be a smart thing to do in your case is unclear.
If you could clarify what you're trying to achieve (to avoid an xy-problem), perhaps we can offer a simpler solution than having to resort to code-generation.
@gvdhorn So, I am trying to create a "factory" to try and measure the performance of a ROS system, by measuring various parameters (such as latency, memory consumption) of the system as a whole (system is defined via a topology, which my program would then read and substitute the necessary parameters into the "factory"). I am inspired by this work https://github.com/irobot-ros/ros2-pe...
And would love to try and make something similar but for original ROS.
for this you could probably get away with remapping, which wouldn't need any code changes. Or specify the topology using actual ROS parameters (in a dict or list).
if you're not interested in measuring (de)serialisation performance (which would be independent of topology I believe), then generic subscribers would probably work. Or you could even just standardise on a standard message type, much like the repository you linked does. It just shuffles around an array of bytes in a ROS message. The message type doesn't change, only the size of the array.
Things like publication frequency, number of subscribers, etc would also not necessarily need code changes -- although remapping would probably become harder with ...(more)
Note: I'm not saying you shouldn't use code-generation.
But it will require more infrastructure and custom work than implementing a single, parameterisable node which reads its configuration from the ROS parameter server.
Perhaps you could ask iRobot why they decided to use code-generation in their case.
Btw: have you looked around for existing implementations of this idea in ROS 1? Seeing as ROS 1 has been around for more than 10 years now, I'd be surprised if this hasn't been done before.
I think you are right here, I should ask iRobot some of these questions. And I believe your idea of creating a parametrisable node makes also sense, I think it is simpler and for sure will do me well in the beginning. However, I would ask you - is it possible then to, say, create several ROS nodes in a code (say, an array of them with different parameters) and then launch them at once in a single process?
Answering your question about similar implementations - turns out not really! I have done extensive research and managed to found only this article along with the repo of the evaluation for ROS1, however, nothing as extensive as the mentioned repo. I believe there was never a drive to compare ROS1 to anything, but with emerging of ROS2 that utilizes completely new architectural choices this became a popular topic in academia and development?
I would probably not start nodes from other nodes, but generate a
.launchfile (using Python or something).Then starting the
.launchfile would be a standard affair..launchfiles support setting parameters, configuring remappings, starting nodes in namespaces, etc, etc.Thank you very much for the answers @gvdhoorn. All the best to you :)