<div dir="ltr">Hi Bill, <div><br></div><div>I think that this is overall a good idea.  And the elements which are more or less direct parallels of the os-release fields look good.  However I think that the fields after the URL listings are not well enough defined to be put into a standard.  Most of the fields are unstructured and are not usable without a significant amount of additional information.  For example DOF cannot be useful w/o a urdf and said urdf will then be redundant with the field.  Many of the other fields feel like they will become tag clouds where one person defines their machine slightly differently and that seems to loose the value of being standard.  <div>

<br></div><div>Also I'd like to suggest that the distribution meta data be installed more like /etc/ros/groovy/  With the recommendation of having /etc/ros/distro symlinked to /etc/ros/groovy to mark groovy as the active distro because we can support multiple distros installed side by side.  </div>

<div><br></div><div>This also leaves space for other things that are distribution specific but need to be customized per robot.  In particular the core launch files and calibrated urdfs are distribution specific and I think might be better elements to consider in the scope of this REP. </div>

<div><br></div><div>Tully<div><div><br></div><div><br></div></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 1, 2013 at 9:46 AM, 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"><div class="im">On 02/01/2013 10:38 AM, Mike Purvis wrote:<br>
> Hi Bill,<br>
><br>
> Our current approach at Clearpath is to install the launchers for<br>
> Husky in:<br>
><br>
> /etc/ros/fuerte/husky/core.d<br>
><br>
> And then the system launch shell script (installed to<br>
> /usr/sbin/husky-core-start, like Turtlebot's) generates a launch file<br>
> which includes everything it finds in there. We're finding that this<br>
> is typically enough information for our purposes—software can figure<br>
> out which version of ROS is installed by ls /etc/ros which robot it's<br>
> setup for by ls /etc/ros/fuerte, and which payloads are included by ls<br>
> /etc/ros/fuerte/core.d. (More about this in our husky_bringup<br>
</div>> <<a href="https://github.com/clearpathrobotics/clearpath_husky/tree/master/husky_bringup/upstart" target="_blank">https://github.com/clearpathrobotics/clearpath_husky/tree/master/husky_bringup/upstart</a>><br>


> package.)<br>
I'd like to come back to these issues in the future, however at this<br>
time I'd like to focus on the config files defined in the REP.<br>
<div class="im"><br>
><br>
> This is not necessarily a vote against. But it would be helpful to<br>
> have more of the following included in the REP:<br>
><br>
> - Individual justification for the inclusion of each piece of data.<br>
</div>I'll can have this added to the draft, but for the hardware<br>
configuration in particular some of the items such as DOF were meant as<br>
a start of discussions.<br>
<div class="im"><br>
> - Justification for their duplication when available (or inferable<br>
> from) elsewhere.<br>
</div>As robots move out of the labs and become more integrated into<br>
businesses and homes, the end users will be less capable of debugging<br>
complex issues.<br>
This means that we need to be able to determine information even if the<br>
ROS or user installation is completely broken.<br>
<br>
For example, if the users environment is corrupted most of the ROS based<br>
tools are unhelpful.<br>
$ rosversion -d<br>
<unknown><br>
<br>
Having a common source of information makes it easy for a user to email<br>
the file to support if everything else is broken.<br>
As a hypothetical example, if we release an ISO image with bugs, having<br>
a text config file describing which version or release candidate will<br>
make it easier to isolate<br>
the source of the problems. Also it makes the system less fragile as it<br>
no longer depends on assumptions such as ROS being installed into<br>
/opt/ros/<distro>, which may no longer be true at some point in the future.<br>
<br>
This can also be useful for indicators and GUIs that run before rosnodes<br>
are launched.<br>
<div class="im"><br>
> - What about including info on what cores get launched, and their<br>
> ROS_MASTER_URIs?<br>
</div>I'll think about this more but I think the idea for the ros-release file<br>
was for it to be relatively static, this might be a better choice for<br>
the robot-release hardware configuration.<br>
<div class="im"><br>
> - Justification for the bash-style X=Y format versus a) the<br>
> established ROS standards of yaml and xml or<br>
</div>AFAIK parsing YAML from bash is unenjoyable. At present, we have a few<br>
use cases where we want access to this a least a subset of this<br>
information in bash.<br>
<br>
* Having Upstart display/log more information about the state of ROS<br>
Expanding on our previous work [1], we would like to |provide clearer<br>
messages via ||notify-send|||<br>
<br>
* MoTD<br>
When users log in via SSH we would like to improve the user experience<br>
and display infomation about the robot.<br>
<br>
* Improved OS integration and user experience<br>
Having things like the name of the hardware vendor readable in bash will<br>
make it easier to do things like setting the desktop background image of<br>
an ISO image to ${VENDOR}-background.jpg<br>
<br>
* Reduced duplication of effort<br>
As an example, if one hardware vendor writes a script to generate<br>
something in the MoTD like "${ROBOT_NAME} by ${VENDOR}\nfor support<br>
information goto ${|SUPPORT_URL}"|<br>
it saves all of us work and makes life better for the users.<br>
<br>
However, I'm not opposed to moving some of the hardware configuration<br>
details, such as DOF and DRIVE into YAML,<br>
<div class="im"><br>
> b) the more (imo) unix-y approach of making ros/robot-release<br>
> directories, and the fields individual files that can then be<br>
> trivially catted into other scripts.<br>
</div>I'm not sure how you get more unix-y than having a config file that is<br>
parsable in bash and basing it on something developed as part of<br>
<a href="http://freedesktop.org" target="_blank">freedesktop.org</a> [2]<br>
<div class="im"><br>
> A larger structural concern is that many of the robots we ship are<br>
> heavily customized with user payloads, including arms, multiple vision<br>
> systems, etc. The software for these elaborate configs end up being a<br>
> mishmash of CPR-written stuff, public drivers, and CPR forks of public<br>
</div>> code. *It's difficult to conceive of boiling all that down to a simple<br>
<div class="im">> field like "DOF", in any kind of way that would provide actual value<br>
</div>> to other tools.*<br>
At a basic level, I think there would be less of a need for fragile<br>
configurations and forks if the code can introspect the hardware.<br>
While I see information such as VENDOR as being useful to a wide range<br>
of tools, I can see how we may not even reach an 80% coverage of use<br>
cases for options such as DOF.<br>
<br>
I'd like to think about making more hardware information available, but<br>
to speed things up for the initial version of the REP we can remove the<br>
more abstract elements for the hardware config.<br>
<div class="im"><br>
> It almost seems like it might be more useful to have the release file<br>
> declare a list of packages which together make up the "config", and<br>
> then each of those include a file that declares the particular<br>
> attributes that they contribute to the whole (so, husky_node<br>
> contributes a differential drive train, imu_um6 and nmea_gps_driver<br>
> contribute position estimation, RCPRG_laser_drivers and openni_kinect<br>
> contribute vision, etc). But is this reinventing the wheel—can the<br>
> existing diagnostics or parameters or manifest infrastructure solve<br>
> the problem this is trying to solve?<br>
</div>Currently, much of the hardware configuration information is written<br>
into launch files, but it is difficult to get the information back out<br>
of a launch file or a running system.<br>
In addition to the advantages of bash compatibility, we are hoping to<br>
generate launch files and URDF [3].<br>
<br>
There is probably value in separating generic hardware information such<br>
as VENDOR from detailed configuration needed for generating URDFs.<br>
<br>
> Additionally, for whatever is ultimately gone with, *it would be<br>
> helpful to have available right out of the gate a basic validator*;<br>
<div class="im">> something which can assist vendors in knowing whether they have<br>
> complied with the recommended practice.<br>
</div>Agrees, some form of lint is definitely required. If it makes it clearer<br>
we can specify the options in BNF.<br>
<div class="im"><br>
> This could take the form of a diagnostics publisher, so the info turns<br>
> up GUIs and gets included in bag files. Another possibility would be<br>
> an end user cli tool, perhaps something like robot_info, which could<br>
> work like so:<br>
><br>
> $ rosrun robot_info robot_info<br>
> Robot: Clearpath Robotics Husky<br>
> ROS version: Fuerte<br>
> Drive Type: Differential (on /cmd_vel)<br>
> Max Speed: 1.2 m/s<br>
> ROS cores:<br>
> main: <a href="http://192.168.1.1:11310" target="_blank">http://192.168.1.1:11310</a> (running)<br>
> public: <a href="http://192.168.0.101:11311" target="_blank">http://192.168.0.101:11311</a> (stopped)<br>
</div>Some of our applications will generate launch files so I would prefer to<br>
avoid building code that depends on ROS running.<br>
<div class="im"><br>
><br>
> Anyhow, my example is getting into some assumptions about multimaster,<br>
> private/public topics, etc, but I'm providing it less to open that<br>
> discussion and more as an example of how the concept of<br>
> ros-release/robot-release files could bring value to Clearpath and our<br>
> users.<br>
><br>
<br>
</div>Thanks for the feedback,<br>
<br>
Bill<br>
<br>
[1] <a href="https://github.com/TurtleBot-Mfg/ros-system-daemon-groovy" target="_blank">https://github.com/TurtleBot-Mfg/ros-system-daemon-groovy</a><br>
[2] <a href="http://www.freedesktop.org/software/systemd/man/os-release.html" target="_blank">http://www.freedesktop.org/software/systemd/man/os-release.html</a><br>
[3]<br>
<a href="https://github.com/IHeartRobotics/iheart-ros-pkg/tree/master/ihe_hardware/urdf_compose" target="_blank">https://github.com/IHeartRobotics/iheart-ros-pkg/tree/master/ihe_hardware/urdf_compose</a><br>
<div class="HOEnZb"><div class="h5"><br>
<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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Tully Foote<br><a href="mailto:tfoote@willowgarage.com" target="_blank">tfoote@willowgarage.com</a><br>(650) 475-2827
</div>