| ROS Resources: ROS Homepage | Media and Trademarks | Documentation | ROS Index | How to Get Help | Q&A Help Site | Discussion Forum | Service Status |
Hey everyone. In case you’re not familiar with snaps, they are a great way to package your robot’s ROS stack and update it transactionally without needing to host your own infrastructure. I’m writing today to let you know that the snapcraft CLI (the tool used to build snaps) recently gained support for ROS 2 Foxy Fitzroy. I wrote up a quick tutorial for how to get started:
I would love to get some mileage on that feature! Please feel free to ask any questions here.
this works fine! thanks 
quick question, using interface network means access(plug) to host network, right? So that it can publish and subscribe from and to other endpoints in the same network. I confirmed that ros2 topic echo /chatter on different machine can receive the data from ros2-talker-listener package.
Best,
That’s correct @tomoyafujita, the network interface controls access to the network. It’s closely related to network-bind– they’re often both required. You can experiment with sudo snap disconnect ros2-talker-listener:network and note that suddenly it’s not working anymore.
@kyrofa, thanks!
what about providing virtual bridge and virtual NICs to bind snap confinement like docker does as default?
In this case, only between snaps in the localhost can communicate each other, but not possible to go beyond physical NIC w/o port forwarding. The use case is to deploy the application for single system (not a distributed system). Considering security and development as an architecture, it would be better to divide application into multiple containers such as perception snap, path planing snap and motion control snap.
Sorry that I guess that this is not only for ROS but also any other frameworks. If you may know, could you share we we could do with it?
Best
@tomoyafujita as of today there’s no way to do that. Snaps focus on being application containers, where the isolation and confinement is very real, but light. For example, they don’t have their own private FHS, or their own network, or their own hardware devices; they access the host system but only in ways allowed by their confinement profile as determined by interfaces such as network and serial-port. As a result, snaps are a bit closer to the actual hardware than you’re probably used to with e.g. Docker.
That said, your desired flow would be possible with a unix socket shared between the snaps. I’m not sure offhand if DDS supports that, though.
How are IPC name spaces handled in snaps? Is shared memory transport between separate or duplicate snap application processes possible?
Yes, but as I understand it the backing file needs to be accessible under confinement by both snaps, so one will need to share it with the others. Similar to the unix socket example above (just grabbing /dev/shm is off limits in confinement).
I’m not sure offhand if DDS supports that, though.
I don’t think so, but thanks this helps.
backing file needs to be accessible under confinement by both snaps
I’ve not done this, but maybe just to bind the same inode and then use mmap with SHM. it should be accessible. (we understand there is security breach when we use shared memory between confinement.)
I vaguely recall that RTI Connext supports unix sockets. I’m dredging up a memory from 10 years ago, though, so I could be completely wrong, and I can’t find anything in the public documentation to verify that.
