Ros-ourdistro-... style add-on rosdistro

Buildfarm
1

Hi there,

We’ve successfully deployed the buildfarm in three virtual machines, and we have created an add-on rosdistro for kinetic with a simple package that only depends on roscpp. Now we can build and generate debian packages using the infrastructure.

Next step for us is to properly handle our forked ros packages. Let’s assume a package called ros-kinetic-foo (from official repositories), but we don’t want to use it because we want to use our forked version. Our idea is to make a clear separation between the official and forked version, creating a package called ros-ourdistro-foo.

Basically we’d want to use ros-kinetic-* packages together with our ros-ourdistro-* packages.

We’ve tried creating a new entry in our forked rosdistro. The ourdistro/distribution.yaml is a copy of the kinetic/distribution.yaml file, and ourdistro/addon_distribution.yaml only contains the package that depends on roscpp

ourdistro:
    distribution: [ourdistro/distribution.yaml, ourdistro/addon_distribution.yaml]
    distribution_cache: http://our_server/rosdistro_cache/ourdistro-cache.yaml.gz

When executing devel job, the package tries to find ros-foo-roscpp, and not ros-kinetic-roscpp

Not sure how this problem should be addressed. What’s the best way to handle it?

2

You’re going to run into several issues:

  • there’s no way to get two base workspaces in /opt/ros to overlay via catkin
  • rosdep doesn’t know how to resolve inter-distro dependencies.

So at the very least, you should expect to have only one ‘ROS distribution’ active at a time.

3

Hello,

I haven’t had the chance to set up an addon rosdistro myself yet but from reviewing the Custom rosdistro docs

I don’t think your custom rosdistro should include the distribution.yaml from kinetic as ourdistro/distribution.yaml as this will tell rosdep will expect to resolve dependencies using ros-ourdistro-roscpp rather than ros-kinetic-roscpp. When you remove that distribution file you’ll need a way to resolve dependencies in your addon distro to their kinetic counterparts. Currently the tool for doing so is GitHub - mikepurvis/rosdep-generator. It will take an upstream rosdistro and generate a static rosdep definitions file for it. Adding that definitions file to your local rosdep sources will let you use rosdep and bloom to resolve dependencies for your addon packages to the upstream versions instead.

I do have a prototype branch here that allows for the inclusion of additional rosdistros in rosdep sources directly but I can’t fully recommend it as it may change while in review to be included in upstream rosdep.

This limitation I don’t have any suggestions to get around.

4

On the robots from PAL Robotics (e.g., the Tiago), they do something similar to what you’re trying to achieve. They use a stable version of e.g. ROS Indigo, which is just a snapshot of the official packages and which is installed to /opt/ros/indigo. In addition, they have their own “distro” which they call “PAL Dubnium” that contains their own addon packages and which is installed to /opt/pal/dubnium, and which overlays the Indigo workspace. I’ve found this presentation on Google, but sadly it doesn’t contain many details. Perhaps you should contact the author (Luca Marchionni) directly.

5

@v-lopez may have slightly more time to answer from PAL Robotics.

Overlaying works pretty well.

6

Hi like @Martin_Guenther and @awesomebytes have said we do use our on custom distribution on top of ROS.

We started doing this before the new buildfarm was created and the documentation linked by @nuclearsandwich was created, so what we’ve done may differ with the steps detailed there.

We freeze make a snapshot of a ROS distribution’s repositories (let’s say Kinetic), and then we release our custom ROS packages or our own software. Our package naming scheme is pal-erbium-my-pkg-name.

We install them on /opt/pal/ and ROS keeps installed in /opt/ros. Instead of sourcing /opt/ros/kinetic/setup.bash, you source /opt/pal/erbium/setup.bash, and this file already sources kinetic and makes the overlays behave as expected.

As long as you source the original ROS workspace (say Kinetic) before building your custom distro, I believe the overlays work flawlessly.

We usually have 3 levels /opt/ros/kinetic, /opt/pal/erbium and working workspace.

1 Like
7

I believe what @nuclearsandwich means to say is that you cannot have two install spaces active if they were not built as overlays. Your setup works, as /opt/ros was active while /opt/pal was built. But if that was not the case, there is no link between the two and sourceing one will deactive the other.

The setup described by the OP was like that.