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

Tue Feb 5 03:18:57 UTC 2013

On 02/04/2013 10:11 PM, Tully Foote wrote:
> 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.
We will revise the REP to separate the Identification information from
configuration information. I think that will address the main feedback
so far.
>
> 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.
Based on my experience so far, I suspect there is enough issues to
warrant a separate REP for /etc/ros
We plan to start writing a REP to describe /etc/ros as time allows in
the next few weeks.

Thanks for the Feedback.

>
> Tully
>
>
>
>
> On Fri, Feb 1, 2013 at 9:46 AM, Bil Morris <bill at iheartengineering.com
> <mailto: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 <http://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 <mailto:ros-users at code.ros.org>
>     https://code.ros.org/mailman/listinfo/ros-users
>
>
>
>
> -- 
> Tully Foote
> tfoote at willowgarage.com <mailto:tfoote at willowgarage.com>
> (650) 475-2827
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users