[ros-users] questions about nodelets

[Jack O'Quin]

On Tue, Nov 9, 2010 at 5:10 PM, Daniel Stonier <d.stonier at gmail.com> wrote:
> I think Josh answered some of your more nodelet related questions, so
> I'll just respond to your roslaunch queries since I've been running
> similar scenarios (1 nodelet manager, about 10 nodelets loading into
> it).

>> I guess a "nodelet load" command sometimes arrives before the "nodelet
>> manager" is ready. Since roslaunch makes no guarantees about order, I
>> wonder how to solve it. I see no similar problems when dealing with
>> the node-based versions of these programs.
>
> No prioritised sequencing in roslaunch causes me a headache too,
> though I've never had a situation when the nodelet manager didn't
> launch before all my nodelets (I guess because its first in line in my
> launcher).
>
> I do have other sequencing problems though and the only way around it
> for now that I know of is to have multiple stage launchers. That
> starts getting pretty messy though. It would be more efficient and
> simpler if we had a mechanism in roslaunch for this.

I think the onInit() bug Josh pointed out (not returning immediately
in the driver) is the main cause of my problems. If the wrong nodelet
gets loaded first, it probably hangs some nodelet manager thread,
preventing the other from being instantiated.

>> Shutting down this nodelet manager process has also been unreliable.
>> Sometimes the threads with go away with ^C (INTERRUPT), but they often
>> hang and require a ^\ (TERMINATE). This may also be an issue with the
>> order in which the signals get delivered and processed. Shutting down
>> the node-based version works reliably.
>
> That one's actually not a critical bug, but its a bit annoying having
> to wait around for the terminate to arrive. Problem is the nodelets
> try and unload themselves on completion, but oft times roslaunch has
> killed off the manager, so they can't communicate. You can fix it by
> hacking the nodelet source nodelet/src/nodelet.cpp. Cturtle and latest
> have similar code (last time I checked), and down near the end in main
> there's a block of code that looks like: [...]

Thanks for the hint. That patch does sound like it should be reported.

I'll have to see what the effect of the onInit() change is before I
know what to do next. While testing today with the live device, a
couple of times the driver did not shut down at all. We had to do a
killall -9 nodelet to clean it up.
-- 
 joq