Ask Your Question

source setup.bash in install space does not work when deployed onto different machine

asked 2017-03-21 03:02:15 -0500

takahashi gravatar image

updated 2017-03-21 16:23:20 -0500

I install my catkin workspace on machine A to a directory (e.g. /home/usera/catkin_ws/install) and would like to use it on machine B in a different location (let's say a different user home, e.g. /home/userb/catkin_ws/install). My setup uses another workspace in /opt/overlay/ that is overlayed.

Now, on machine A everything works fine, when I source the setup.bash (therefore I check the ROS_PACKAGE_PATH, which is /home/usera/catkin_ws/install/share:/opt/overlay/share:/opt/ros/kinetic/share). Unfortunately, on machine B, sourcing setup.bash does not work, the ROS_PACKAGE_PATH is /opt/overlay/share:/opt/ros/kinetic/share.

I have found the following ROS answers:

So apparently ROS uses absolute paths and I need to mirror the install location in machine A to machine B, in order to get the install space working on machine B.

So my questions are:

  • Is there a way to deploy the install space to machine B to a different location than on machine A (no location mirroring)?
  • If not, what is the advantage of having absolute paths? As this makes deployment of ROS binaries via an install space very cumbersome in my opinion.
edit retag flag offensive close merge delete


opt/overlay/share:/opt/ros/kinetic/share doesn't look right, why is there no leading / ? The install space should be relocatable, but the workspace it overlays needs to be on both machines (same as for binaries you built against). See:

William gravatar image William  ( 2017-03-21 13:19:31 -0500 )edit

sorry, that was a typo. it is /opt/overlay/share:/opt/ros/kinetic/share of course. corrected this in the original question. the overlaid workspace is the same on both machines. I will take a look at the issue and come back with more information. thanks!

takahashi gravatar image takahashi  ( 2017-03-21 16:22:51 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2017-03-22 03:29:06 -0500

takahashi gravatar image

I resolved the problem. When I deployed my install space from machine A to machine B, I created a folder (let's call it base) containing some shell scripts and the /home/usera/catkin_ws/install and zipped it:

base - home - usera - catkin_ws - install - ...

More specifically, I created the zip file like this:

mkdir base
cp --parents -r /home/usera/catkin_ws/install/* base
cp  base
zip -r base

Unzipping on machine B led to the problem I described.

However, if I create the zip file like this:

mkdir base
mkdir -p base/home/usera/catkin_ws
cp -r /home/usera/catkin_ws/install base/home/usera/catkin_ws
cp  base
zip -r base

and unzip it on machine B, I can source the base/home/usera/catkin_ws/install/setup.bash and the created ROS_PACKAGE_PATH is correct.

It seems like the --parents flag of the cp command changed something in my deployed install space, however I have no idea what it changed and how this could even happen. Anyway, I am very happy that I was able to resolve this and maybe someone knows the reason of this.

edit flag offensive delete link more

Your Answer

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

Add Answer

Question Tools



Asked: 2017-03-21 03:02:15 -0500

Seen: 400 times

Last updated: Mar 22 '17