<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Somwhat off topic from the original
subject but as it seems to be of interest and we recently also had
to deal with "how to ship this" I just want to add my experience
with the docker solution. <br>
As the system is mainly meant to be used (in the sense of turn it
on, not develop with it) by the customer docker seemed to be the
best solution. However, as we have multiple (mostly) identical
target systems that differ in the configuration we use a docker
container but also create a ros workspace in the user home where
we copy the relevant package out of the docker (that holds the
config) and then mount it back into the container. This allows for
persistent changes of the configuration files on the system while
keeping the "known" package structure. Combined with a small QT
GUI that allows the user to update the container with just a click
this seems to be working quite well so far. The update script asks
if it should overwrite the configuration package.<br>
The main problem with this solution is the increased overhead for
changes (other than the mapped configuration) as editing a docker
container is somewhat strange and it will of course be overwritten
again. Also as far as I understand docker it is meant as a non
persistent system and is somewhat encapsulated from the outside
world. So any changes by the user are pretty much out of the
question. <br>
I am not familiar with Chef. Do you think it could be helpful in
such a situation?<br>
<br>
In the development systems (Prototype Robots) this would not be an
option, however it has become good practice to provide a
startscript that is always at the home directory which is supposed
to bring up everything (first everything else, then run the
required ros launchfiles). This is probably not what you are
looking for but it has proven really helpful for developers that
need to operate a robot they are unfamiliar with quickly.<br>
<br>
Do you also build all your in house non-ROS-dependencies as debs?<br>
<br>
Best Regards<br>
Georg<br>
</div>
<blockquote
cite="mid:CAHYAc29Egq+mofCtD+v4S7h9Z19PoF+FimtrAVNgiLm_t-h3vw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<div dir="ltr">
<div class="gmail_extra">Mike,</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">I think this is where the Docker, and
the Chef solutions fit in well. At the core of the problem,
you are effectively describing a configuration management
issue. Docker makes it easy to ship a pre-built and
pre-configured set of things -- and the Chef solution allows
to abstract the process into a DSL. They both have their pros
and cons, but I think they are not mutually exclusive either.
I am very interested in this discussion, so if you have a
private thread going please loop me in! </div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">-Ryan H.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">On Wed, Mar 4, 2015 at 5:19 AM, Mike
Purvis <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mpurvis@clearpathrobotics.com"
target="_blank">mpurvis@clearpathrobotics.com</a>></span>
wrote:<br>
<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 dir="ltr">As an OEM who ships a lot of robots to
first-time ROS users, one of the things I/we have
thought about at Clearpath is exactly how to configure
the robots for the best combination of
ease-of-production on our side, ease-of-getting-started
on the user's side, and ease-of-maintenance on the
user's side. The current state of affairs is:
<div>
<ul>
<li>Everything on the robots is installed from debs,
from a combination of <a moz-do-not-send="true"
href="http://packages.ros.org" target="_blank">packages.ros.org</a>
(buildfarm) and <a moz-do-not-send="true"
href="http://packages.clearpathrobotics.com"
target="_blank">packages.clearpathrobotics.com</a>
(in-house buildbot-ros builds).</li>
<li>An /etc/ros/setup.bash file falls through to
/opt/ros/indigo/setup.bash. This is what is
sourced for the robot_upstart job which brings up
the base software.</li>
<li>The homedir is populated with a README file
explaining how to create a workspace with a new
package in it...</li>
<li>... and further how to change that "master"
setup.bash, in the event that your new package
contains nodelets, plugins, or things you want to
launch as part of the robot_upstart background
job.</li>
<li>Because all the "system" software is installed
from debs, upgrading is a fairly sane
update/dist-upgrade story.</li>
<li>But, if there's a repo of special customization
launchers/URDF/whatever that's specific to that
one platform, it is configured as a package and
placed in a source workspace in the homedir.</li>
<li>The desktop and simulator software is also
distributed as debs, and so provide a sane story
for getting started on the user's supporting
computer (but if the user wants the meshes or
other stuff from a customization package, it must
be manually copied over, le sigh).</li>
</ul>
<div>We also resell a number of other vendors'
products, and many do not make it any farther than a
source workspace for everything— often with a manual
apt-get step for dependencies (rather than using
rosdep). On the one hand, this is perhaps easier for
hacking on and exploring the platform's own
software, but it sucks for pretty much everything
else.</div>
<div><br>
</div>
<div>Anyhow, if anyone's interested in these issues or
has thoughts about how to improve the state of
affairs for OEMs or users of OEM robots, please get
in touch off-list, would love to discuss further; at
some point we could also consider establishing a SIG
for vendors. In any case, I can be found at <a
moz-do-not-send="true"
href="mailto:mpurvis@clearpathrobotics.com"
target="_blank">mpurvis@clearpathrobotics.com</a></div>
</div>
<div><br>
</div>
<div>M.</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 4 March 2015 at 07:42,
Jonathan Bohren <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:jonathan.bohren@gmail.com"
target="_blank">jonathan.bohren@gmail.com</a>></span>
wrote:<br>
<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">
<p dir="ltr">I think this is a great idea. I can't
say the likelihood that this gets added to the
wiki, but I'd be happy to accept a PR to add this
to <a moz-do-not-send="true"
href="http://rosindex.github.io" target="_blank">http://rosindex.github.io</a></p>
<p dir="ltr"><a moz-do-not-send="true"
href="https://github.com/rosindex/rosindex/issues/142"
target="_blank">https://github.com/rosindex/rosindex/issues/142</a></p>
<span><font color="#888888">
<p dir="ltr">-j</p>
</font></span>
<div>
<div>
<br>
<div class="gmail_quote">On Wed, Mar 4, 2015,
03:44 G.A. vd. Hoorn - 3ME <<a
moz-do-not-send="true"
href="mailto:g.a.vanderhoorn@tudelft.nl"
target="_blank">g.a.vanderhoorn@tudelft.nl</a>>
wrote:<br>
<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">All,<br>
<br>
<br>
just wondering whether we should somehow
clarify what the current 'best<br>
practices' are for installing packages onto
a ROS pc. I see a lot of<br>
people that assume that building from source
(after cloning from a<br>
repository) is _the_ way to do things.<br>
<br>
Apart from the fact that this is essentially
a waste of time and effort,<br>
it also often leads to problems (as they
forget to check for and / or<br>
install all dependencies first), which then
results in numerous ROS<br>
Answers questions. Having the sources
locally also seems to invite some<br>
users to start editing / hard coding
parameters (such as IPs / serial<br>
ports) into nodes, which is obviously
unwanted.<br>
<br>
Somehow I have a feeling that the prominent
placing of the repository<br>
URL in the Package Summary contributes to
the confusion.<br>
<br>
Would it perhaps be an idea to add a
one-liner to the 'Package Summary'<br>
on wiki pages of released packages that
shows users how to install it<br>
("Installation: sudo apt-get install
ros-$release-pkg-name", although<br>
that is distribution specific)? Or a link to
a (new) wiki page that<br>
explains how to install packages in general
(with the from-source option<br>
shown last)?<br>
<br>
<br>
Gijs<br>
_______________________________________________<br>
ros-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:ros-users@lists.ros.org"
target="_blank">ros-users@lists.ros.org</a><br>
<a moz-do-not-send="true"
href="http://lists.ros.org/mailman/listinfo/ros-users"
target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
</blockquote>
</div>
</div>
</div>
<br>
_______________________________________________<br>
ros-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:ros-users@lists.ros.org"
target="_blank">ros-users@lists.ros.org</a><br>
<a moz-do-not-send="true"
href="http://lists.ros.org/mailman/listinfo/ros-users"
target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
_______________________________________________<br>
ros-users mailing list<br>
<a moz-do-not-send="true"
href="mailto:ros-users@lists.ros.org" target="_blank">ros-users@lists.ros.org</a><br>
<a moz-do-not-send="true"
href="http://lists.ros.org/mailman/listinfo/ros-users"
target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
ros-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a>
<a class="moz-txt-link-freetext" href="http://lists.ros.org/mailman/listinfo/ros-users">http://lists.ros.org/mailman/listinfo/ros-users</a>
</pre>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
.........................................................
M.Sc. Georg Heppner
Wissenschaftlicher Mitarbeiter Interaktive Diagnose- und Servicesysteme (IDS)
FZI Forschungszentrum Informatik
Haid-und-Neu-Str. 10–14
76131 Karlsruhe, Germany
Tel.: +49 721 9654-248
Fax: +49 721 9654-249
<a class="moz-txt-link-abbreviated" href="mailto:heppner@fzi.de">heppner@fzi.de</a>
<a class="moz-txt-link-abbreviated" href="http://www.fzi.de">www.fzi.de</a>
.........................................................
FZI Forschungszentrum Informatik am Karlsruher Institut für Technologie
Stiftung des bürgerlichen Rechts
Stiftung Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Prof. Dr. Andreas Oberweis, Prof. Dr. Ralf Reussner,
Jan Wiesenberger, Prof. Dr.-Ing. J. Marius Zöllner
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus
.........................................................</pre>
</body>
</html>