Ask Your Question

Maintaining a ROS source install (add packages, update release).

asked 2013-12-12 02:54:06 -0500

demmeln gravatar image

updated 2014-01-22 14:50:39 -0500

This is a bit of a follow up on the answer to this questions:

So assuming I have build and installed ROS (e.g. the desktop-full variant), I'm woundering how to best maintain my installation, meaning adding additional packages (which on ubuntu I would install via apt-get) and updating the whole installation to current releases (staying on the same distro, hydro in my case).

Is it possible and recommended to install to the same install space (e.g. /opt/ros/hydro) from different workspaces? E.g. I would like to add additional packages like suggested in the answer linked above. Can I build them in a freshly created workspace and install to /opt/ros/hydro? Should I instead extend my workspace with which I build the original packages installed to /opt/ros/hydro?

How would I go about upgrading my packages to the latest releases? Can I use my existing workspace and update the .rosinstall file to the latest released versions? What is the best practice here?

edit retag flag offensive close merge delete


Noone? There must be a ton of people having pure source-installs, no?

demmeln gravatar image demmeln  ( 2013-12-15 23:46:24 -0500 )edit

2 Answers

Sort by ยป oldest newest most voted

answered 2013-12-16 09:06:40 -0500

William gravatar image

Given that you have a base ROS installed, lets say to ~/hydro/install, with the sources in ~/hydro/src, which was generated from a rosinstall_generator command like rosinstall_generator desktop_full --rosdistro hydro --deps --wet-only > hydro-desktop-full-wet.rosinstall. In order to update this install I would do the following:

$ mv hydro-desktop-full-wet.rosinstall hydro-desktop-full-wet.rosinstall.old
$ rosinstall_generator desktop_full --rosdistro hydro --deps --wet-only > hydro-desktop-full-wet.rosinstall
$ diff hydro-desktop-full-wet.rosinstall.old hydro-desktop-full-wet.rosinstall

On my machine I get something like this:

% diff hydro-desktop-full-wet.rosinstall.old hydro-desktop-full-wet.rosinstall
<     version: release/hydro/orocos_kdl/1.2.0-1
>     version: release/hydro/orocos_kdl/1.2.1-0
<     version: release/hydro/urdf_tutorial/0.2.1-0
>     version: release/hydro/urdf_tutorial/0.2.2-0
<     version: release/hydro/urdfdom/0.2.8-1
>     version: release/hydro/urdfdom/0.2.10-3

This tells me that those three packages have new versions, then you can use wstool to update your ~/hydro/src folder:

$ wstool merge -t src hydro-desktop-full-wet.rosinstall

     Change details of element (Use --merge-keep or --merge-replace to change):
  orocos_kdl,  urdf_tutorial,  urdfdom

Continue: (y)es, (n)o, (v)erbosity, (a)dvanced options: y
Config changed, maybe you need run wstool update to update SCM entries.
Overwriting /Users/william/hydro/src/.rosinstall

update complete.

The above command will have updated the .rosinstall file in the ~/hydro/src folder, grep shows me that orocos has indeed been updated:

% cat src/.rosinstall | grep orocos
- git: {local-name: orocos_kdl, uri: '',
    version: release/hydro/orocos_kdl/1.2.1-0}

At this point though, you have not updated the source code you have, to do this you must use wstool again:

% wstool up -t src

The above command will check each entry in the .rosinstall against the thing in the source folder. When it finds an inconsistency, it will ask your what you want to do:

Prepare updating <a href=""></a> (version release/hydro/catkin/0.5.77-0) to /Users/william/hydro/src/catkin
Url <a href=""></a> does not match <a href=""></a> requested.
  (d)elete and replace, (a)bort, (b)ackup and replace, (s)kip: s
Skipping install of catkin because: Url <a href=""></a> does not match <a href=""></a> requested.

I have a custom version of catkin which I do not want to update, so I'll skip that one. Packages which are new will be fetched, I had removed opencv2, so it re-fetched that:

[opencv2] Fetching <a href=""></a> (version release/hydro/opencv2/2.4.6-3) to /Users/william/hydro/src/opencv2

Finally it gets to orocos_kdl and updates it:

[orocos_kdl] Updating /Users/william/hydro/src/orocos_kdl
remote: Counting objects: 227, done.
remote: Compressing objects: 100 ...
edit flag offensive delete link more


Thanks for you extensive answer. This almost fully answers my question. With this update model it seems fine to keep extending the workspace of the "base install" with additional stable packages (which i would otherwise want to install from a package manager).

demmeln gravatar image demmeln  ( 2013-12-16 10:02:49 -0500 )edit

However can you comment on installing an overlay into the same install space as the underlay (= base install)? See the third paragraph of my question.

demmeln gravatar image demmeln  ( 2013-12-16 10:04:40 -0500 )edit

This should really be on the wiki and linked to from the source installation page.

jkolb gravatar image jkolb  ( 2014-01-22 06:10:10 -0500 )edit

@jkolb: agreed, can you put it there? :-P @William: any idea about reusing the underlays install space?

demmeln gravatar image demmeln  ( 2014-01-22 14:49:36 -0500 )edit

I've added another section to the wiki with these instructions:

ahendrix gravatar image ahendrix  ( 2014-01-24 11:50:38 -0500 )edit

Regarding installing an overlay into the install space of an underlay. Conventional wisdom says it works:

demmeln gravatar image demmeln  ( 2014-03-10 00:18:57 -0500 )edit

answered 2013-12-16 01:56:48 -0500

joq gravatar image

updated 2013-12-16 03:53:26 -0500

When managing a large workspace, it gets awkward having to rebuild massive amounts of code every time you change one of the CMakeLists.txt files. I don't do anything as large as your source setup, but this works reasonably well for me:

  1. Keep packages you are actively working on in a separate catkin workspace, overlaying to the main one.

  2. Use wstool update to bring the latest sources into a given workspace, then rebuild it.

UPDATE: When building things from source in a catkin workspace, I normally run from that workspace. I generally only make install to verify that all the necessary files are being copied before releasing a package to the build farm.

  • A command like wstool set robot_model --version-new robot_model-1.7.1 will change an existing checkout to a different branch or tag. If needed, do that before running wstool update.
edit flag offensive delete link more


Yes, that makes sense. I am more concerned about the standard packages that I do not want to hack. I.e. I have the base install, and want to add another stable package from source and have it installed in /opt/... Have you ever installed and overlay to the install space of the base install?

demmeln gravatar image demmeln  ( 2013-12-16 03:35:24 -0500 )edit

I guess the `wstool update` works only as wanted if the .rosinstall tracks e.g. the `devel-hydro` packages, but the `rosinstall_generator` (as used according to the install instructions in the wiki) tracks the release tags. Or am I mistaken? Can I switch to the latest release tags with `wstool`?

demmeln gravatar image demmeln  ( 2013-12-16 03:38:53 -0500 )edit

Yes, `wstool set` allows you to change the version tag.

joq gravatar image joq  ( 2014-01-22 09:28:40 -0500 )edit

Yes, but only if you know the tag you want. I was more concerned with getting the latest release for all the base packages, but William outlined a good way to handle it using `rosinstall_generator` and `wstool merge`.

demmeln gravatar image demmeln  ( 2014-01-22 14:47:36 -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

1 follower


Asked: 2013-12-12 02:54:06 -0500

Seen: 3,041 times

Last updated: Dec 16 '13