ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
2

Catkin fails to chain workspaces [closed]

asked 2014-08-19 07:14:49 -0500

Marcel Usai gravatar image

updated 2014-08-19 16:09:03 -0500

Hi guys, I have a problem and cannot find a permanent solution to it:

I am trying to chain two workspaces A and B but catkin fails to recognize workspace A. So what i did was create worspace A in:

/usr/share/ros/workspaceA

This works fine and i can build my packages. Then i created another workspace B to work in, this should overlay workspace A, in:

~/ros/workspaceB

My packages in workspaceB depend on packages in workspace A. When trying

source /usr/share/ros/workspaceA/devel/setup.bash
source ~/ros/workspaceB/devel/setup.bash
cd ~/ros/workspaceB/
catkin_make

I get

...
-- This workspace overlays: ~/ros/workspaceB/devel;/opt/ros/indigo
...

and following some error that my package from workspaceA ould not be found. So obviously, catkin fails to recognize workspaceA. Without dependencies on packages from workspaceA everything works fine.

How do I get this fixed, so that i can build my packages in workspaceB? What am I missing? Has this to do with the path to workspaceA?

Note: This worked for me once, when workspaceA was located in

~/ros/workspaceA

but after deleting it and recreating in in just the same place i got the same result as above.

Thanks for your support!

edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by Marcel Usai
close date 2014-09-04 02:40:10.958702

Comments

This has a way nicer solution with catkin tools . See http://answers.ros.org/question/64702... .

peci1 gravatar image peci1  ( 2016-11-16 09:04:44 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted
6

answered 2014-08-19 13:13:20 -0500

dornhege gravatar image

The problem is the assumption that sourcing chains workspaces. This is not the case. If it were sourcing multiple setup.sh files will leave you in an undefined state depending on whatever you did before. Here is your problem:

source /usr/share/ros/workspaceA/devel/setup.bash
source ~/ros/workspaceB/devel/setup.bash
cd ~/ros/workspaceB/
catkin_make

This activates workspaceB before building. Thus you do not overlay workspaceA. Check out the tutorial on chaining workspaces. Note the lines along:

## THIS IS THE CRUCIAL PART FOR OVERLAYING
$ source ~/overlay_ws/devel/setup.bash
$ catkin_make

You probably at some point sourced workspaceA and catkin_make in workspaceB leading to this:

-- This workspace overlays: ~/ros/workspaceB/devel;/usr/share/ros/workspaceA/devel;~/ros/workspaceB/devel;/opt/ros/indigo

Try removing the build/devel folders in workspaceB and then:

source /usr/share/ros/workspaceA/devel/setup.bash
cd ~/ros/workspaceB/
catkin_make
source ~/ros/workspaceB/devel/setup.bash

This should lead to the setup you want. From now on it is sufficient to source ~/ros/workspaceB/devel/setup.bash in your .bashrc. This will lead to the correct overlays.

edit flag offensive delete link more

Comments

Thank you. Think I messed things up trying to understand chaining workspaces. Just edited my question to remove the last (misleading) edit.

So one could say that it's always building before sourcing?

Marcel Usai gravatar image Marcel Usai  ( 2014-08-19 16:03:22 -0500 )edit
1

That depends. Build your current workspace before sourcing it, but source other (underlaid) workspaces (which were already built at some point) before building the current one (otherwise, workspaces will not be chained).

Murilo F. M. gravatar image Murilo F. M.  ( 2014-08-19 16:38:18 -0500 )edit
3

answered 2014-08-19 12:40:56 -0500

Murilo F. M. gravatar image

Sourcing in the correct order does not actually guarantee workspaces will be chained correctly, and the ROS_PACKAGE_PATH may have repeated entries (as described in the question). The details can be found here. This link also describes the limitations in chaining catkin workspaces.

It is all down to which ROS installation and user workspace(s) were already sourced at the time the new workspace was created.

To illustrate that, suppose the .bashrc file is only sourcing my hydro (or indigo) installation:

source /opt/ros/hydro/setup.bash

We can check the environment variable:

$ echo $ROS_PACKAGE_PATH
/opt/ros/hydro/share:/opt/ros/hydro/stacks

Then, in terminal #1 we create a workspace named A, build and source it:

$ mkdir -p ~/A/src
$ cd ~/A/src
$ catkin_init_workspace
...
$ cd ../
$ catkin_make
...
$ source devel/setup.bash

If we check the environment variable again:

$ echo $ROS_PACKAGE_PATH
/home/user/temp/A/src:/opt/ros/hydro/share:/opt/ros/hydro/stacks

In (a new) terminal #2, we create another workspace, named B (remember, only the system-wide ROS installation is being sourced in my .bashrc). After building and sourcing it in terminal #2, if we check the env. variable in this case:

$ echo $ROS_PACKAGE_PATH
/home/user/temp/B/src:/opt/ros/hydro/share:/opt/ros/hydro/stacks

So far so good. Let us now add the necessary lines to the .bashrc file in order to source workspaces A and B:

source /opt/ros/hydro/setup.bash
source /home/user/temp/A/devel/setup.bash
source /home/user/temp/B/devel/setup.bash

Again, in (a new) terminal #3, if we check the env. variable:

$ echo $ROS_PACKAGE_PATH
/home/user/temp/B/src:/opt/ros/hydro/share:/opt/ros/hydro/stacks

Only workspace B (as well as the system-wide installation) was sourced. This shows that sourcing in the correct order does not imply in chaining workspaces correctly (as documented in the link above).

Now, back to terminal #1, where workspace A is properly sourced, let us create workspace C, build and source it. Then, let us check the environment variable:

$ echo $ROS_PACKAGE_PATH
/home/user/temp/C/src:/home/user/temp/A/src:/opt/ros/hydro/share:/opt/ros/hydro/stacks

This time, workspace C was correctly chained with workspace A, and the reason for that to have worked as expected is because workspace A was already sourced in terminal #1, which was not the case in terminal #2.

To be more pedantic with my explanation, if one tried the sequence of commands above and ran a diff (say, using meld) between the automatically generated files /home/user/temp/A/devel/_setup_util.py, /home/user/temp/B/devel/_setup_util.py and /home/user/temp/C/devel/_setup_util.py, one would find that those files from workspaces A and B are identical, whilst in the file referring to workspace C, line 255, the CMAKE_PREFIX_PATH variable would include /home/user/temp/A/devel, because workspace A was already sourced.

I hope this helps others to avoid having the issues I had in the past.

edit flag offensive delete link more

Comments

Thank you for your answer, it just helped me understanding the concept of overlaying workspaces.

Marcel Usai gravatar image Marcel Usai  ( 2014-08-19 16:14:33 -0500 )edit

Thanks for pointing out where to edit the CMAKE_PREFX_PATH. It becomes much easier for me to chain or unchain the workspaces. Thx.

tianb03 gravatar image tianb03  ( 2014-11-11 05:26:55 -0500 )edit

Question Tools

3 followers

Stats

Asked: 2014-08-19 05:27:18 -0500

Seen: 932 times

Last updated: Aug 19 '14