After a bit of hacking around I think I found a solution, at least for
now. Instead of doing the waitForService and service call in the
onInit method of my nodelets (where it can block), I set up a one-shot
timer which invokes a method that does the same thing. It also seems
that upping the num_worker_threads parameter of the nodelet manager
was required as well. In my case things start working as expected when
I set it to 5 or higher (reliably, anyway--at lower numbers it might
sometimes work, and I think that has to do with the unpredictable
order of startup--if the 'client' nodelets grab all the threads first,
then the 'server' nodelet is waiting forever for a thread on which to
advertise its service). I'm loading a total of 6 nodelets for the time
being but only 5 of them would be involved in the startup blocking
problem, so I think this makes sense.

Would it then be a good rule of thumb to set num_worker_threads to at
least the number of nodelets being loaded into a manager? Is there a
large performance penalty for having too many worker threads?

Pat

On Wed, Dec 1, 2010 at 12:54 PM, Patrick Bouffard
<bouffard@eecs.berkeley.edu> wrote:
> I'm trying to consolidate a number of separate nodes into a single
> process using nodelets. I think I worked out the changes necessary to
> go from ordinary nodes to nodelets that can be run standalone. But
> when I try to take those same nodelets and load them all into a
> nodelet manager, things start to break. I think this might have
> something to do with threading/callback queues or something to that
> effect.
>
> One of the things that my node(let)s do at startup is to wait for a
> service to be advertised. The node that advertises that service is now
> one of the nodelets, and I notice that when I load the nodelets that
> are the service clients into the nodelet manager, the service doesn't
> ever seem to start. I suspect this might be because when I call
> ros::service::waitForService(), it's blocking all of the nodelets,
> including the one that would be advertising the service--does that
> make sense? What is the Right Thing to do here to get the illusion of
> having multiple nodes but with them running in the same process to
> take advantage of zero-copy message passing etc.?
>
> Initially I thought perhaps I just need to add ros::spin() in the
> onInit method in each nodelet, but I saw in another thread (no pun
> intended :-) that this is not correct. I'm guessing the answer lies in
> threading but I'm not quite sure where to start. Is there anywhere in
> the ROS ecosystem a package that has a similar structure to what I'm
> trying to do, that I could look at as an example?
>
> Also, I'm wondering what the distinction between ROS_INFO and
> NODELET_INFO is; should I always be using the latter in nodelets?
>
> Thanks,
> Pat
>