<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Hi everyone,</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>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:<br>
<br>
<a href="http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/examples/ros/snapcraft.yaml" target="_blank">http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/examples/ros/snapcraft.yaml</a><br>
<br>
That will then bundle the ROS install and the two binaries all into a single snap.</div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>
What problems did the size cause? Were you running out of disk space or was the download difficult?</div></blockquote><div><br></div><div>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). </div><div>Besides the size of the snaps, right now, I also have to admit that doing ROS development in Snappy is extremely time consuming.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><span class=""></span>
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. </div></blockquote><div><br></div><div><div>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.</div><div><br></div><div><div>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.</div></div><div><br></div><div><div>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 <u>depend on each other</u>. This is critical for expanding the capabilities of  our robots by installing different snaps. </div><div>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 <a href="http://wiki.ros.org/rosbash">rosbash</a> tools installed within Snappy so that they can inspect ROS abstractions.</div></div><div><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>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.<br></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><span class=""><br></span>
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.</div></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><b>Víctor Mayoral Vilches</b><div>CTO & Co-Founder</div><div><br></div><div><img src="http://erlerobotics.com/blog/wp-content/uploads/2014/10/erle_corporativo_5.0_72px_nobackground.png" width="96" height="96"><br></div><div><br></div><div><b>Erle Robotics</b></div><div><a href="http://erlerobotics.com/" target="_blank">erlerobotics.com</a> | <a href="mailto:victor@erlerobot.com" target="_blank">victor@erlerobot.com</a></div><div>+34 616151561<br></div><div><i>skype</i>: v.mayoral<br></div><div> </div></div><br></div></div>