On Tue, Nov 9, 2010 at 5:30 PM, Jack O'Quin <jack.oquin@gmail.com> wrote:
> On Tue, Nov 9, 2010 at 5:10 PM, Daniel Stonier <d.stonier@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.

My startup problems were indeed fixed by running the device polling in
another thread, as Josh suggested.

>>> 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: [...]

> 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.

The multi-threaded version shuts down successfully, but usually with
some error messages. I have not observed that version hanging the
device yet, although it sometimes needs a TERMINATE signal to go away.

It's really hard to get all that stuff exactly right in a
multi-threaded plugin-based implementation.

Thanks for all the help!
-- 
 joq