ROS Resources: Documentation | Support | Discussion Forum | Service Status | Q&A answers.ros.org

Ubuntu Core and snap packages in production

Hi!

I’ve been wondering if anyone in the community has experience of using snap packages in their ROS enabled projects? I’ve been trying really hard to find some projects but didn’t succeed in finding anything else than couple of blog posts.

Did anyone of you evaluate using snaps in robotics? Are there any huge advantages or disadvantages one should be aware of?

Thanks in advance for any advice you might offer!

I have no sources for what I’m gonna say but I remember connecting ROS components with snaps was impossible/a pain. As snaps were by default isolated (like a Docker image if you use Docker) you could not connect, say, a snap running roscore and a snap running something else like the navigation stack.

Maybe things got fixed with time, but I haven’t heard more about.

There is a related post from last year: From ROS prototype to production on Ubuntu Core in case you are interested.

I’ve looked into it, but not actually tried it.

I’ve been following this set of tutorials to get to know snap better. After following it and going through some pains (e.g. serial port access, build times on armhf platform) I started to wonder what other people have experienced.

I can see how snap, if project is architectured right, can solve some of the deployment issues however for development it seems like a lot of burden, especially in cases where you want to develop in incremental steps and test on the robot as you go.

I would imagine, after following the tutorials, you would need to put all the nodes that you require in a single launch file. This could work but doesn’t seem too modular.

Hey there @msadowski, thanks for opening a thread! I’m a ROS nut, but also one of the snapcraft maintainers, so I hope that I can answer your questions.

This was true in the past, but less so today. Please see this write-up. I’ll admit it’s still not the easiest thing, but I know of a few companies using it.

Yeah, it’s a bit like packaging your ROS system as debs just in order to test on the robot: no one really does that either. Put any sort of packaging step in the development iteration loop and things slow down pretty quickly. Snaps are currently very much a deployment/update tool (get a prototype working outside of snaps, then productize it using snaps). We’re actually working on making iteration a lot better this cycle, and you’ll see some improvements already in the next release, but we’re not there yet. It will still never be as easy as just running from source, though.

I know slightly of topic: For ROS2 the whole procedure should be way easier right?

Excellent question! Indeed, since roscore is no longer necessary for handshaking, splitting nodes between snaps becomes far easier. ROS2 still uses workspaces, though, so it’s not as clean as it could be. Depending on how things are configured, you may still end up needing to split a workspace between multiple snaps.

Thanks for the write up, it’s really helpful! I can’t wait to see what you will come up with next with Snap and ROS! If there was a way to have incremental builds I think this could allow for using snaps even during the development (although I can imagine it would be quite difficult to pull off).

1 Like