Introduction

The debate over packaging robotics software is as old as robots themselves!

As the industry has evolved from 'dumb' robots, like Kawasaki robot arms, to intelligent, autonomous systems, like Waymo’s robotaxis, this debate has intensified.

Unlike their predecessors, intelligent robots require an iterative software development life cycle (SDLC) driven by rapid advancements in embodied AI, constantly pushing the state-of-the-art (SOTA) in robotics.

Apple and Tesla have popularized over-the-air (OTA) software updates for hardware. The standard is clear — to be defined as a modern hardware company, customers expect frequent software updates.

The requirement to quickly ship software updates means robotics teams are reconsidering how to package their software.

The ideal deployment flow must:

• Simplify software packaging,

• Integrate seamlessly with CI/CD pipelines,

• Enable rapid iteration,

• All without sacrificing performance!

In this blog, we’ll explore two popular software packaging methods for robotics: Docker and Yocto.

We’ll explain them, their benefits, and how to choose the right approach for your next robotics project.

Buckle in!

Docker

The Docker platform uses containerization to package applications with their dependencies, libraries, and configurations, ensuring consistency across operational contexts.

In this section, we’ll cover the core concepts and features essential to using Docker.

Core Concepts:

• Container

  • A lightweight, isolated runtime environment bundling an application and its dependencies.

• Image

  • A pre-built, immutable template used to create containers.

  • A container is an instance of an image.

• Dockerfile

  • A text file with instructions for building a Docker image, specifying the base image, dependencies, configurations, and setup commands.

• Docker Compose

  • A tool that manages and orchestrates multi-container systems using a .yml file.

  • Simplifies running interconnected services.

  • An easier but less powerful alternative to Kubernetes and Docker Swarm.

• Container Registry

  • Stores and distributes Docker images, either cloud-hosted (e.g., Docker Hub, AWS ECR, Google Artifact Registry) or on-prem.

• Volume

  • Persists data outside a container’s lifecycle, enabling data sharing between containers and ensuring it survives restarts.

• Layer

  • Each instruction in a Dockerfile creates a cached layer, optimizing builds and storage.

Features:

1. Containerization

   • What it is: Containerization isolates services into separate, lightweight units, ensuring portability and repeatability.

   • Why it’s useful: A robotics development workflow has a variety of operational contexts— from developer workstations, simulations, hardware-in-the-loop (HIL) rigs, test robots, and production robots (whew, that’s a lot 😅). Containers reduce integration issues between these contexts.

2. Isolation

   • What it is: Docker containers run independently of the host operating system (OS) and other containers.

   • Why it’s useful: Robotics systems run multiple services in conjunction, — such as path-planning, perception, and object detection. Isolation encapsulates dependencies and runtime environments, preventing conflicts.

3. Ease of Deployment

   • What it is: Once built, Docker images are reusable and, when stored in a container registry, can be quickly deployed to target devices.

   • Why it’s useful: Robotics engineers test iteratively on real machines. Pre-built images eliminate the need to rebuild large applications (often 10+ GB), streamlining the workflow.

Yocto

Yocto, primarily used in embedded systems, allows engineers to create custom Linux-based system images. It provides the tools, templates, and workflows to build images from source, offering control, flexibility, and optimized performance for specific hardware.

Here’s what you need to know about Yocto:

Core Concepts:

• Image

  • The final output of a Yocto build.

  • Combines the kernel, bootloader, and software packages into a deployable format.

• Recipe

  • Like a recipe for baking a cake! Defines how to fetch, configure, and build software components to create images.

  • Uses .bb (BitBake) file format to specify source locations, dependencies, and build instructions.

• Layers

  • Modular collections of recipes and configurations.

  • Promotes separation of concerns between OS and application layer.

  • Examples: Board Support Package (BSP) Layer meta-tegra for Jetson and meta-robotapp for ROS2.

• BitBake

  • The task scheduler and engine at the core of Yocto.

  • Executes instructions in recipes to build software components, packages, and images.

• Tasks

  • Build steps handled by BitBake.

  • Defined in recipes and executed in order, based on specified dependencies.

  • Examples: fetching source code, compiling, and packaging software.

