Create packagegroups or images based on REP 2001

[robwoolley]

The ROS REP2001 describes variants of ROS 2: https://ros.org/reps/rep-2001.html

The variants recommend the packages that should be included for different types of installations. This appears to map to the packagegroups and image recipes in OpenEmbedded. We should investigate creating recipes that represent the variants to make it easier to create images.

[robwoolley]

REP 2005 (https://ros.org/reps/rep-2005.html) may also provide information useful for creating packagegroups.

[robwoolley]

Look at Space ROS packages as a source of inspiration: https://github.com/space-ros/space-ros/blob/main/spaceros-pkgs.txt

[bchoineubility]

@robwoolley Do you mean ros image can be created as package groups defined in REP not only ros-core-image and ros-image-world?

[robwoolley]

@bchoineubility Yes, that was my intent. The packagegroups are really just logical lists of packages that you wish to include in your image recipe.

The best example of this is turtlebot3-core. There is an image recipe, ros-image-turtlebot3-core.bb, that is really simple:

# Copyright (c) 2019 LG Electronics, Inc.

require ros-image-core.bb

SUMMARY = "Core ROS image containing core TurtleBot 3 packages"
DESCRIPTION = "${SUMMARY}"

IMAGE_INSTALL:append = " \
    packagegroup-ros-turtlebot3-core \
"

It just includes ros-image-core and then adds packagegroup-ros-turtlebot3-core to the image. The core part of which is

# From http://emanual.robotis.com/docs/en/platform/turtlebot3/raspberry_pi_3_setup/#3-install-dependent-packages-on-turtlebot-pc
RDEPENDS:${PN} = " \
    ros-base \
    turtlebot3-bringup \
    turtlebot3-msgs \
    ${TURTLEBOT3_PACKAGES_CAMERA} \
    ${TURTLEBOT3_PACKAGES_LIDAR} \
"

These packagegroups can overlap if needed. So we could create a packagegroup for Space ROS called packagegroup-ros-space.bb that just had a list of the packages mentioned at the URL above.

eg.

RDEPENDS:${PN} = " \
    action-msgs \
    ament-cmake \
    ament-lint \
    builtin-interfaces \
    class-loader \
    composition-interfaces \
etc.

Then to add them to your image you could just put this in your conf/local.conf:

IMAGE_INSTALL:append += "packagegroup-ros-space"

or to build them all just do:

bitbake packagegroup-ros-space

[bchoineubility]

@robwoolley That's good idea ! thanks for good explaination.

[rcwoolley]

@grsandeep85 suggested taking a look at the ros packagegroup used in Petalinux which includes some basic demos and examples: https://github.com/Xilinx/meta-petalinux/blob/rel-v2023.2/recipes-core/packagegroups/packagegroup-petalinux-ros.bb

[robwoolley]

Note that poky provides busybox by default. The ros_setup.sh script and other scripts requires bash and coreutils. The default ros-image-core should include those packages by default.

[Ryanf55]

Note that poky provides busybox by default. The ros_setup.sh script and other scripts requires bash and coreutils. The default ros-image-core should include those packages by default.

Should we also find/file an upstream bug against ROS for meta-ros users that do not want bash installed?

When using source /usr/bin/ros_setup.sh in an environment without bash, I would also expect it to work ok and not rely on bash.

[Ryanf55]

Note that poky provides busybox by default. The ros_setup.sh script and other scripts requires bash and coreutils. The default ros-image-core should include those packages by default.

PR: #1095

[robwoolley]

Should we also find/file an upstream bug against ROS for meta-ros users that do not want bash installed?

When using source /usr/bin/ros_setup.sh in an environment without bash, I would also expect it to work ok and not rely on bash.

I did some quick testing. The problem seems to be specific to the "head -c 1" command that is in /etc/profile.d/ros/_local_setup_util.py

There are 2 possible solutions:

1. busybox does actually have support for head -c 1, however you need to enable the fancy head feature: https://github.com/brgl/busybox/blob/master/coreutils/head.c#L35
2. The other option would be to submit a PR to suggest replacing "head -c 1" with "cut -b 1" which is also in busybox / coreutils.

I'm leaning towards:

1. Rename ros-image-core to ros-image-core-minimal and enable fancy head in busybox
2. Create ros-image-core based on bash and coreutils as the default for new developers who expect an environment similar to what they have on Ubuntu

What do you think?

[Ryanf55]

Should we also find/file an upstream bug against ROS for meta-ros users that do not want bash installed?
When using source /usr/bin/ros_setup.sh in an environment without bash, I would also expect it to work ok and not rely on bash.

I did some quick testing. The problem seems to be specific to the "head -c 1" command that is in /etc/profile.d/ros/_local_setup_util.py

There are 2 possible solutions:

1. busybox does actually have support for head -c 1, however you need to enable the fancy head feature: https://github.com/brgl/busybox/blob/master/coreutils/head.c#L35
2. The other option would be to submit a PR to suggest replacing "head -c 1" with "cut -b 1" which is also in busybox / coreutils.

I'm leaning towards:

1. Rename ros-image-core to ros-image-core-minimal and enable fancy head in busybox
2. Create ros-image-core based on bash and coreutils as the default for new developers who expect an environment similar to what they have on Ubuntu

What do you think?

Great! I like the idea of having a minimal option. I can try to give this a stab first.

[Ryanf55]

Should we also find/file an upstream bug against ROS for meta-ros users that do not want bash installed?
When using source /usr/bin/ros_setup.sh in an environment without bash, I would also expect it to work ok and not rely on bash.

I did some quick testing. The problem seems to be specific to the "head -c 1" command that is in /etc/profile.d/ros/_local_setup_util.py

There are 2 possible solutions:

1. busybox does actually have support for head -c 1, however you need to enable the fancy head feature: https://github.com/brgl/busybox/blob/master/coreutils/head.c#L35
2. The other option would be to submit a PR to suggest replacing "head -c 1" with "cut -b 1" which is also in busybox / coreutils.

I'm leaning towards:

1. Rename ros-image-core to ros-image-core-minimal and enable fancy head in busybox
2. Create ros-image-core based on bash and coreutils as the default for new developers who expect an environment similar to what they have on Ubuntu

What do you think?

For the head -c 1 to cut -b 1 replacement, upstream is in colcon-core it seems: https://github.com/colcon/colcon-core/blob/291f16c9c0bd646f541eaa80f0875f77b83bdc25/colcon_core/shell/template/prefix.sh.em
This would be a trivial patch.

Specifically, here:
https://github.com/colcon/colcon-core/blob/291f16c9c0bd646f541eaa80f0875f77b83bdc25/colcon_core/shell/sh.py#L30

[Ryanf55]

Should we also find/file an upstream bug against ROS for meta-ros users that do not want bash installed?
When using source /usr/bin/ros_setup.sh in an environment without bash, I would also expect it to work ok and not rely on bash.

I did some quick testing. The problem seems to be specific to the "head -c 1" command that is in /etc/profile.d/ros/_local_setup_util.py

There are 2 possible solutions:

1. busybox does actually have support for head -c 1, however you need to enable the fancy head feature: https://github.com/brgl/busybox/blob/master/coreutils/head.c#L35
2. The other option would be to submit a PR to suggest replacing "head -c 1" with "cut -b 1" which is also in busybox / coreutils.

I'm leaning towards:

1. Rename ros-image-core to ros-image-core-minimal and enable fancy head in busybox
2. Create ros-image-core based on bash and coreutils as the default for new developers who expect an environment similar to what they have on Ubuntu

What do you think?

Hi Rob, I discussed with upstream colcon-core, and they would welcome a PR to switch from head to cut. Would you like to submit the patch? ^ See linked issue.

[bchoineubility]

Hi I have a question for colcon issue,

Does it mean yocto will support colcon generator as well ninja in the building ros package?
If so, can you please share what's going on for that?

BR,
Mark

[robwoolley]

Hi Mark,

An intern of mine did have colcon running on the Yocto target to build packages a few years ago (see https://github.com/Wind-River/meta-robot/tree/master/recipes-build/colcon ). If you have an interest in building packages with colcon on the target or with an SDK, it would be helpful if you could file a new issue with details on what it is you are interested in doing. Especially including any sample commands or packages that we could use to verify that it was working.

Regards,
Rob

[bchoineubility]

Hi Rob,

Thanks for reply. by the way, if yocto will support colcon generator, cmake.bbclass would be modified and support "Unix Makefiles" and "Ninja" now.

I don't try to add "Colcon" to cmake.bbclass and build ros package with colcon yet because I am not sure it will be simple trial.

Can you share your trial for it if you had tried it?

BR,
Mark

[robwoolley]

Hi Mark,

I was talking about running colcon outside of bitbake. I don't have a trial to share. May I ask that we have this discussion in a new issue? I don't think it is related to this particular issue.

Regards,
Rob

[bchoineubility]

OK, I misunderstood it. I will create new issue for it someday.

BR,
Mark

[robwoolley]

Quick update: Making packagegroups may be unnecessary because ROS describes meta-packages for each "variant". See the variants directory under generated-recipes for details:

These build successfully:

• ros-core
• ros-base
• perception

They would make good build targets for CI/CD.

These variants don't yet build:

• desktop: needs rqt-common-plugins, rviz2, rvis-default-plugins, turtlesim to be fixed
• simulation: needs ignition/gazebo
• desktop-full: needs all the above

You can test these variants today by just doing: bitbake