On 12/04/2010 12:36 PM, Nicholas Butko wrote:
> On Dec 4, 2010, at 12:14 PM, Radu Bogdan Rusu wrote:
>> On 12/04/2010 12:12 PM, Nicholas Butko wrote:
>>> Then, is there any advantage to creating nodes as nodes instead of nodelets?
>>
>> Sure. If a nodelet dies, the entire process might die. Nodes are more "robust", as you can restart/respawn them individually.
>
> Could you achieve the same behavior by having a separate nodelet manager for each nodelet? For example, would it be easy to write a shell script that starts a uniquely named nodelet manager and assigns a single nodelet to it? Call such a script "rosrun_nodelet" for example. Then you could run a single piece of code as a nodelet or a node.
Yup, but with multiple nodelet managers, you're essentially running multiple nodes. Though, you're right -- things are
better as you can put several nodelets inside a manager.
> I am thinking of transferring a bunch of my nodes to nodelets, and I guess I want to know what people at WG are finding "best practices" are. Do you find yourself coding every new node as a nodelet, or only when it's absolutely necessary? Are there any good strategies for hybrid nodes/lets? How easy is it to write a main function that "runs" a nodelet as a node?
In general, nodelets should not be abused. If the performance of nodes (copy/(de)serialization) is really what's
dragging your processing graph down, then sure, nodelets are offering a viable alternative. However, this should really
be profiled first for each application.
Cheers,
Radu.
--
http://pointclouds.org
(text/plain)