ROS architectures with snaps

Choosing the right architecture can be hard, but we want to help. In this blog, we’ll look at different architectures and their pros and cons. We’ll also show you how to apply the chosen architecture to a mobile robot software stack with three essential apps. With this blogpost, we will see the different ROS architectures with snaps.

ROS apps are generally designed to be modular. However, once the app is ready to deploy, this modularity may not be needed

If you use snaps to deploy your ROS or ROS 2 application, you might wonder if you should keep the app in one snap or split it into several. Although ROS apps are modular, you might not need that modularity once you’re ready to deploy. With snaps, you can choose to keep your app modular or make it more streamlined. 

ROS architecture – Monolithic snap 

The most common approach for a ROS application is to use monolithic architecture. This method involves shipping the complete software stack and application in one snap. It serves as the default architecture when the preferred architecture is unknown.

In our example, the monolithic architecture for our mobile robot application will look like this:

As you can see in the picture, the monolithic snap called “my-monolithic-snap” contains all the system and ROS dependencies. It also embeds the configurations and everything needed at run-time. Additionally, this single monolithic snap is exposing three applications. The three applications are communicating using ROS (Could be the network, shared memory, etc.).

Complexity, stability and size 

The primary advantage of this approach is that snaps bundle all necessary dependencies and applications into one package. It requires only one snapcraft.yaml to snap all applications. 

However, the snapcraft.yaml may still contain multiple parts in case some dependencies of the ROS workspace need to be built.

By having all binaries, libraries, configurations, and other components live inside the same snap, snaps ensure application stability. Since snaps are immutable, having everything in one snap makes an application more robust. Furthermore, when testing the snap, you can be confident that users or devices will experience the same behaviour. 

Having everything in one snap also eliminates the need to duplicate files or binaries across snaps, making it more space-efficient. 

Deployment and reusability 

However, introducing a change in the snap would require rebuilding the entire snap. This can be time-consuming for complex robotics applications. Due to changes in system libraries or even ROS ones, the final snap will likely differ significantly from the original one. Even with delta updates, updating the snap will most likely be in the order of magnitude of the snap size.

Moreover, deploying a different robotics application using the same “Brain” (e.g., the same navigation stack, hardware controllers, etc.) would require building and distributing two completely different snaps. As a result, there is very little chance that such a monolithic snap will be deployed on another robot.

You can find a complete implementation of the TurtleBot3 as a monolithic snap on GitHub.

In summary, these are the pros and cons of the monolithic approach:

Pros

• Easy to set up and maintain
• Self-sufficient snaps
• Robust
• Space efficient

Cons

• Updates can be heavy to deploy on devices
• Reduce reusability
• Cannot be reused on another robot

ROS architecture – Multi-snap 

ROS has been designed with a modular approach in mind. This means that it is possible to maintain this modularity even when deploying robotics applications. By using the network, ROS and ROS 2 can exchange data, allowing two applications to communicate with each other via ROS, even if they are not located in the same snap. This means that a complete robot software stack is deployed over multiple snaps. The composite of these snaps represent the complete software stack of the robot.

In the case of our mobile robot application, the snap architecture will look like this:

As you can see in the picture, the “Brain” snap called “my-brain-snap” contains everything for the Brain app. Meaning that “my-brain-snap” is carrying its own ROS installation as well as dependencies. Additionally, the “my-patrol-snap” and “my-clean-snap” also carry their ROS installation and specific dependencies. The three apps are exposing their own applications working together communicating with each other with their ROS communication (topics, services, etc)

Complexity, stability and size 

Deploying in multiple snaps means multiple snapcraft.yaml to define, build and maintain. So going for the multi-snap architecture is going to mean more work to deploy a robotics application.

ROS 2 DDS default implementation, FastDDS, can use shared memory to exchange data. This happens when two DomainParticipant are on the same host. You can enable shared memory across multi-snap with the addition of an extra interface.

Deploying a complete robot software stack via a multi-snap setup requires careful consideration of compatibility and stability. Additional testing is needed to ensure that all the snaps work well together, especially when updating them. In case some snaps are no longer compatible with each other, you can usechannels to clarify the compatibility between snaps. Moreover, Ubuntu Core’s validation set prevents incompatible software installation on a device.

Deploying robot software via multiple snaps inevitably takes up more space on the disk since snaps still need to bundle all their dependencies. This means that splitting a robot software stack into multiple snaps may require shipping different snaps containing some common libraries (such as ROS base libraries).

Deployment and reusability 

Deploying robot software via multiple snaps inevitably takes up more space on the disk since snaps still need to bundle all their dependencies. This means that splitting a robot software stack into multiple snaps may require shipping different snaps containing some common libraries (such as ROS base libraries).

Updating one application (snap) without having to update all the other snaps that didn’t change could be a plus in bandwidth-constrained environments. However, users might not understand that multiple snaps are required to run an application. You can pair multiple snaps together for deployment via a private Snap Store or by creating a custom Ubuntu Core image.

One benefit of the multi-snap approach is that it brings reusability to the snaps. Developers can reuse one Brain snap for all the robots while deploying an “application” snap to enable a specific function on the robot. This allows to develop multiple application snaps, all of which work alongside the Brain snap, providing the basic functionality of a robot. The developed applications rely on the Brain of a particular robot. This Brain application is reusable on another robot, as long as the interface is standardised (same topic names, units, etc).

In summary, these are the pros and cons of the multi-snap approach

Pros

• Brings reusability for the snaps
• Allow modularity in applications
• Reduce update bandwidth cost in case of an update

Cons

• Less space efficient
• Potential snaps incompatibility
• Harder to maintain
• Might require additional interfaces
• Need coordination between the releases of the snaps

Review of ROS architecture with snaps

When choosing to deploy your robotics application with snaps, you can choose a monolithic or modular approach. A monolithic architecture will bundle the complete software stack and application in one snap. The multi-snap architecture will allow you to bundle the complete robot software stack over multiple snaps.

The monolithic approach is easy to set up and maintain but requires heavy updates and reduced reusability. The multi-snap approach allows for reusability and modularity but is less space-efficient and harder to maintain. It may also require additional interfaces and coordination between snap releases. 

Regardless of which ROS architectures with snaps you choose, using a private Snap Store or Ubuntu Core image will simplify the deployment. This can save you time and effort in the long run, and help ensure that your software is consistently available and up-to-date.

If you want to learn more about Snaps

Access our developer guide

• Visit our documentation page
• Learn the benefits and how you can migrate your docker application to snaps.