Skip to content
ROS Discourse — Community updates· Craig_Lawton-Devine·· 4 days agoEditorial score35

ROS Discourse Community Questions Adoption of Ubuntu Snaps for Robot Fleets

What happened to "Robot-as-a-Snap"?

Summary

The ROS Discourse community discusses the limited adoption of Canonical's Ubuntu Snap ecosystem despite its atomic update features, contrasting it with common alternatives like Docker or Yocto. Contributors ask why strict confinement and iteration friction may hinder widespread use in production robotics deployments.

Source: ROS Discourse — Community updates · Read original article ↗

Article text · Original source · English

If you’re building on ROS 2, odds are you’re running Ubuntu. It’s the default for almost everyone. Over the last few years, Canonical has put a ton of engineering effort into pushing an Ubuntu Robotics ecosystem built around Snaps and Ubuntu Core.

On paper, it sounds like a dream setup for production robots:

  • Atomic & Transactional Updates: Ubuntu Core gives you atomic OS updates and transactional Snap updates. If an update breaks midway through, it automatically rolls back instead of bricking a robot in the field.

  • Version Linking: You can link snap dependencies across versions so you know everything is compatible before triggering an update across the fleet.

  • Built-in ROS 2 Tooling: Snapcraft has ROS 2 extensions and build plugins ready to go out of the box.

  • Observability & Fleet Management: Hooks into the Canonical Observability Stack (Telegraf, Prometheus, Loki) for real-time telemetry, plus Landscape to manage snap versions across your fleet.

Yet, despite all this tech being around for years, there’s surprisingly little chatter about it in the ROS 2 community. On Discourse and in forums, I rarely see people asking questions, sharing setups, or recommending snaps for production.

Instead, when people talk about shipping robots, it usually comes down to:

  1. Standard apt on Ubuntu Server: Easy to set up, but updates are fragile. A failed apt upgrade can easily leave a robot in a broken state out in the field.

  2. Docker: Great for bundling dependencies, but configuring hardware passthrough for heavy GPU workloads like VSLAM or LLMs can add friction.

  3. Yocto / Custom Embedded Linux: Gives you total control and clean atomic updates, but now your team is stuck maintaining every single system package.

Where’s the catch?

Why hasn’t the snap ecosystem become the standard way to reliably deploy software onto robot fleets?

  • Is strict confinement getting in the way of hardware access (like passing through GPUs for VSLAM/LLMs, direct serial, GPIO, or cameras)?

  • Is the developer iteration loop just too clunky compared to plain workspace builds?

  • Or are people just happier sticking with Docker or Yocto despite the maintenance headaches?

Curious to hear from anyone deploying ROS 2 in the wild: What are you actually running on your fleet, and what kept you on (or off) Snaps and Ubuntu Core?

What the source reports

Publisher-reported claims, with original evidence. These results have not been independently verified by RoboSignal.

  • paper: not_reported
Source excerpts and review record

Automatically extracted; no manual editorial approval recorded.

Source:ROS Discourse — Community updates · discourse.openrobotics.org

Timezone · UTC

Article dates follow your selected timezone. Briefing editions use Hong Kong time (UTC+8).