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 > 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 > > > > > 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 > > > 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/, 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@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users > > > > > -- > Tully Foote > tfoote@willowgarage.com > (650) 475-2827 > > > _______________________________________________ > ros-users mailing list > ros-users@code.ros.org > https://code.ros.org/mailman/listinfo/ros-users