[ros-users] Request for Comment: Draft REP - Robot System Identification

Tue Feb 5 03:11:11 UTC 2013

Hi Bill,

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.

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.

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.

Tully

On Fri, Feb 1, 2013 at 9:46 AM, Bil Morris <bill at iheartengineering.com>wrote:

> On 02/01/2013 10:38 AM, Mike Purvis wrote:
> > Hi Bill,
> >
> > Our current approach at Clearpath is to install the launchers for
> > Husky in:
> >
> > /etc/ros/fuerte/husky/core.d
> >
> > And then the system launch shell script (installed to
> > /usr/sbin/husky-core-start, 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 ls /etc/ros which robot it's
> > setup for by ls /etc/ros/fuerte, and which payloads are included by ls
> > /etc/ros/fuerte/core.d. (More about this in our husky_bringup
> > <
> https://github.com/clearpathrobotics/clearpath_husky/tree/master/husky_bringup/upstart
> >
> > package.)
> I'd like to come back to these issues in the future, however at this
> time I'd like to focus on the config files defined in the REP.
>
> >
> > This is not necessarily a vote against. But it would be helpful to
> > have more of the following included in the REP:
> >
> > - Individual justification for the inclusion of each piece of data.
> I'll can have this added to the draft, but for the hardware
> configuration in particular some of the items such as DOF were meant as
> a start of discussions.
>
> > - Justification for their duplication when available (or inferable
> > from) elsewhere.
> As robots move out of the labs and become more integrated into
> businesses and homes, the end users will be less capable of debugging
> complex issues.
> This means that we need to be able to determine information even if the
> ROS or user installation is completely broken.
>
> For example, if the users environment is corrupted most of the ROS based
> tools are unhelpful.
> $ rosversion -d
> <unknown>
>
> Having a common source of information makes it easy for a user to email
> the file to support if everything else is broken.
> As a hypothetical example, if we release an ISO image with bugs, having
> a text config file describing which version or release candidate will
> make it easier to isolate
> the source of the problems. Also it makes the system less fragile as it
> no longer depends on assumptions such as ROS being installed into
> /opt/ros/<distro>, which may no longer be true at some point in the future.
>
> This can also be useful for indicators and GUIs that run before rosnodes
> are launched.
>
> > - What about including info on what cores get launched, and their
> > ROS_MASTER_URIs?
> I'll think about this more but I think the idea for the ros-release file
> was for it to be relatively static, this might be a better choice for
> the robot-release hardware configuration.
>
> > - Justification for the bash-style X=Y format versus a) the
> > established ROS standards of yaml and xml or
> AFAIK parsing YAML from bash is unenjoyable. At present, we have a few
> use cases where we want access to this a least a subset of this
> information in bash.
>
> * Having Upstart display/log more information about the state of ROS
> Expanding on our previous work [1], we would like to |provide clearer
> messages via ||notify-send|||
>
> * MoTD
> When users log in via SSH we would like to improve the user experience
> and display infomation about the robot.
>
> * Improved OS integration and user experience
> Having things like the name of the hardware vendor readable in bash will
> make it easier to do things like setting the desktop background image of
> an ISO image to ${VENDOR}-background.jpg
>
> * Reduced duplication of effort
> As an example, if one hardware vendor writes a script to generate
> something in the MoTD like "${ROBOT_NAME} by ${VENDOR}\nfor support
> information goto ${|SUPPORT_URL}"|
> it saves all of us work and makes life better for the users.
>
> However, I'm not opposed to moving some of the hardware configuration
> details, such as DOF and DRIVE into YAML,
>
> > 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.
> I'm not sure how you get more unix-y than having a config file that is
> parsable in bash and basing it on something developed as part of
> freedesktop.org [2]
>
> > 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. *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.*
> At a basic level, I think there would be less of a need for fragile
> configurations and forks if the code can introspect the hardware.
> While I see information such as VENDOR as being useful to a wide range
> of tools, I can see how we may not even reach an 80% coverage of use
> cases for options such as DOF.
>
> I'd like to think about making more hardware information available, but
> to speed things up for the initial version of the REP we can remove the
> more abstract elements for the hardware config.
>
> > 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?
> Currently, much of the hardware configuration information is written
> into launch files, but it is difficult to get the information back out
> of a launch file or a running system.
> In addition to the advantages of bash compatibility, we are hoping to
> generate launch files and URDF [3].
>
> There is probably value in separating generic hardware information such
> as VENDOR from detailed configuration needed for generating URDFs.
>
> > Additionally, for whatever is ultimately gone with, *it would be
> > helpful to have available right out of the gate a basic validator*;
> > something which can assist vendors in knowing whether they have
> > complied with the recommended practice.
> Agrees, some form of lint is definitely required. If it makes it clearer
> we can specify the options in BNF.
>
> > 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:
> >
> > $ rosrun robot_info robot_info
> > Robot: Clearpath Robotics Husky
> > ROS version: Fuerte
> > Drive Type: Differential (on /cmd_vel)
> > Max Speed: 1.2 m/s
> > ROS cores:
> > main: http://192.168.1.1:11310 (running)
> > public: http://192.168.0.101:11311 (stopped)
> Some of our applications will generate launch files so I would prefer to
> avoid building code that depends on ROS running.
>
> >
> > 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.
> >
>
> Thanks for the feedback,
>
> Bill
>
> [1] https://github.com/TurtleBot-Mfg/ros-system-daemon-groovy
> [2] http://www.freedesktop.org/software/systemd/man/os-release.html
> [3]
>
> https://github.com/IHeartRobotics/iheart-ros-pkg/tree/master/ihe_hardware/urdf_compose
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>

-- 
Tully Foote
tfoote at willowgarage.com
(650) 475-2827
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130204/2631d389/attachment-0004.html>