ros / meta-ros

OpenEmbedded Layers for ROS 1 and ROS 2

meta-ros

This is a series of OpenEmbedded layers designed to add support for the Robot Operating System (ROS) for embedded Linux releases by the Yocto Project.

It enables developers to create custom, Linux-based robotic systems, taking advantage of capabilities of ROS and the flexibility of the Yocto Project.

Supported Combinations

The following table shows the end-of-life dates for combinations of Yocto Releases and ROS Distros. Releases and distros not shown in the table above can be presumed unsupported.

Yocto Release		ROS1 Distros	ROS 2 Distros
	(Rolling)	Noetic	Humble (LTS)	Iron
		May 2025	May 2027	Nov 2024
Styhead (Dev)	(Future)	May 2025	(Future)	Nov 2024
Scarthgap (LTS)	Apr 2028	May 2025	May 2027	Nov 2024
Nanbield	Apr 2024	Apr 2024	Apr 2024	Apr 2024
Mickledore	Nov 2023	Nov 2023	Nov 2023 1	Nov 2023
Langdale	May 2023	May 2023	May 2023	May 2023
Kirkstone (LTS)	Apr 2026	Apr 2024	Apr 2026	Nov 2024

Support Levels

Value	Definition
full	the configuration is fully supported
unsupported	the configuration is never built and only updated to fix breaking changes introduced upstream, eg [master] of a component’s repository being renamed to [main] or git:// needing to be replaced by https://
1 best-effort	the configuration has an EOL-ed ROS distro or OpenEmbedded release series, which means only a “best effort” will be made to have all its packages build
2 contrib	the configuration has been contributed and is not built

Getting Started

The easiest way to get started with ROS with OpenEmbedded is to build the combination of Kirkstone (Yocto Project) with Humble (ROS 2).

You may use the kas tool to clone the necessary git repositories and kick off the build.

Instructions can be found here: https://github.com/ros/meta-ros/tree/build/kas/README.md

Repository Layout

Branches

The master branch follows the Yocto Project release series currently under development.

The branches named after Yocto releases track updates during their support lifecycle. The commit history on these branches is linear.

The -next branches contain commits that are pending being merged into their corresponding unsuffixed branches. The commit history on these branches may get rewritten as patches are tested and revised.

The build branch contains the mcf tool which can be used for creating an environment using the .mcf configuration files. These files may be found in the files, files-contrib, and files-unsupported directories in the build branch.

Tags

Information on past meta-ros milestone releases can be found on the meta-ros GitHub wiki: https://github.com/ros/meta-ros/wiki/Superflore-OE-Recipe-Generation-Scheme#milestones

The last official milestone was Milestone 17 on 2022-06-05.

Milestones provide updates for all supported combinations of OpenEmbedded releases and ROS Distributions. They follow the format <BRANCH>/milestones/<N>.

ROS Layers

The meta-ros-common layer provides recipes that are common to all ROS distributions. This typically includes 3rd party libraries and tools needed by ROS as well as ROS-specific image and package group recipes.

The ROS distros each have their own sub-directory containing a layer inside each branch. This contains bitbake configuration files that describe the ROS distro including which packages from ROS may be built. The recipes generated by the superflore tool may be found in the recipes-* directories. When changes are required against the generated recipes, the bbappend files are created in recipes-bbappends.

History

