Frameworks in Ubuntu Core

[Víctor Mayoral Vilches]

Hi everyone,


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

Ted, it's great what's happening with snapcraft and we already shared our
good feelings about it as a meta-build system proving support for catkin
(and maybe ament in the short term?). Thanks for putting time into these
simple examples of ROS with Snappy. They've are really useful.


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

Size actually is a problem if we think of extending a robot's behavior with
snaps. The main reason why we haven't pushed ROS snaps to the store is
because it doesn't make sense to have a 200 MB simple ROS package (or even
50 MB if we manually strip it down). Updating it wirelessly sounds even
less plausible (which is what really excites me).
Besides the size of the snaps, right now, I also have to admit that doing
ROS development in Snappy is extremely time consuming.

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

Your reasoning here makes sense from the Snappy perspective, still, as a
roboticist using ROS, my view is not far from what Gianluca proposes and i
believe i've shared this before. I tend to split my software in separate
parts (ROS packages) that will have dependencies as. This is the ROS
approach and it'll take quite a bit to make a change here (community-wise),
specially in the research community.

We've been doing a lot thinking on how to structure our code so that it's
reusable to other snaps and only came up with hacks that will never be
accepted in the store.

It's important to highlight here that when we design software for robots
using ROS, we build on top of this concept of distributed software pieces
that may *depend on each other*. This is critical for expanding the
capabilities of  our robots by installing different snaps.
So if I were to create certain functionality and expose it through set of
new ROS topics, I'd probably expect to access these ROS topics from other
snaps in a later stage. Since ROS supports TCP/IP-based and UDP-based
communications, would it be possible to access ROS topics from other snaps?
Can I inspect the ROS  packages installed in the overall system? It'll
probably make sense to have rosbash <http://wiki.ros.org/rosbash> tools
installed within Snappy so that they can inspect ROS abstractions.

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

I completely disagree with this claim. The OSRF existence is not justified
by doing "shared maintenance of dependencies". It exists for many other
relevant matters and digging into the ROS community will actually show that
many ROS dependencies are maintained by ROS users.


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

I think this is quite the point. Deployment of software in commercial
robots can perfectly differ from how we develop it. While ROS is widely
being used among academy and industry, my personal feeling is that
deployment of ROS in commercial robots that don't expect to be extended is
something where Snappy can perfectly fit.


*Víctor Mayoral Vilches*
CTO & Co-Founder



*Erle Robotics*
erlerobotics.com | victor at erlerobot.com
+34 616151561
*skype*: v.mayoral
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20151021/52c71d30/attachment-0001.html>