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

[Mike Purvis]

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.)

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.
- Justification for their duplication when available (or inferable from)
elsewhere.
- What about including info on what cores get launched, and their
ROS_MASTER_URIs?
- 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.

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.*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?

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. 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)

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.

Mike



On 1 February 2013 03:39, Bil Morris <bill at iheartengineering.com> wrote:

> Hello ROS Users,
>
> We have been working on ROS system integration and we have produced a
> draft REP of some config files that we think would be useful for other
> robot hardware vendors to integrate into their process.
>
> Abstract
> ----------
> Robots with ROS installed at the system level have different
> requirements from users manually starting and stopping a ROS
> installation they built themselves. This REP describes file formats for
> storing information about these robotic systems. This will provide users
> and applications with a source of information that is common across
> robot hardware platforms and software installations.
>
> https://github.com/IHeartRobotics/ros-reps/blob/master/rep-rsi.rst
>
>
> Thanks,
> Bill
> ----
> I Heart Engineering
> <3
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130201/c488d39c/attachment-0004.html>