Building a Yocto Image for a MediaTek Genio Robot

There is a moment in every hardware project where a working demo has to become something you can build twice. For an embedded product on the MediaTek Genio, that moment is a Yocto image. Here is how we packaged our robot into one, and the single discipline that decides whether your image is trustworthy.

Key Insights

• A demo lives on one hand-tuned board; a product lives in a Yocto image that rebuilds and reflashes identically
• We package the robot’s ROS 2 container stack, its recipes, and a boot service into a custom layer so the whole system lands the same way every build
• The boot service starts the stack in order and brings up only the nodes whose hardware is actually present
• The most dangerous mistake is a fix made live on the board that never made it into the recipe, because a reflash silently loses it
• Treat the recipe as the source of truth, and verify that a fresh flash reproduces the working board

Why Yocto, and not a setup script

You can bring a board up by hand. You should not ship that way. A board configured by hand is a board only one person can reproduce, and only until they forget a step. A Yocto image is the opposite: it is a build that produces the same root filesystem every time, boots the same way, and can be written onto the next unit with no bespoke setup. The first time you need a second board, or need to reflash the one you have, the image is what saves you from redoing bring-up from memory.

For our robot the image carries the whole software system: the ROS 2 nodes as containers, the recipes that place them and their supporting files, and the orchestration that starts everything at boot.

Baking in a container stack

Running each ROS 2 node as a container is the right structure, and Yocto is how you make that structure durable. A custom layer packages the container images and the recipes that install them, so that a freshly flashed board comes up with the exact stack you tested. On top of that sits a boot service that starts the stack in a defined order and is smart about hardware: it brings up the camera and its consumers only when the camera is present, the lidar-dependent nodes only when the lidar is there, and so on. That way one image behaves sensibly whether a given peripheral is plugged in or not, which matters on a robot that gets reconfigured on the bench.

The trap that bites reflashes

Here is the discipline that separates a real image from a fragile one. During bring-up you will fix things live on the board, because that is faster than a rebuild. Every one of those fixes has to be folded back into the layer, or your image is quietly wrong. We hit exactly this: several pieces of the boot orchestration existed only on the board and not in the recipe, which meant a fresh flash would have come up missing part of the startup. The board worked; the image that was supposed to reproduce it did not.

The rule is simple to state and easy to violate: the recipe is the source of truth, not the board. The check that enforces it is to flash a clean image and confirm the result matches your working unit, before you rely on the image for anything. If a reflash loses a fix, you have found the gap while it is cheap.

We keep the specifics of our layer and recipes for the projects we do, because they are particular to the platform and the product. The reusable lesson is the one above: a Yocto image is only as trustworthy as your discipline about keeping the board and the recipe in sync.

If you are turning a working prototype into a reproducible, flashable image on the MediaTek Genio or on NVIDIA Jetson, that BSP and image work is a core part of what we do. Tell us what you are building. For the robot this image runs, see the ROSOrin build overview and running ROS 2 on the MediaTek Genio.