Skip to main content

Your submission was sent successfully! Close

Thank you for signing up for our newsletter!
In these regular emails you will find the latest updates from Canonical and upcoming events where you can meet our team.Close

Thank you for contacting us. A member of our team will be in touch shortly. Close

An error occurred while submitting your form. Please try again or file a bug report. Close

  1. Blog
  2. Article

gbeuzeboc
on 27 April 2023


Welcome to Part 6 of our “Optimise your ROS snap” blog series. Make sure to check Part 5. This sixth and final part will  summarise every optimisation that we did. We will provide a critique for every optimisation that we tried along this series of blogs.

Finally, we have reached the last part of this blog post series exploring how to optimise ROS snaps. Now it’s time to conclude on our results. This series of blogs was inspired by various other blogs posted on the ubuntu.com/blog website.

What we learned about ROS snap optimisation

Throughout these blog posts, we tried various ways to improve our snap in terms of time or space. While some optimisations only had benefits (Compiling in Release, removing unnecessary files, cleaning up content-sharing duplicates) some other optimisations would need particular care and awareness. Optimising a snap shouldn’t compromise its stability, after all, snaps are also made for resilience.

A snap that would receive very few updates and benefit from a lot of testing could leverage some of the most ambitious optimisations.

None of the optimisations that we applied here are specific to ROS, so we should feel free to experiment these on other snaps.

Also, we must keep in mind that snap packages bundle all their dependencies. This means we will never make them as small as a package technology that relies on other packages as dependencies (like Debian packages). Snaps are completely self-contained. They offer stability and a universal Linux packaging format but cannot have all the benefits of other package formats.

All the optimisations that we presented in this blog post series are available on the branch feat/optimization in the gazebo_snap repository. Since we did not apply all of them to the Gazebo snap, the ones actually used were merged in the gazebo_snap GitHub repository. If you have any feedback or ideas regarding the optimisation of ROS snaps or snaps in general, please join our forum and let us know what you think. Furthermore, have a look at the snap documentation if you want to learn more about snaps for robotics applications. The developer guide will come handy to learn how to deploy robotics applications with snaps.

You might also be interested in:

What we learned about ROS snap optimisations is that there are various ways to optimise a snap. The optimisation from Part 2 should be widely used while the rest depends on each case. Because of how ROS Debian packages are defined and depend on each other, a ROS snap carries a lot of files and packages that are necessary for our applications. Hopefully this blog post series helped you understand what files are packed in a snap and the different ways to optimise their size.

Results summary

Here we will find a table of all the results. This way, we can quickly compare. As an example, with the optimisations we applied to the Gazebo snap available on the Snap Store we have reduced its size by more than 40%. Since snaps automatically update, we freed 333 MB on systems that had the previous version without optimisations.

Gazebo snapCold startHot startRTF.snap sizeInstalled snap size
Debug without content sharing6.513.550.35890 M4.0 G
Debug6.403.510.35661 M2.8 G
Release6.062.724.39232 M758 M
Initial clean-up6.022.734.67211 M674 M
Remove useless Debians6.092.754.36193 M626 M
Cleanup content sharing duplicates6.032.764.29119 M427 M
Ld-cache6.072.743.96119 M 427 M
XZ compression6.973.714.0386 M427 M
Extreme trimming5.672.744.1439 M115 M
Extreme trimming + XZ compression6.963.754.1429 M115 M

Thank you for optimising the Gazebo snap with us, you can read the different parts of this blog post series following the different links:

Part 1 of this series will present the possible problems ROS snap might face, as well as the methodologies to measure it.

Part 2 of this series will present the optimisations already present in our Gazebo snap.

Part 3 of this series will present safe optimisations consisting of removing duplicates and unnecessary files.

Part 4 of this series will present the dynamic library caching optimisation.

Part 5 of this series will present alternative compressions as well as a risky but efficient optimisation.

If you have any feedback, questions or ideas regarding ROS snap optimisations, please join our forum and let us know what you think. Furthermore, have a look at the snap documentation if you want to learn more about snaps for robotics applications.

Related posts


gbeuzeboc
25 September 2024

TurtleBot3 OpenCR firmware update from a snap

IoT Article

The TurtleBot3 robot is a standard platform robot in the ROS community, and it’s a reference that Canonical knows well, since we’ve used it in our tutorials. As a matter of fact, we use it to demonstrate some of our work, such as distributing a ROS stack through snaps. This robot embeds two boards, a ...


Gabriel Aguiar Noury
20 August 2025

Canonical is now a platinum member in the Open Source Robotics Alliance

Robotics Article

Ubuntu is the home of ROS. The very first ROS distribution, Box Turtle, launched on Ubuntu 8.04 LTS, Hardy Heron, and since then, Ubuntu and ROS have grown hand in hand. With every Ubuntu LTS release, a new ROS distribution follows, an intentional alignment that ensures ROS works out of the box on Ubuntu Desktop, ...


ROS Noetic is EOL – take action to maintain fleet security

Robotics Article

As of May 2025, the Robot Operating System (ROS) Noetic Ninjemys officially reached its end of life (EOL). First released in 2020 as the final ROS (1) distribution, ROS Noetic has been the default choice for thousands of developers building on Ubuntu 20.04 LTS. For developers and businesses running mission-critical systems on ROS Noetic, ...