Nodelet namespacing issues

[stonier]

Test catkin package: https://github.com/stonier/ros_testing

Namespacing for public and private is broken in a particular configuration: https://github.com/stonier/ros_testing/blob/master/namespaced_manager.launch

The results of that launch file put public and private topics in quite disparate places:

/dude/private
/family/public

where it should probably be

/dude/private
/public

I have three other namespace variations there, all of which behave as expected.

• https://github.com/stonier/ros_testing/blob/master/direct.launch
• https://github.com/stonier/ros_testing/blob/master/namespaced_everything.launch
• https://github.com/stonier/ros_testing/blob/master/namespaced_differently.launch

Seems to be only a problem if the nodelet's parent namespace is the root, '/'.

[progtologist]

This is a really important issue that has not received any attention since 2013! The problem itself roots to the NodeHandle constructor API, which apparently has no real global namespace constructor. I have made a minor change in roscpp and issue a pull request, though I doubt it will be integrated anytime soon.

[tfoote]

@progtologist Can you link to your pull request here so we can review it?

[progtologist]

@tfoote I postponed the PR because I found a minor unresolved issue while testing it. I will work on it in the next days and link the PR here once I have tested it extensively.

[progtologist]

@tfoote I have created a PR here (#37) that unit tests the nodehandles. I tried to trace it back in roscpp but I got lost at some point (debugging with nodelets and launchfiles is not that trivial for me).

As you can see, one of the tests is failing. The problem is that, when the NodeHandle constructor receives a NodeHandle with the namespace "/", it tries to resolve this, instead of assuming it is a global nodehandle.

Also, this raises the question, whether there is actlually a global nodehandle. since, in my point of view, the global nodehandle is actually a namespaced nodehandle.

[tfoote]

@progtologist Thanks for the unit tests. That will be very helpful for tracking this down. I haven't looked into the full details, but based on what you've described it, I would have expected the '/' to resolve immediately to itself.