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?
@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?
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?
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)
@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.
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.
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 . 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.
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.
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.
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.
. It seems like most layers are contained within a single repository. At least layer folders should start with the