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

[Bil Morris]

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