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 (buildfarm) and 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

On 4 March 2015 at 07:42, Jonathan Bohren <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> 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
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