configuration information. I think that will address the main feedback
so far.
Thanks for the Feedback.
>
> Tully
>
>
>
>
> On Fri, Feb 1, 2013 at 9:46 AM, Bil Morris <bill@iheartengineering.com
> <mailto:bill@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@code.ros.org <mailto:ros-users@code.ros.org>
> https://code.ros.org/mailman/listinfo/ros-users
>
>
>
>
> --
> Tully Foote
> tfoote@willowgarage.com <mailto:tfoote@willowgarage.com>
> (650) 475-2827
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users