• Package Management

  • Outputs build artifacts in formats like .deb (Debian), .rpm (RedHat), and .tar (Tarball),

  • Enables software installation, updates, and removal on target devices.

Features:

1. Customizable Linux Distribution

   • What it is: Yocto is like à la carte dining, while Ubuntu is a buffet. Ubuntu offers ALL components and libraries, even those you may not need. Yocto lets you select only the components that perfectly match your use case.

   • Why it’s useful: Every robot has a unique configuration of hardware, firmware, software, and ML. Yocto allows you to build the Goldilocks image for that configuration and eliminate everything else.

2. Lightweight Images

   • What it is: Yocto generates minimal, efficient system images tailored to the hardware.

   • Why it’s useful: Edge devices have limited CPU power, RAM, and disk space. By removing unnecessary components, Yocto images reduce overhead, allocating more resources to critical tasks like perception or control. This can lower latency, improve response times, and optimize power consumption.

3. Real-Time Support

   • What it is: Yocto supports kernel modifications like PREEMPT-RT that support real-time operations.

   • Why it’s useful: Robots with complex actuation systems—like Tesla Bot, Swiss Mile quadrupeds, or Aescape’s massage robots—rely on precise timing for motor control and sensor fusion. These tasks require real-time capabilities that Ubuntu and other off-the-shelf Linux-based OSs do not natively support. Just use a kernel modification with Yocto!

Why Use Docker?

Now that we understand Docker and Yocto’s role in robotics, let’s discuss why you may want to use one or the other in your workflow. Let’s start with Docker.

Portability

A robotics development workflow involves a variety of simulation, testing, and production environments. Because Docker isolates runtime into containers, porting an application across these contexts is easy. This allows for consistent performance, reducing the confounding variables of running on bare metal.

Faster Dev Cycles

Speed is everything in robotics development. Imagine you’re testing a change to your robot’s perception module. Waiting 10 minutes for your system image to rebuild for every tweak would be maddening.

Docker solves this by using prebuilt, cached images. Instead of a full rebuild, you can pull a mostly cached container in say, 30 seconds. Over the life of a project, those seconds add up!

Flexibility with Hardware Upgrades

Over a robot's lifetime, its hardware spec will evolve—whether upgrading to the latest Jetson board or switching architectures from ARM64 to x86.

Yocto requires a custom build for each hardware configuration, which can be a painstaking process whenever you change hardware. I’ve met teams who stayed on a board for generations longer than they wanted to because a new Yocto build would require too much development time.

Docker abstracts these dependencies, reducing both versioning and maintenance overhead.

Robust CI

The highest-fidelity testing you can get is running your software on a real robot. But let’s be honest: that’s slow and unscalable.

A better CI/CD approach is to frontload as much testing as possible in the cloud or simulation. Containers shine here—they let you automate testing, scale simulations, and run everything in parallel. By the time you’re ready to deploy, most issues are ironed out. Then, you can focus on high-value validation testing on the robot itself, where it matters.

Simplified Debugging

Diagnosing and reproducing bugs is much easier with Docker. Containers are fully reproducible and can be shared and run on any machine. This allows teams to collaborate on troubleshooting even when working across different workstations or environments.

The Docker Ecosystem!

Docker’s mature ecosystem offers an expansive library of open-source containers for common applications like databases, monitoring, and more. These pre-built images save you the effort of re-creating infrastructure, letting you focus on what matters: building differentiated software.

Why Use Yocto?

Let’s discuss some of the benefits that make Yocto an attractive solution.

Hardware-Specific Builds

From the device drivers to the computer, your robot has a unique configuration. Thanks to Yocto’s custom builds, you can design your Linux distribution to fit.

Optimized for Edge Devices

Robots operate with limited RAM, CPU power, and disk space while collecting massive amounts of data that can only be offloaded intermittently. Every byte counts.

Yocto strips away unnecessary components, reducing memory and CPU usage while improving boot times.

Real-Time Capability

