<div dir="ltr">Hi Bill,<div><br></div><div style>Our current approach at Clearpath is to install the launchers for Husky in:</div><div style><br></div><div style>/etc/ros/fuerte/husky/core.d</div><div style><br></div><div style>

And then the system launch shell script (installed to <font face="courier new, monospace">/usr/sbin/husky-core-start</font>, like Turtlebot's) generates a launch file which includes everything it finds in there. We're finding that this is typically enough information for our purposes—software can figure out which version of ROS is installed by <font face="courier new, monospace">ls /etc/ros</font> which robot it's setup for by <font face="courier new, monospace">ls /etc/ros/fuerte</font>, and which payloads are included by <font face="courier new, monospace">ls /etc/ros/fuerte/core.d</font>. (More about this in our <a href="https://github.com/clearpathrobotics/clearpath_husky/tree/master/husky_bringup/upstart">husky_bringup</a> package.)</div>

<div style><br></div><div style>This is not necessarily a vote against. But it would be helpful to have more of the following included in the REP:</div><div style><br></div><div style>- Individual justification for the inclusion of each piece of data.</div>

<div style>- Justification for their duplication when available (or inferable from) elsewhere.</div><div style>- What about including info on what cores get launched, and their ROS_MASTER_URIs?</div><div style>- Justification for the bash-style X=Y format versus a) the established ROS standards of yaml and xml or b) the more (imo) unix-y approach of making ros/robot-release directories, and the fields individual files that can then be trivially catted into other scripts.</div>

<div style><br></div><div style>A larger structural concern is that many of the robots we ship are heavily customized with user payloads, including arms, multiple vision systems, etc. The software for these elaborate configs end up being a mishmash of CPR-written stuff, public drivers, and CPR forks of public code. <b>It's difficult to conceive of boiling all that down to a simple field like "DOF", in any kind of way that would provide actual value to other tools.</b> It almost seems like it might be more useful to have the release file declare a list of packages which together make up the "config", and then each of those include a file that declares the particular attributes that they contribute to the whole (so, husky_node contributes a differential drive train, imu_um6 and nmea_gps_driver contribute position estimation, RCPRG_laser_drivers and openni_kinect contribute vision, etc). But is this reinventing the wheel—can the existing diagnostics or parameters or manifest infrastructure solve the problem this is trying to solve?</div>

<div style><br></div><div style>Additionally, for whatever is ultimately gone with, <b>it would be helpful to have available right out of the gate a basic validator</b>; something which can assist vendors in knowing whether they have complied with the recommended practice. This could take the form of a diagnostics publisher, so the info turns up GUIs and gets included in bag files. Another possibility would be an end user cli tool, perhaps something like robot_info, which could work like so:</div>

<div style><br></div><div style>$ rosrun robot_info robot_info</div><div style>Robot: Clearpath Robotics Husky</div><div style>ROS version: Fuerte</div><div style>Drive Type: Differential (on /cmd_vel)</div><div style>Max Speed: 1.2 m/s</div>

<div style>ROS cores:</div><div style>  main: <a href="http://192.168.1.1:11310">http://192.168.1.1:11310</a> (running)</div><div style>  public: <a href="http://192.168.0.101:11311">http://192.168.0.101:11311</a> (stopped)</div>

<div style><br></div><div style>Anyhow, my example is getting into some assumptions about multimaster, private/public topics, etc, but I'm providing it less to open that discussion and more as an example of how the concept of ros-release/robot-release files could bring value to Clearpath and our users.</div>

<div style><br></div><div style>Mike</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 1 February 2013 03:39, Bil Morris <span dir="ltr"><<a href="mailto:bill@iheartengineering.com" target="_blank">bill@iheartengineering.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello ROS Users,<br>
<br>
We have been working on ROS system integration and we have produced a<br>
draft REP of some config files that we think would be useful for other<br>
robot hardware vendors to integrate into their process.<br>
<br>
Abstract<br>
----------<br>
Robots with ROS installed at the system level have different<br>
requirements from users manually starting and stopping a ROS<br>
installation they built themselves. This REP describes file formats for<br>
storing information about these robotic systems. This will provide users<br>
and applications with a source of information that is common across<br>
robot hardware platforms and software installations.<br>
<br>
<a href="https://github.com/IHeartRobotics/ros-reps/blob/master/rep-rsi.rst" target="_blank">https://github.com/IHeartRobotics/ros-reps/blob/master/rep-rsi.rst</a><br>
<br>
<br>
Thanks,<br>
Bill<br>
----<br>
I Heart Engineering<br>
<3<br>
_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</blockquote></div><br></div>