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

Can you share a catkin workspace with precompiled packages?

asked 2016-08-29 13:33:26 -0500

lokus gravatar image

I'm giving a class about mobile robotics and i won't be able to install all the "external" dependencies required on the host classroom. I'm looking for a way to share a catkin workspace with pre-compiled nodes between the students.

I'm using catkin_tools and my main issue is that catkin generates symlinks that get corrupted when the workspace is moved around or renamed. For example: /devel/setup.bash links to: /home/specific_user/catkin_ws/devel/.private/catkin_tools_prebuild/setup.bash

¿Is there a way to re-generate all the symlinks and reset configuration without erasing compiled information?

edit retag flag offensive close merge delete


I don't think devel spaces are supposed to be relocatable, or shareable. install spaces however should be shareable, provided you put them in the same relative location on the other machines.

Do your students need access to the source code of your pre-compiled nodes?

gvdhoorn gravatar image gvdhoorn  ( 2016-08-29 15:10:20 -0500 )edit

They only need to "fill" a portion of code in one node. I could share a workspace with some pre-installed packages and provide a install() directive on the CMake for the "exercise" package. They should be able to install & compile only the "exercise" package, source install space and have fun right?

lokus gravatar image lokus  ( 2016-08-29 16:06:45 -0500 )edit

I would only use an install space for your 'base' packages (ie: those you want to precompile and distribute). I would make students create their own workspace, that extends your base workspace. That would keep things nicely separated. See my answer for some more detail.

gvdhoorn gravatar image gvdhoorn  ( 2016-08-30 02:13:06 -0500 )edit

1 Answer

Sort by » oldest newest most voted

answered 2016-08-30 02:07:07 -0500

gvdhoorn gravatar image

updated 2016-08-30 02:11:57 -0500

From your comment I think the following approach would work:

  1. setup a 'base' workspace that includes all the packages that are needed for the functioning of your complete application, but that are not part of the exercises (ie: your students don't need to / are not expected to change anything in those packages)
  2. build that workspace on a single machine (while making sure that the machines the students use are 'similar enough', ie: have a compatible runtime system), and install it to the install space of the catkin workspace
  3. create a tarball of the install space
  4. copy that tarball to all the other machines, extract it there, making sure the install space ends up in the same relative location. So if it was in /home/some_user/ros/catkin_ws/install, it should be in /home/some_user/ros/catkin_ws/install on the student machines.

    Note that the install space doesn't need to be in your home directory at all, it can be placed anywhere (fi: /opt/base_ws or /usr/local/base_ws (or something similar)). The location can be configured using catkin config --install-space ... But you have to make sure to put the workspace in the same location on the students' machines.

Only thing left now is to create a new workspace (the 'exercise' or 'student' workspace), that extends the base workspace on all the student machines, and to place just the exercise package(s) in it. Whenever students build that workspace, only the packages in the overlayed workspace will be built, not those in the 'base' workspace.

Personally, I would use a VCS to distribute the exercise package(s), create a .rosinstall file (pointing to the (git) repositories containing the packages) and have students use wstool merge <url to rosinstall file> to setup their own workspaces.

Edit: if you would be willing to spend the effort, and / or need to scale this up, you could even think about creating debian packages or RPMs for your base packages, and distribute those in some way. But that could be quite some work (depending on any other infrastructure you might already have).

Note that you can also create a .deb from your install space using fpm. It wouldn't be a really proper debian package, but it would perhaps be easier to distribute than an unversioned tarball.

edit flag offensive delete link more

Question Tools



Asked: 2016-08-29 13:33:26 -0500

Seen: 586 times

Last updated: Aug 30 '16