ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

ROS2 yocto meta layer

Hi all,

I would like to start a discussion about how to install ROS2 into a yocto based system

I tried to use the meta-ros layer from this github repository: https://github.com/bmwcarit/meta-ros

My setup was:

  • imx6 board with a custom vendor yocto image + the meta-ros layer described above
  • Host setup: windows 10 with the ROS2 dashing diademata distro.

I would like to note that this setup does not work well together, mainly because the meta-ros ROS2 recipes are outdated, so probably those two versions are incompatible with eachother.

My main question would be, are there more people looking into this?

2 Likes

Hi @windel,

We did some work, longe time ago, the repo is outdated: https://github.com/erlerobot/meta-ros2

Also, AFAIK there are other companies working to have support for this. Check out: A proposal for a Superflore OE Recipe Generation Scheme

Happy to help you if you needed.

Regards,

@LanderU

Hi @LanderU,

Thank you for your tip on superflore, I was unaware of this: https://github.com/ros-infrastructure/superflore

I guess it does more or less the same as my hand-crafted script (which is still broken so far) https://github.com/windelbouwman/meta-ros2-generator

Regards,
Windel

1 Like

@windel hey! The majority of ROS 2 PR’s into superflore are currently merged into master. Currently, superflore is aiming to push to the ros/meta-ros repository.

@andre.goddard could you please link the necessary resources for @windel to give it a test?

1 Like

The bmwcarit/meta-ros is targeted to move to ros/meta-ros soon.

See this discussion:

Hi @allenh1,

This is good news! Does this mean that ros/meta-ros will contain a layer for ROS2 dashing? We would like to try this system out on a yocto based platform in combination with a Windows 10 PC. What are the hurdles to be taken for this to work?

Today I was able to build rclpy based on my own experiments, but it did not yet work due to python3.5 being the python interpreter on the target.

If there is a test layer available I could give this a try.

Is superflore also able to generate the layer, but not commit in docket / git? In other words could you run it locally?

Regards,
Windel

Does this mean that ros/meta-ros will contain a layer for ROS2 dashing?

That is the plan as I understand it!

Is superflore also able to generate the layer, but not commit in docket / git? In other words could you run it locally?

Yes! you certainly can.

superflore-gen-oe-recipes --output-repository-path [folder] --dry-run

You can also just repoint superflore to your own fork of ros-meta using

superflore-gen-oe-recipes --upstream-repo https://github.com/<owner>/<repo>

We released the recipes for Dashing yesterday.

Please see https://github.com/ros/meta-ros/wiki/OpenEmbedded-Build-Instructions for instructions.

Contact us if you need more information.

@herb-kuta-lge is the new maintainer from LG side.

1 Like

We released the recipes for Dashing yesterday.

And Crystal.

Sorry for beeing nitpicking, but is there any reason not to separate into meta-ros1 and meta-ros2? Usually one ends up using custom meta layers instead of the original ones because they lack configurability and tend to be bloated. In case everything ros version specific is genered dynamically anyway just ignore this comment. It seems like there are ros version specific recipes but no ros version specific images. It seems like it’s not possible to configure w.r.t. ros versions in the layer.conf file. Probably we could add support for Yocto warrior. (End of wishlist) :slight_smile:

@lokesku this is great news! I will for sure try it out. One issue I face right away, is that my yocto version is rocko. The branches on the meta-ros layer are for the thud and morty yocto releases. Is there an option to add the rocko branch as well?

Another question I have is about python versions. Currently rclpy requires python >= 3.6, whereas morty has python3.5. How is this handled?

Sorry for beeing nitpicking, but is there any reason not to separate into meta-ros1 and meta-ros2

We could split the meta-ros.git repo into meta-ros1, meta-ros2, and meta-ros-common layers. I’ll add it to the issues list in the next revision of the Superflore OE Recipe Generation Scheme page.

It seems like it’s not possible to configure w.r.t. ros versions in the layer.conf file.

