Interest in OpenEmbedded?

Hello community :wave:,
we are currently thinking about using ROS2 in our next Yocto based product. We have meta-ros already working in a prototype stage, but there is still a lot to do until it can be released. We were wondering if there is interested from other parties in meta-ros and if it is worth keeping up the development? Most importantly to get the PR for ROS2 humble integration merged.

Seems like there was already a push by @robwoolley beginning of this year, but further development seems to have stopped.

We are also willing to contribute but cannot take over the whole maintenance role alone. Is there anyone interested in ROS2 for Yocto and interested in some sort of cooperation for further development?

7 Likes

Hi @fabolhak ,

we are working on it, since we use humble / noetic / kirkstone in our current setup and are in the process of switching to mickledore. There is more than enough to do, we have forked to kirkstone and mickledore. At least the packages we use seem to work just fine.

It would be very much appreciated if you can test / report and contribute.

I always wonder how anyone can use ROS in a product without meta-ros. So I do not understand why it is seemingly neglected by the community.

Regards,

Matthias

1 Like

Hi @fabolhak and @RethinkMatze

Thanks for expressing interest. I am still interested in bringing back meta-ros. Any help that everyone can offer would be appreciated.

Where I had left off 9 months ago was I had Honister, Dunfell, and Hardknott working for Humble. The number of combinations of ROS distros and Yocto Releases became difficult to manage by myself.

I have since hired a co-op student to assist me with the work and was looking to dust off the work I had started before.

If this is of interest, I’d be happy to resume the OpenEmbedded WG meetings and invite everyone.

Regards,
Rob

1 Like

I expect most ROS users simply use Ubuntu or Isaac. What’s the attraction with yocto /oe? Why don’t more people use it?

Hello all,

Most efforts surrounding meta-ros are unfortunately still a bit disorganized, mostly because there’re very few of us contributing and even less willing to maintain things. I personally have very few cycles to dedicate to this and those I put down are generally funded by partners who are ok with disclosing part of our work. The branches above for kirkstone and mickledore are worth merging upstream. I wasn’t aware of them. @RethinkMatze would you like to submit a PR and ping me? I’d be happy to review and merge them there.

For those interested in latest cutting edge progress in meta-ros, there’s a branch for Yocto langdale that I’ve been meaning to push upstream at GitHub - vmayoral/meta-ros at langdale.

Actually, most people using ROS in production environments don’t. There’re many benefits you can get by moving beyond developer/development-oriented rootfs (or OS, if you prefer it that way). See ROS 2 Humble in AMD KR260 with Yocto for some additional technical arguments.

We’ve also been working heavily on supporting ROS2 Iron + Yocto on the Nvidia Jetson boards here at Mission Robotics.

Right now we have successfully deployed an Iron+Kirkstone image to both a Jetson Nano SD devkit, as well as the Xavier NX eMMC module, including the build/install of our internal ROS2 workspace packages. As part of this, we’ve also tested out deploying with a read-only rootFS (with separate persistent /data partition) and the preempt-rt patch.

We would very much like to collaborate with others, if there is interest in doing so, as it feels like everyone would benefit from some form of collective maintenance here. We see support for Yocto as incredibly important when it comes to achieving robust, scalable production deployments. It also provides additional freedom to support more types of hardware platforms, specifically those designed for industrial applications, where many board/module OEMs provide Yocto BSP.

One of my colleagues will follow up here soon with some more details about what we have done so far, and hopefully we can find a way to upstream some of that work, assuming we can get it to an agreeably upstreamable state.

If this is of interest, I’d be happy to resume the OpenEmbedded WG meetings and invite everyone.

We would love to join, if there is enough interest to fire this back up. I wasn’t even aware there had been an OE WG.

2 Likes

Hello,

Let me intervene in your discussion.

I am a user of meta-ros-foxy and meta-ros-humble (Since few years).

If you would like, I can share my experience with:

  • updating meta-ros-xxx:
    Update versions of ROS packages, how to regenerate the meta-ros-xxx with tools such as ros-generate-cache, rosdep…
    And problems encountered.

  • How to automatically start nodes and monitor them

Best regards,

2 Likes

Hello

I’m working with @spiderkeys on the ROS2 Iron OE/Yocto.

As @spiderkeys mentioned, currently we are based on the following stack:

  • ROS2 Iron
  • Yocto Kirkstone

You can find our ROS2 Iron branch on our github.
This is abased on @vmayoral 's excellent work on the langdale branch.

At the moment, we’re installing basic ROS commands like the ros2 CLI tools.
Besides that, we’re building our own ROS packages using colcon.
While getting our own packages built, I kept coming across some missing references and dependencies within the generated Iron recipes that were easy to resolve.
But there are probably more of them.

The integration of the ROS2 setup into our Yocto build was quite easy. Add the repo as a git submodule, link the required meta folders into the layers and things generally work.

We also have a workflow to create a nativesdk from the yocto image.
This is essentially a cross-compile SDK to build software for your target platform. At the moment we’re packaging this into a docker image for developers to use on their machines.

I would be happy to help bring the ROS2 iron branch upstream. While there’s probably still some work to make sure all the packages are complete and working, if there is anyone that could give us some guidance on additional testing and integration, that would be appreciated.

1 Like

Hello,

thank you so much for all the responses. I did not expect soo much feedback in such a short amount of time.

Currently, I’m on vacation until end of September. When I will be back at work, I will check with my management how much effort we can spent on this.

It’s great to hear that there is interest from the community. I guess that helps in the argumentation :slight_smile:

Kindest regards,
Fabian

1 Like

This is precisely what we use within the Hardware Acceleration architecture. See firmware additions (Pillar II) at REP-2008. sysroots produced in the same manner are added as part of the firmware layer, which then helps enable Yocto (or any other Linux-based) embedded rootfs for CPU cross-compilation. This also helps aligning hardware acceleration resources.

Can you please submit a PR against the kirkstone branch and ping me for review?

I went ahead and made some minor updates in the project:

Another aspect worth discussing is ROS 2/Yocto convergence:

Yocto releases

The ROS 2/Yocto fragmentation is one of the biggest hurdles while maintaining the project. To try to facilitate this, it’d be good to hear what others are planning to do. How does Humble/Scarthgap sound? (both to be maintained until at least 2027).

2 Likes

Hi @fabolhak ,

We are happy to help and contribute to meta-ros layer. Back in Jan 2023 we port forward to langdale as we were moving other layer to langdale.

I echo you taking over ownership would require a potentially significant amount of initial effort, and then some level of on-going effort.

@robwoolley can you please restart the monthly or bi-weekly meetings.

I vote for humble and scarthgap from LTS point of view.