Robotic applications with strict timing requirements need deterministic execution, which Ubuntu does not offer.

Integrate a real-time kernel modification with Yocto to unlock this capability!

Long-Term Control

Robots are deployed in the field for months or even years, making complete control over your operating system essential. A custom Yocto Linux means you’re no longer subject to any 3rd party software release/update cycle.

If Ubuntu ships a version release (e.g., 22.04 to 24.04), this update can break dependencies, introduce device driver incompatibility, or change kernel behavior.

A Yocto build is more likely to be stable for the life of your project.

Enhanced Security

Device security is paramount, especially for robots operating in safety-critical environments. Embedded systems have numerous attack vectors, making this task difficult.

Ubuntu provides security features like signed binaries and encrypted root filesystems, but its unnecessary components widen the attack surface. A custom Yocto build eliminates these components while allowing you to implement these mechanisms.

Board Support Packages (BSPs)

Though much of the Yocto process is do-it-yourself, BSPs reduce the development effort needed. BSPs are a pre-configured set of files, drivers, kernel, and middleware designed for a specific ‘board’ (Raspberry Pi, Jetson, among others).

BSPs serve as the “base layer” for the image. The Yocto ecosystem provides a variety of open-source BSPs.

Over-the-Air OS Updates

Docker primarily operates at the application layer, so you must build separate infrastructure to update your OS or other lower-level software over the air (OTA).

Fortunately, Yocto supports OTA OS updates. You can choose between approaches like image updates (swupdate), partition updates (mender and RAUC), or OSTree.

When to use Docker vs. Yocto?

Let’s summarize when to use Docker vs. Yocto. Of course, every design decision has its tradeoffs, so we’ll also discuss those.

Where Docker Wins

• Prototyping: In the early stages of a robotics project, you can’t afford to sink time into a custom build system. You need to validate your application and move on quickly. Containers are perfect for an iterative cycle between your workstation and robot.

  • Tradeoff: While skipping any packaging work and building directly from source can speed up prototyping, it introduces dependency management headaches later in the workflow.
    
    

• Collaborative Workflow: Robotics teams often have engineers working across diverse contexts, from simulation and hardware-in-the-loop (HIL) setups to actual robots. Docker’s portability allows seamless handoffs between teammates and contexts.
  
  

• Frequent Updates: Following an agile SDLC requires the infrastructure for bi-weekly updates. Docker makes application updates simple.

  • Tradeoff: Docker can’t perform updates for the OS or other low-level dependencies.

Where Yocto Wins

• Production-Grade: Yocto is great for building production-grade system images. Without reliance on third-party vendors, you maintain full control, security, and long-term stability.

  • Tradeoff: Yocto has a STEEP learning curve. Expect to invest significant time learning Yocto before your system image runs successfully.
    
    

• Resource-Constrained Devices: For edge devices with limited CPU, RAM, and storage, Yocto eliminates unnecessary software components, minimizing resource usage and improving system performance

  • Tradeoff: These builds are hardware-specific, making reusing them across different devices difficult.
    
    

• Real-Time Needs: If your device requires real-time or deterministic operations, Yocto is the best way to modify your kernel to support this.

Docker and Yocto are NOT Mutually Exclusive!

Throughout this blog, we’ve compared Docker and Yocto, and given you criteria to decide between them. This is a false dichotomy! Though most teams use them independently, Docker and Yocto are not mutually exclusive, and a hybrid approach can work splendidly!

In a hybrid approach, Yocto is used to package the OS and lower-level dependencies. This delivers a custom, highly performant system image with the ability to implement over-the-air (OTA) updates for your OS.

Docker complements this by handling your application software. Since application updates are far more frequent than OS updates, Docker’s ease of use becomes invaluable.

Configuring a Yocto build alongside Docker images requires a significant upfront investment. However, this hybrid system has a high ROI in production.

Thanks for reading! I hope this blog helped you decide how to package software for your next robotics project.

Best of luck, and I can’t wait to see what you build.

Miru provides infrastructure for robotics teams to easily deploy software updates over-the-air (OTA). If you don't want the headache of building this yourself, reach out!