ROS 2 nodes created inside libraries, good practice?
In porting stuff to ROS2, I'm often faced with the problem of what to do with calls to the ROS api that are deep inside libraries. In ROS1, since a node and process when one to one, you could always make a new NodeHandle and wait for a message, call a service, etc anywhere you want.
You can largely do the same thing in ROS2 by creating (and destroying) a new rclcpp::Node on-the-fly in your library and then running a separate executor to get callbacks processed. Is this a good idea? Assuming it isn't doing this in a tight loop, is it likely to cause conflicts or other issues? Does it make sense to architect systems with ephemeral nodes?
Asked by jdlangs on 2021-12-14 15:38:06 UTC
Comments
I can't speak to whether or not this is good architecture, but my hunch is that this is a good option for very infrequent ROS API calls only - how would you be using the API if I may ask?
Asked by aprotyas on 2021-12-23 01:04:25 UTC
It could vary, so I'm interested in what factors to make the decision on. On one end, it might be something like an object that stays alive the whole time and manages it's own publishers/subscribers. On the other end, it could be simply subscribing and obtaining a single message or doing a single service call.
Asked by jdlangs on 2022-01-03 11:46:15 UTC
Apologies for the late reply - but I think this page touches on this topic a little bit. https://docs.ros.org/en/galactic/Concepts/About-Composition.html
Asked by aprotyas on 2022-02-27 03:50:46 UTC