The original implementation of meta-ros for ROS 1 Indigo Igloo (https://github.com/bmwcarit/meta-ros) was transferred here on 2019-06-25.

The initial port of ROS 2 port was undertaken by Erle Robotics. Their work was shared at this repository and integrated upstream into meta-ros.

It has been converted to use recipes generated by superflore. Please see this wiki page for details of what was done and the current development milestones.

The original implementation has been retained in the legacy branch.

Contributing

There are many ways to contribute back to meta-ros. This includes helping report build errors, writing documentation, adding support for ROS packages that are currently skipped, and adding build-time and run-time tests for ROS packages.

• To find details of how meta-ros is being developed, you may find detailed information at the meta-ros wiki.

• To report a bug with meta-ros, we encourage you to file an issue. We also welcome pull requests.

• See CONTRIBUTING.md for additional information about ROS contribution policies.

Join the meta-ros Community

To join the conversation about meta-ros you may find us on the forum or at our bi-weekly working group meeting:

• OpenEmbedded category on the ROS Discourse forum
• ROS OpenEmbedded Working Group (minutes, meeting invites)

meta-ros's Issues

Create a logo for advertisement

Probably, something that combines the logos of OpenEmbedded and ROS

Create document to discuss changes in ROS package.xml from our point of view

• Summarize some comments in #34

Is LGPL-2.1 or LGPLv2.1 the standard license string in OpenEmbedded?

• check documentation or source

Try to use this repository simply following the instructions in README

Find and remove mistakes in the README and hard-coded assumptions about the setting of the development system.

Create mailing list and Register it in archives

std-srvs: requires target /usr/lib/genpy/gensrv_py.py needed by _Empty.py

| /home/lukas/oe-core/build/tmp-eglibc/sysroots/x86_64-linux/usr/bin/cmake -E cmake_progress_report /home/lukas/oe-core/build/tmp-eglibc/work/i586-oe-linux/std-srvs/1.9.41-r0/ros_comm-1.9.41/messages/std_srvs/build/CMakeFiles 3
| make[2]: Entering directory /home/lukas/oe-core/build/tmp-eglibc/work/i586-oe-linux/std-srvs/1.9.41-r0/ros_comm-1.9.41/messages/std_srvs/build' | make[2]: *** No rule to make target/usr/lib/genpy/gensrv_py.py', needed by devel/lib/python2.7/site-packages/std_srvs/srv/_Empty.py'. Stop. | make[2]: Leaving directory/home/lukas/oe-core/build/tmp-eglibc/work/i586-oe-linux/std-srvs/1.9.41-r0/ros_comm-1.9.41/messages/std_srvs/build'
| make[1]: *** [CMakeFiles/std_srvs_genpy.dir/all] Error 2
| make[1]: *** Waiting for unfinished jobs....
| [ 25%] [ 50%] Built target std_srvs_gencpp
| Built target std_srvs_genlisp
| make[1]: Leaving directory `/home/lukas/oe-core/build/tmp-eglibc/work/i586-oe-linux/std-srvs/1.9.41-r0/ros_comm-1.9.41/messages/std_srvs/build'
| make: *** [all] Error 2
| ERROR: oe_runmake failed
| ERROR: Function failed: do_compile (see /home/lukas/oe-core/build/tmp-eglibc/work/i586-oe-linux/std-srvs/1.9.41-r0/temp/log.do_compile.25332 for further information)
ERROR: Task 7 (/home/lukas/oe-core/meta-ros/recipes-ros/ros-comm/std-srvs_1.9.41.bb, do_compile) failed with exit code '1'

Address the cross-compiling problems with rosunit

roslaunch: When running roscore in the qemu VM, fails with "no module named ..."

To run roscore, we must add to roslaunch the runtime dependency on all the required python modules.

rospkg: get_path fails with ResourceNotFound during execution of rosgraph and roscore

The function get_path at /usr/lib/python2.7/site-packages/rospkg/rospack.py:164 fails with ResourceNotFound. This is probably due to missing environment variables which are typically set by the setup.sh script. However, this setup.sh is not installed on the target at the moment.

To reproduce, use the core-image-ros-groovy-running-roscore and start rosgraph in the VM.

refine License declaration LPGL in python-empy

Currently, bitbake reports the warning for python-empy
No generic license file exists for: LGPL in any provider.

OpenEmbedded knows a number of refined LGPL licenses. We must check under which python-empy is licensed and refine the recipe.

Check the roscpp packages

In b00261e, the roscpp packages are shipped empty.

We should check

• if it intended that these packages are empty.
  (As they are preprocessor packages, it could be that they do not ship anything that is needed in the guest system, e.g. object files, libraries, ...)
• if we can configure the depending recipes, so that these packages do not have to be created, but only the dev packages are created and used.

check where to host the mailing list of this project

Document the downloadfilename option in the bitbake and/or openembedded and/or yocto manual (follow-up of issue #6)

copy the open issues from the ISSUES file to this tracker and remove the ISSUES file

Use meta-oe layer instead of copy recipes to our layer

I would propose to add the meta-oe layer to the dependencies of our layer and to remove all duplicated recipes.

Make dev-packages portable

1. The dev-packages should be usable in the sysroot environment and in the target system.
   While development, native compilation of depending ros packages require the dev-packages in the target system.
2. The dev-packages should be usable in other OpenEmbedded build environment, e.g. when copying the sstate packages. (Check if this is a use case supported by OpenEmbedded generally.)

At the moment, the config.cmake files fixes some pathes. This makes the packages not portable.

rospack: QA Issue rdepends

QA Issue rdepends:

ERROR: QA Issue: rospack rdepends on rospack-dev
ERROR: QA run found fatal errors. Please consider fixing them.

find out what housel's gist does and how it is related to our work

There is a gist from housel at https://gist.github.com/1263777
However, this work seems to create recipes for some older version of ROS (pre-groovy & pre-catkin time).
Also in the new version, the package.xml has changed.
Nevertheless, we should the rationale and the ideas in that gist.
Maybe, we can also communicate with the author.

topic-tools: fails in compilation with sysroots/x86_64-linux/usr/lib/libboost_thread-mt.so: could not read symbols: File in wrong format

The topic-tools recipe fails during the do_compile step at:
build/tmp-eglibc/sysroots/x86_64-linux/usr/lib/libboost_thread-mt.so: could not read symbols: File in wrong format

Revisit rostime recipe

• remove obsolete -DCMAKE_PREFIX_PATH setting.
• check if RDEPENDS is necessary.

check style of recipes

The created recipes should follow the style defined in
https://wiki.yoctoproject.org/wiki/Recipe_%26_Patch_Style_Guide
and
http://www.openembedded.org/wiki/Styleguide.
Possibly make checking the style part of some testing process.

Push collaboration with related repositories

There are two other related repositories:

https://github.com/kartikmohta/meta-km
https://github.com/yida/yida-collections

Tasks:

• Evaluate the overlap of recipes
• Check differences in the overlapping part
• Evaluate quality of the other recipes
• Come up with scenarios for collaboration

tests for ensuring correct installation with tests in VM or something else

The existing test script checks that all packages can be build.
However, it does not ensure that the packages can run in an image.
We must also provide tests that check this property for all the packages.

First, we should discuss how one could implement that in general.

Improve OE-core's python-setuptools that requires some python modules at runtime.

When installing python-setuptools in an image, setuptools is not functional, because it depends on some python modules at run time.

Figure out the python modules it depends on, send a patch to openembedded core.

The extra cmake files cannot be loaded because the config.cmake points to the root directory instead of the sysroot environment.

catkin: Remove comments about current issues

In cfd4488, we add some notes about current issues. These should be moved to github issues and removed from the source.

add ALLOW_EMPTY_${PN} = "1" to roscpp-traits

Add a MIT license text in the script files

Contribution to OE Core: python-pprint rdepends on python-io

The python manifest in OE Core does not reflect that python-pprint rdepends on python-io.
Discuss on the OE Core mailing list to add this dependency.

Refine License LGPL in the package.xml of xmlrpcpp sources

We believe it is licensed LGPLv2.1.

• check license
• announce on mailing list
• send patch via github

message_generation and genlisp issue

Any package that uses message_generation when building also depends on genlisp, as it seems.

adjust license in xmlrpcpp recipe

• refine from LGPL to the correct LGPL version
• Maybe update the package.xml in ros_comm as well

try out if we can compile to arm architecture

There is a high interest in compiling ROS for arm architectures. We should check how we can do this with OpenEmbedded and our recipes.

catkin-native: Reinvestigate why catkin-native fails in assert.cmake called by rt.cmake

In 3f2a343, we patched catkin to remove assertion for the rt-library.
However, we did not understand the reason why this check fails in our setting, why the check is there in the first place, and what the consequences of simply removing the check is.
Possibly, this must be discussed with the catkin developers.

Depend on native version of tool packages

All ROS packages with install tools in the bin directory or install python code with is used by other packages should be used as native version. The DEPENDS must be adapt accordingly.

Understand what RDEPENDS in the recipes should be set to

So far, we have been just compiling ROS, so we did not add RDEPENDS in any recipe.
Once, we create images, we should check what RDEPENDS must be for each recipe.

add LICENSE information in ros recipes

The ros package source do not ship the BSD license text.
The only reference to BSD is in the package.xml, we should always at least check that file for the reference to BSD.

std-msgs: the recipe does not generate the message header files

The CMakeLists file (https://github.com/ros/std_msgs/blob/0.5.7/CMakeLists.txt) contains the line:

generate_messages()

This should produce the message header files in the devel directory.

But, the generated Makefile from the cmake/catkin call does not contain the annotations to call gencpp and generate the header files, that I actually expected.

The generate_messages() or add_message_files(...) in the CMakeLists.txt seems to be ignored.

This needs further investigation.

This issue then leads to the failure in roscpp, e.g. missing String.h file.

Check status of 30306b6bba213995c1c16a9ff833b0ae282fb2c2

Use the existing ros recipes in the core-image and compile the rest in the guest system on top

Investigate occasional error with catkin-native and the recipes

My conjecture is that once I installed catkin in the build environment,
any recipe that uses catkin-native breaks down, because it uses the catkin files in the "staging dir" instead of those in the "staging dir native".

It can be mitigated by starting with a clean build environment, and avoid installing catkin.

How could we tweak the recipes to avoid picking up those catkin files in the staging directory at all?

The error is:

| CMake Error at /home/lukas/poky-danny-8.0/build/tmp/sysroots/qemux86/usr/share/catkin/cmake/catkinConfig.cmake:20 (include):
| include could not find load file:
|
| /usr/share/catkin/cmake/all.cmake
| Call Stack (most recent call first):
| CMakeLists.txt:3 (find_package)
|
|
| CMake Error at /home/lukas/poky-danny-8.0/build/tmp/sysroots/qemux86/usr/share/catkin/cmake/catkinConfig.cmake:87 (list_insert_in_workspace_order):
| Unknown CMake command "list_insert_in_workspace_order".
| Call Stack (most recent call first):
| CMakeLists.txt:3 (find_package)
|
|
| -- Configuring incomplete, errors occurred!

Check if we have to mention to use the patched distutils class

In ee91c90, the distutils.bbclass in this repository (a patched version of the one in poky-danny, which has now been put upstream in the OpenEmbedded-core repository) was deleted from the repository.
The installation guide should explicitly mention to get the patched version if necessary for the native compilation of ros-groovy.

create a script that generates bitbake recipes out of the package.xml files

check the semantics of two licenses in a package.xml

https://github.com/ros/roscpp_core/blob/groovy-devel/roscpp_core/package.xml

mentions two licenses. Are they meant as OR and as AND? How do they model this anyway in ROS?

• Check ROS wiki or ask mailing list.
• Which LGPL license is meant?

Create a script that tests the recipes and writes a useful test report

QA Issue: unshipped files

All these files are currently not shipped in various packages:

QA Issue Warning:
/usr/.catkin
/usr/setup.bash
/usr/.rosinstall
/usr/setup.sh
/usr/setup.zsh
/usr/_setup_util.py
/usr/env.sh

/usr/share
/usr/share/<package_name>
/usr/share/<package_name>/package.xml
/usr/share/<package_name>/cmake
/usr/share/<package_name>/cmake/<package_name>Config-version.cmake
/usr/share/<package_name>/cmake/<package_name>Config.cmake

/usr/share/genmsg/cmake/pkg-<package_name>.cmake.em
/usr/share/genmsg/cmake/pkg-<some_other_name>.cmake.in
/usr/share/genmsg/cmake/pkg-<package_name>.context.in

/usr/etc/ros
/usr/etc/ros/python_logging.conf

Add new contributor to readme file

create a shell variable for the ros-gbp github and replace the address in all ros recipes

check if it is worth to keep a CONTENTS file

Two recipes with the same file name cause a clash and bitbake only downloads one file

-also noted 049a1a6
-occurs with roscpp-traits and rostime, roscpp-serialization
-best ask on the openembedded mailing list