<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/4.8.5"> </HEAD> <BODY> On Tue, 2015-10-20 at 18:09 +0000, Gianluca Bardaro wrote: <BLOCKQUOTE TYPE=CITE> I already found two different solution that use the approach of creating a single snap for ROS and the nodes: - <A HREF="http://www.piware.de/2015/01/snappy-package-for-robot-operating-system-tutorial/">http://www.piware.de/2015/01/snappy-package-for-robot-operating-system-tutorial/</A> - <A HREF="https://github.com/erlerobot/ros2snap">https://github.com/erlerobot/ros2snap</A> The second one is derived from the first. </BLOCKQUOTE> Our thinking has evolved a little since then, as we're now using Snapcraft to build ROS snaps. It has landed in trunk and will be in the next release of Snapcraft. You can see an example of a listener and talker in the Snapcraft examples folder: <A HREF="http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/examples/ros/snapcraft.yaml">http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/examples/ros/snapcraft.yaml</A> That will then bundle the ROS install and the two binaries all into a single snap. <BLOCKQUOTE TYPE=CITE> I did some toy examples using this approach, I created two different app that can communicate using the ROS communication system. The main problem was the size of each single snap, since each one has to include the entire ROS framework. </BLOCKQUOTE> What problems did the size cause? Were you running out of disk space or was the download difficult? <BLOCKQUOTE TYPE=CITE> That's why I tried to create a framework containing only ROS. From a certain point of view ROS is the perfect candidate to be a framework. It provides some shared resources (like roscore that coordinates all the nodes and a shared parameter server) and a communication layer. The "problem" is it provides also some libraries to creates nodes. I suppose I could minimize the size of each app by carefully select only the necessary libraries and hopefully obtain something of a reasonable size. </BLOCKQUOTE> The problem with including the library inside the framework is that suddenly you're starting to make a choice about which version every app on the system has to use. If they have a bug fix or patch that effects them, but is considered not important for the framework, they can't get it for their app. Also, it makes deploying and testing apps more difficult as their behavior can change depending on the other snaps that are installed on the system. Neither of these are desirable traits. While it makes sense to do shared maintenance of dependencies, and the reason orgs like the OSRF exist, it is also important to build a system where developers can expect their software work consistently. We've got lots of ideas on how to handle the cases of Snaps that are large to optimize the disk space and download time. Right now they're optimizations that we haven't fully explored. <BLOCKQUOTE TYPE=CITE> Our hypothetical use case was, for example: Think about having a fleet of ten drones, or maybe a swarm of ground robot, you want to test multiple localization system, each one maybe based on multiple ROS nodes. You can create multiple apps containing all the different systems and swap or deploy them easily on all the robots simultaneously. In our opinion breaking the architecture in multiple apps make the system more flexible and easier to manage, even more when multiple people work on different part of the same architecture. This is useful even if you don't have the problem of deploying software on multiple robots. </BLOCKQUOTE> A snap is really more of an integration point, in that it can pull in software from multiple sources to make the final snap. So for instance teams could work in their own version control system, making their own releases, and then pull all of those into a single snap for a particular robot or use-case. The deployment breakup doesn't have to match 1:1 with the development division of labor. Ted </BODY> </HTML>