Ask Your Question
0

Loading nodelets built in different machines to a single manager

asked 2019-03-08 05:05:05 -0500

jgallostra gravatar image

updated 2019-03-08 11:35:01 -0500

Hi, I'm working on a project with Ubuntu 16.04 and kinetic where I have two catkin workspaces: one for building the iai_kinect2 package for handling KinectOne data reading, and another for building my own packages for image processing. I used to build them separately and run them in different docker containers, whereas roscore is running in the host PC. In this fashion, each container sources its own setup.bash file, so the iai_kinect2 nodelets cannot find the libraries for launching my own nodelets, which have been built in another container.

I am wondering if there is a way of launching nodelets from different dockercontainers / machines onto the same manager without having to source the bash file of each build in the host machine.

Right now I have placed both packages in the same container as a workaround, but I would like to be able to separate them as the project I work on requires different libraries for different packages, therefore using several docker containers to launch the nodes from each package.

edit retag flag offensive close merge delete

2 Answers

Sort by ยป oldest newest most voted
0

answered 2019-03-11 04:00:01 -0500

jgallostra gravatar image

As commented by @gvdhoorn:

Nodelets are stored on disk as shared libraries. If the manager process cannot access the shared library, it cannot load the nodelet.

In this particular case, what could work is clever mounting of directories from the ROS workspace containing the nodelets into the container that wants to load them (don't forget the metadata that is also need, ie: package.xml). But depending on what those nodelets exactly do this may not work, as all the dependencies of those nodelets would also need to be accessible.

This issue has to do more with "dependency hell" rather than nodelets. If workspace A needs a certain set of dependencies, and workspace B needs another incompatible set of dependencies, using artefacts from workspace A in processes from workspace B is not going to work.

edit flag offensive delete link more

Comments

Btw, should I close the question now that it has been answered?

jgallostra gravatar imagejgallostra ( 2019-03-11 05:12:41 -0500 )edit

No. Just mark it as answered by clicking the checkmark.

gvdhoorn gravatar imagegvdhoorn ( 2019-03-11 07:12:57 -0500 )edit
0

answered 2019-03-08 10:03:42 -0500

Wolf gravatar image

Yes, launching nodelets from different packages is possible. You must not even have them in the same launch file.

For instance, looking at the example launch file given here:

http://wiki.ros.org/nodelet/Tutorials...

You can place the part for the manager

 <node pkg="nodelet" type="nodelet" name="standalone_nodelet"  args="manager"/>

and multiple nodelets

  <node pkg="nodelet" type="nodelet" name="Plus"
        args="load nodelet_tutorial_math/Plus standalone_nodelet">
    <remap from="/Plus/out" to="remapped_output"/>
  </node>

into different launch files in different packages. All they have to share is the name of the nodelet manager ("standalone_nodelet") in the above example. Only you have to launch the launchfile with the manager first.

Have in mind, that nodelets will run in the same process, i.e., you have to launch all of the separable launches on the same (virtual) machine.

edit flag offensive delete link more

Comments

Maybe I didn't explain myself properly: I wasn't referring to different packages but different machines (I tried to refer to that when I wrote "different workspaces"). I have edited the question to clarify this.

jgallostra gravatar imagejgallostra ( 2019-03-08 10:14:19 -0500 )edit

Was only thought as hint. The answer applied anyway. If the later launch files can find the nodelet_manager via rosgraph you only have to pass the name of the manager, i.e., "standalone_nodelet".

Wolf gravatar imageWolf ( 2019-03-08 10:31:29 -0500 )edit

Hmmm okay, I'll try again on monday, but I'm pretty sure that even passing the correct manager name to the launchfile in the container, if the host machine cannot find the lib files of the nodelets, then the manager complains about being unable to load the nodelets.

Btw, @Wolf, thanks for your time and help!

jgallostra gravatar imagejgallostra ( 2019-03-08 10:35:55 -0500 )edit

Nodelets are stored on disk as shared libraries. If the manager process cannot access the shared library, it cannot load the nodelet.

@jgallostra: what could work is clever mounting of directories from the ROS workspace containing the nodelets into the container that wants to load them (don't forget the metadata that is also need, ie: package.xml). But depending on what those nodelets exactly do this may not work, as all the dependencies of those nodelets would also need to be accessible.

Re-reading your question, I believe the issue is not so much with nodelets, but with "dependency hell". If workspace A needs a certain set of dependencies, and workspace B needs another incompatible set of dependencies, using artefacts from workspace A in processes from workspace B is not going to work.

gvdhoorn gravatar imagegvdhoorn ( 2019-03-08 10:52:03 -0500 )edit

@gvdhoorn thanks for the explanation. Marking answer as correct.

jgallostra gravatar imagejgallostra ( 2019-03-08 11:20:18 -0500 )edit

How is this answer correct? You ask how to load nodelets from different workspaces without having those different workspaces active at the same time. The post by @Wolf ignores the different workspaces aspect and doesn't deal with binary incompatibility.

gvdhoorn gravatar imagegvdhoorn ( 2019-03-08 13:41:06 -0500 )edit

Yes, indeed, sorry. I'm quite new to the forum so I'm still learning but thanks. I guess the new answer could be marked as correct.

jgallostra gravatar imagejgallostra ( 2019-03-11 04:01:20 -0500 )edit

Just for the record if anyone finds this via google: I just checked again that having nodelets in different workspaces is absolutely no trouble, as long as the shell of the nodelet_manager has sourced the setup.bash of both workspaces. Though, while rereading your question I noted, that I missed the phrase where you said that sourcing the setup.bash is particularly what you wanted to avoid.

Wolf gravatar imageWolf ( 2019-03-11 15:57:24 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

2 followers

Stats

Asked: 2019-03-08 05:05:05 -0500

Seen: 127 times

Last updated: Mar 11