The ROS distro to be used is configured by the ROS_DISTRO setting in conf/bblayers.conf, which is generated by mcf from a conf/*.mcf file.

Probably we could add support for Yocto warrior.

Contributions from the community are always appreciated.

1 Like

Is there an option to add the rocko branch as well?

Contributions from the community are always appreciated.

Currently rclpy requires python >= 3.6, whereas morty has python3.5. How is this handled?

It isn’t. We only claim that the images build and pass the sanity test. If rclpy doesn’t work when using OE morty, then should we drop ROS 2 support from this branch of meta-ros?

Instead of splitting the repository into meta-ros1 and meta-ros2, I propose to use a more monorepo approach, and use a similar scheme as done in meta-openembedded (https://git.openembedded.org/meta-openembedded/tree/). What is done here, is a single repository with multiple folders. The folders starting with meta- are seperate layers which can be included seperately.

In the case of ROS, I would propose the following scheme:

Create those GIT branches:

  • rocko
  • sumo
  • thud
  • warrior

Create those subfolders:

  • meta-ros2-dashing
  • meta-ros2-crystal
  • meta-ros1-x
  • meta-ros-common

This will allow users to checkout the correct yocto version of the layer. Subsequently, it will allow them to pick the ros distribution they need by including the proper layer.

This essentially boils down to splitting the ros1 and ros2 recipes, except it is done in the same repository, with the benefit of being able to share a common layer which is compatible at all times.

1 Like

Right, the monorepo approach seems to be better.

Right, this seems to be common Yocto best practice. For completion: The GitHub branches relate to the branch selection of the meta layer in the OE Layer Index then. Note: There are also other layers which create directories specific to Yocto versions like e.g. meta-balena.

Is this approach common Yocto best practice as well?

Probably I don’t understand what you meant. But isn’t it best practice to avoid duplication by definining classes, recipes, etc. either w.r.t. meta-ros-common, meta-ros1 and meta-ros2?

Some layers separate also w.r.t. purpose of the recipes, e.g. development like in meta-acrn with recipes-devtools directory. Is this approach suitable and how does it fit into the overall approach?

I don’t know, but it makes sense to me :slight_smile: . It seems like most layers are contained within a single repository. At least layer folders should start with the meta- prefix. In this case, I would suggest to create several layers within the repository, all starting with meta-.

The splitting of recipes in for example a recipes-devtools folder does not enable you to select these recipes only. All recipes from a layer are included into your build. You can only include layers as a whole. The purpose of this folder is clustering of recipes.

Thats indeed the idea. Reduce duplication, by having classes defined in meta-ros-common as much as possible. ROS2 specific classes, like the ament bbclass should go in the meta-ros2-common layer or even in the meta-ros-common layer to reduce the amount of layers.

Hi @windel, A colleague of mine successfully run ROS2 as Yocto layers on top of Raspberry Pi, actually he runs TurtleBot3. Let me check it with him.

I managed to get basic ros2 topic echo working! I used the openembedded-core system (not poky) for this to work. I created a new distro, and included the BSP from my vendor, and the meta-ros layer from github.com/ros/meta-ros. Some dependencies were missing, and the SOABI python configuration was wrong. I had to patch ament.bbclass to include the proper SOABI value is inserted into for example _rclpy.cpython-37m-arm-linux-gnueabihf.so. It was _rclpy.arm-linux-gnueabihf.so, which causes import errors.

1 Like

Hi @windel,

As @razr mentioned, I’ve been able to get meta-ros crystal working on Raspberry Pi. It required some tweaking to get it to build properly with my setup, but I’ve verified that the demos work correctly, and that the embedded board can interface with a PC running ROS. I’ve also ported the firmware and nodes for the Turtlebot 3, along with the Colcon buildtool, into OpenEmbedded layers. We’re hoping to make these layers public soon.

Hi all,

Did someone already manage to use the warrior version of yocto with this layer? I would like to use meta-tensorflow with ros, to use machine learning. At the moment this appears not possible due to the fact that meta-tensorflow is only compatible with warrior, and meta-ros only with thud.

One benefit of the warrior version of yocto is that it include python3.7, instead of python3.5, so the need to include a python3.7 recipe in the meta-ros layer is then resolved.

Regards,
Windel