Frameworks in Ubuntu Core

Ted Gould ted at ubuntu.com
Tue Oct 20 20:20:52 UTC 2015


On Tue, 2015-10-20 at 18:09 +0000, Gianluca Bardaro wrote:

> I already found two different solution that use the approach of
> creating a single snap for ROS and the nodes:
> -
> http://www.piware.de/2015/01/snappy-package-for-robot-operating-system-tutorial/
> - https://github.com/erlerobot/ros2snap
> The second one is derived from the first.


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:

http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/examples/ros/snapcraft.yaml

That will then bundle the ROS install and the two binaries all into a
single snap.


> 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.


What problems did the size cause? Were you running out of disk space or
was the download difficult?


> 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.


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.


> 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.


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20151020/246918a9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20151020/246918a9/attachment-0001.pgp>


More information about the snappy-devel mailing list