meta-ros: Building ROS 1 and ROS 2 Images with OpenEmbedded

What meta-ros Actually Solves

The key value is that meta-ros removes the need to hand-maintain recipes for each ROS package. Instead, it uses a tool called superflore to generate recipes automatically from the ROS release repositories. This is a fundamental design choice: the project does not try to keep a static set of recipes, but instead regenerates them as upstream ROS packages change. That keeps the layers in sync with ROS releases, but it also means the quality of the build depends on how well superflore's generated recipes match OpenEmbedded's conventions. The README mentions that the original implementation for ROS 1 Indigo was transferred from bmwcarit in 2019, and the ROS 2 port came from Erle Robotics, so the project has accumulated history and now relies on a generation pipeline rather than hand-written recipes.

How the Layers Are Organized

The repository splits into several layers. The most important is meta-ros-common, which 'provides recipes that are common to all ROS distributions,' including third-party libraries and ROS-specific image and package group recipes. Each ROS distro gets its own sub-directory containing a layer inside each branch. That layer holds BitBake configuration files that describe the distro, such as which packages can be built. The actual recipes generated by superflore are placed in recipes-* directories. When the generated recipes need tweaks, the project uses bbappend files in recipes-bbappends. This separation means you can mix a common base with distro-specific overrides. The branch structure reinforces this: the master branch tracks the Yocto release under development, while branches named after Yocto releases have linear commit histories for stable support. The -next branches hold pending changes that may be rewritten, so you should not base a production build on them. The build branch contains the mcf tool and .mcf configuration files that set up an environment; the README points to a separate README in that branch for kas instructions.

Supported Combinations and Their Meaning

The README includes a support table that is the single most important piece of information for adoption. It lists Yocto releases (Wrynose, Whinlatter, Walnascar, Styhead, Scarthgap) against ROS 2 distros (Rolling, Humble, Jazzy, Kilted, Lyrical). Each cell has an end-of-life date or is struck through as unsupported. For example, the Wrynose LTS release supports Humble until May 2027, Jazzy until May 2029, and Lyrical until Apr 2030. The Scarthgap LTS supports Humble until May 2027, Jazzy until Apr 2028, and Lyrical until Apr 2028. Older Yocto releases like Whinlatter and Walnascar are fully struck through, meaning no ROS distro is supported on them. The table also defines support levels: 'full' means fully supported, 'unsupported' means never built and only updated for breaking upstream changes, 'best-effort' applies when a ROS distro or OpenEmbedded series is EOL, and 'contrib' means contributed but not built. This is a critical constraint: if your Yocto release is not in the table, you are on your own. The project does not promise support for arbitrary combinations, and the dates show that support tracks the upstream lifecycle of both Yocto and ROS. For a long-lived product, you should choose an LTS Yocto release and an LTS ROS distro, such as Scarthgap with Humble or Jazzy, and verify the end-of-life dates align with your product's expected lifespan.

Getting Started with kas and mcf

The README says the easiest way to start is to build Kirkstone (Yocto) with Humble (ROS 2), and it recommends using the kas tool to clone repositories and kick off the build. It points to a README in the build branch for instructions, but does not include the exact commands in the main README. The build branch contains the mcf tool, which uses .mcf configuration files found in files, files-contrib, and files-unsupported directories. So there are two paths: kas, which is a Yocto-specific build tool that uses a YAML configuration to fetch layers and set up the build, and mcf, which is a custom tool that reads .mcf files. The .mcf files are organized by support level, so files-unsupported likely contains configurations that are not officially supported. This is a practical detail: you must pick the right configuration file for your combination, and the support level tells you whether the build is expected to work. The README also notes that the last official milestone was Milestone 17 on 2022-06-05, and milestones follow the format <BRANCH>/milestones/<N>. This suggests that the project releases updates in batches, and you should track which milestone you are on to know how recent your recipes are.

The Superflore Generation Pipeline

A central mechanism is the use of superflore, a tool from the ROS infrastructure team that generates OpenEmbedded recipes from ROS package repositories. The README says the project 'has been converted to use recipes generated by superflore' and links to a wiki page describing the scheme. This means the recipes are not hand-written; they are produced by parsing ROS release metadata and translating it into BitBake syntax. The advantage is that when a ROS package updates, the recipe can be regenerated to match. The disadvantage, which the README hints at, is that generated recipes may not always build cleanly, and that is why bbappend files exist to patch them. The README also mentions that the original implementation is retained in the legacy branch, so there is a history of hand-maintained recipes that were later replaced. For an engineer, this means you should not expect every ROS package to build out of the box; the project's own contribution section asks for help 'adding support for ROS packages that are currently skipped.' So the pipeline is a starting point, not a guarantee. You will likely need to write your own bbappends for packages that fail to build or are missing from the generated set.

Maintenance and Upgrade Cost

The support table's end-of-life dates are the clearest signal of maintenance cost. Each combination has a finite support window, and once a Yocto release or ROS distro reaches EOL, the configuration moves to 'best-effort' or becomes unsupported. The README states that unsupported configurations are 'never built and only updated to fix breaking changes introduced upstream,' so you cannot rely on fixes for functional issues. Upgrading to a new Yocto release or ROS distro requires moving to a different branch, because each Yocto release has its own branch. The commit history on release branches is linear, which simplifies tracking changes, but the -next branches can be rewritten, so you should not base a build on them. The project uses milestones to batch updates, and the last one was in 2022, so there may be gaps between updates. For a product, you must plan for periodic upgrades to stay within the supported matrix. The licence is MIT, which is permissive and does not impose restrictions on redistribution, but you should still check the licences of the upstream ROS packages you include, as they may vary. This is not legal advice, but a practical note that the layer's licence does not cover the entire software stack.

Limitations and When to Look Elsewhere

The most obvious limitation is the narrow support matrix. If your target Yocto release is not listed, or if you want a ROS 1 distro (the table only shows ROS 2), you are out of luck. The README's history section mentions ROS 1 Indigo as the original implementation, but the current table only lists ROS 2 distros. That implies ROS 1 support is effectively legacy. Another limitation is that the generated recipes may not cover every ROS package; the contribution section asks for help adding support for skipped packages. This means you cannot assume a package will build just because it exists in ROS. The project also relies on the kas or mcf tools, so you must learn those workflows, which adds a learning curve if you are new to Yocto. An alternative approach is to use a pre-built ROS image from a vendor like Ubuntu or Debian, which gives you binary packages but sacrifices the custom image control that Yocto provides. Another alternative is to use the official ROS Docker images, which are easier to set up but do not run on bare metal embedded systems. The difference is that meta-ros integrates with the Yocto build system, so you get a root filesystem that is tailored to your hardware, whereas binary distributions assume a generic Linux environment. If you need that tight integration, meta-ros is the right tool; if you just need ROS on a development machine, a binary install is simpler.

Editorial conclusion

Adopt meta-ros if you need to build a custom Linux image for a robot and you already commit to the Yocto Project workflow. It is the only maintained layer set that covers both ROS 1 and ROS 2 across multiple distros, and the support matrix tells you exactly which combinations are safe. Do not use it if you want a quick binary install or if your target Yocto release is not listed in the table; anything not in the table is unsupported. Before starting, verify that your Yocto release and ROS distro pair appears as 'full' in the support table, and check the build branch for the kas configuration that matches your chosen combination. The project's own history shows that ROS 1 support is legacy, so plan for ROS 2 only if you are starting fresh.

Official sources

1. Official README
2. Project repository
3. Release notes