How to source binary packages from different places?

Question

Dear ROS Enthusiasts,

I have a problem sourcing binary packages from multiple install directories. These are the source commands I want to work with:

1. source /opt/ros/kinetic/setup.bash
2. source /opt/ros/other/setup.bash
3. source /home/my_user/install_dir/setup.bash
4. source /home/my_user/catkin_ws/devel/setup.bash

In /opt/ros/other I have the usb_cam package installed, which is still not available for kinetic. In /home/my_user/install_dir I have installed a binary version of a package, I programed myself. For some reasons, I don't want to provide the source of this package. The nodes of the package in the catkin workspace require the output of the binary package in /home/my_user/install_dir published in certain topics.

As long as I don't source my binary package in /home/my_user/install_dir, everything works well. Means, the source commands 1, 2, and 4 don't interfere each other and work well in combination. I have access to packets of the ROS installation and the usb_cam packet in my catkin workspace at the same time.

Unfortunately, the source commands 3 and 4 interfere with each other. Only the last of these two source commands is effective. As a result, I can't call all nodes in a single launch file and even worse I don't have access to the data types of my binary package in my catkin workspace.

Since source commands 1, 2, and 4 are working well together, sourcing binary packages from multiple places is possible. Since source command 3 does not source a workspace, I should not have an effect based on cascading workspaces, right? However, I don't see any differences between the usb_cam package and my binary package, which may result in the different behavior of source commands 2 and 3.

Thank you very much for your help.

---

Originally posted by CupcakeMuffin on ROS Answers with karma: 1 on 2017-05-28

Post score: 0

Answer 1

Look into catkin workspace overlaying.

In short: all your workspaces need to form a chain, with the 'lowest' workspace (or layer) your regular ROS install, then the next one (probably /opt/ros/other) and so on. That way package resolution will walk the chain, and should be able to find packages in no matter which workspace.

Two ways to do this:

• implicitly: make sure to source the setup.bash of the workspace you want to extend before running catkin_make (or catkin build) in the extending workspace
• explicitly: use catkin config --extend (from catkin_tools)

See also Workspace Mechanics - Workspace Chaining / Extending in the catkin_tools documentation.

There are ways to do things slightly differently, but I'm not sure that will be much more convenient. See #q64702 for a related question and some explanation by @William.

---

One possible explanation for your current situation is that instead of a single chain, you essentially have a tree with two leaves, with the split at workspace 2.

Resource resolution does not walk a tree, only a chain, so that could explain why 1, 2 and 3 are properly overlayed, and 1, 2 and 4, but not 1, 2, 3 and 4.

---

Originally posted by gvdhoorn with karma: 86574 on 2017-05-29

This answer was ACCEPTED on the original site

Post score: 0