Project

General

Profile

Actions

Bug #391

open

ROS 2

Added by Guilhem Saurel 12 months ago. Updated 10 months ago.

Status:
New
Priority:
Normal
Assignee:
-

Description

Hello,

We currently have many projects on robotpkg with a declared dependency on ROS 1 via catkin.

On 22.04, they are simply built with the robotpkg version of catkin, as there is no longer one from the system.

Some of them (eg. motion/dynamic-graph-bridge-msgs) are already compatible with ROS 2, and would just need a different packaging (with ament) to be made available for ROS 2.

What could be our strategy here ? Are there other packages that can already be used with ROS 1 system packages on 20.04 and ROS 2 system packages on 22.04 ?

I guess we still want to keep ROS 1 binaries from robotpkg in 22.04 to ease the transition, but I'm not even sure if this would actually be useful to anybody.

Best,
Guilhem

Actions #1

Updated by Anthony Mallet 12 months ago

I guess this could be managed with a "ros alternative", simlilar to
python packages (optionnaly including the alternative in the package
name, depending on the goals).

Currently, there is already a ros alternative to select among ros1
versions. My plan was to deprecate this, as there is no point to
select a ros1 version anymore. I also did not add a ros2 alternative
on purpose, as the ros1 alternative has never been useful: people use
whatever ros version is present on their system and don't care.

So, once the ros1 alternative is gone, it should be possible to
transform it into a "ros1 vs. ros2" selection.

The alternative-dependent dependencies could be managed via the
PKG_ALTERNATIVE_SET.ros{1,2} hooks (hoping this works, sometimes there
are hairy issues with this, but my intuition is that it should work).

To answer some of your other questions:

  • I don't know any other packages in robotpkg that knows about ros1
    and 2 at the same time (genom components are expected to use
    different templates, so this is (will be) already managed via the
    existing genom building options)
  • Building or not binary packages for ros1 alternatives on recent
    distributions is a matter of choice, we can do it or not (possible
    only if the alternative name is included in the packages name, as
    with python). But it should definitely remain possible to build a
    ros1 package on recent distribution if the user configures its
    robotpkg to do so (this does not require the alternative name in the
    package name). I guess we don't care that both can be installed
    simultaneously, also.

What do you think about this?

Actions #2

Updated by Guilhem Saurel 11 months ago

Thanks, I think this is a good solution.

We won't have different ROS 2 version, but we already saw with ROS 1 that we don't need that.

Building for ros1 alternative is still a good idea, as long as it don't require too much additional work to maintain older packages. So I guess we can just decide to build them until we decide to stop building them. And this can be decided package by package if necessary.

About the simultaneous installation, I'm not sure. ROS binary packages are separated in /opt/ros/<version>, but this won't be the case for us, so they will be conflicts between installed files. At least, apt will probably not like it.

Actions #3

Updated by Anthony Mallet 11 months ago

Do you have an idea of how many packages would be concerned?

I started to work on the alternative, which works, but the PLIST have
nothing in common (at least for motion/dynamic-graph-bridge-msgs).
So this makes complex packages:
- handle totally different dependencies (ok)
- prefix the name with ros/ros2 so that dependency works (ok-ish).
- have two different PLIST (.ros, .ros2) (ok)
- Deal in some way with SYSTEM_SEARCH (not found how exactly yet)

But all in all, if it is only a couple of packages that will need
this, maybe having completely separate packages will be easier to deal
with.

Actions #4

Updated by Guilhem Saurel 11 months ago

Ok, I can maintain motion/ros-dynamic-graph-bridge-msgs and motion/ros2-dynamic-graph-bridge-msgs, this would probably be easier and faster for me.

Actions #5

Updated by Anthony Mallet 11 months ago

On Thursday 10 Aug 2023, at 18:31, Guilhem Saurel wrote:

Ok, I can maintain motion/ros-dynamic-graph-bridge-msgs and
motion/ros2-dynamic-graph-bridge-msgs, this would probably be easier
and faster for me.

If that's the only one, yes, definitely.

One can keep motion/dynamic-graph-bridge-msgs as is, and just create
the new one as motion/ros2-dynamic-graph-bridge-msgs.
I already started with this one, so I can push the ros2 version soon
if you like.

Actions #6

Updated by Guilhem Saurel 11 months ago

this won't be the only one, as this is only the first of the dependency chain, but this chain is not that huge.
Yes, if you have something that work for you, it will make a nice example for the others, thanks !

Actions #7

Updated by Anthony Mallet 10 months ago

I finally pushed a new package motion/dynamic-graph-bridge-msgs-ros2
that will be compiled for ros2.

On Ubuntu-22.04, the binary package will use ros/rolling, as suggested by
Olivier Stasse. On other distributions, it will use robotpkg version
which contains more or less ros-rolling versions, with a bit of lag due
to lazyness :) (but each ros2- package can be upgraded on an
individual basis when needed).

The naming scheme is as follow:
ros2- indicates an 'official' package part of ros distribution.
*-ros2 indicates a regular package, not part of ros distribution, but
using ros2-* packages :)

Tell me if you have any issue!

Actions

Also available in: Atom PDF