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.
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.
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.
I am not familiar with Chef. Do you think it could be helpful in such a
situation?
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.
Do you also build all your in house non-ROS-dependencies as debs?
Best Regards
Georg
> Mike,
>
> 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!
>
> -Ryan H.
>
> On Wed, Mar 4, 2015 at 5:19 AM, Mike Purvis
> <mpurvis@clearpathrobotics.com <mailto:mpurvis@clearpathrobotics.com>>
> wrote:
>
> 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:
>
> * Everything on the robots is installed from debs, from a
> combination of packages.ros.org <http://packages.ros.org>
> (buildfarm) and packages.clearpathrobotics.com
> <http://packages.clearpathrobotics.com> (in-house buildbot-ros
> builds).
> * 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.
> * The homedir is populated with a README file explaining how to
> create a workspace with a new package in it...
> * ... 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.
> * Because all the "system" software is installed from debs,
> upgrading is a fairly sane update/dist-upgrade story.
> * 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.
> * 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).
>
> 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.
>
> 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
> mpurvis@clearpathrobotics.com <mailto:mpurvis@clearpathrobotics.com>
>
> M.
>
> On 4 March 2015 at 07:42, Jonathan Bohren
> <jonathan.bohren@gmail.com <mailto:jonathan.bohren@gmail.com>> wrote:
>
> 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 http://rosindex.github.io
>
> https://github.com/rosindex/rosindex/issues/142
>
> -j
>
>
> On Wed, Mar 4, 2015, 03:44 G.A. vd. Hoorn - 3ME
> <g.a.vanderhoorn@tudelft.nl
> <mailto:g.a.vanderhoorn@tudelft.nl>> wrote:
>
> All,
>
>
> just wondering whether we should somehow clarify what the
> current 'best
> practices' are for installing packages onto a ROS pc. I
> see a lot of
> people that assume that building from source (after
> cloning from a
> repository) is _the_ way to do things.
>
> Apart from the fact that this is essentially a waste of
> time and effort,
> it also often leads to problems (as they forget to check
> for and / or
> install all dependencies first), which then results in
> numerous ROS
> Answers questions. Having the sources locally also seems
> to invite some
> users to start editing / hard coding parameters (such as
> IPs / serial
> ports) into nodes, which is obviously unwanted.
>
> Somehow I have a feeling that the prominent placing of the
> repository
> URL in the Package Summary contributes to the confusion.
>
> Would it perhaps be an idea to add a one-liner to the
> 'Package Summary'
> on wiki pages of released packages that shows users how to
> install it
> ("Installation: sudo apt-get install
> ros-$release-pkg-name", although
> that is distribution specific)? Or a link to a (new) wiki
> page that
> explains how to install packages in general (with the
> from-source option
> shown last)?
>
>
> Gijs
> _______________________________________________
> ros-users mailing list
> ros-users@lists.ros.org <mailto:ros-users@lists.ros.org>
> http://lists.ros.org/mailman/listinfo/ros-users
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@lists.ros.org <mailto:ros-users@lists.ros.org>
> http://lists.ros.org/mailman/listinfo/ros-users
>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@lists.ros.org <mailto:ros-users@lists.ros.org>
> http://lists.ros.org/mailman/listinfo/ros-users
>
>
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
--
.........................................................
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
heppner@fzi.de
www.fzi.de
.........................................................
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
.........................................................
_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users
(text/plain)