[ros-users] Robot Task Description Format - Potential REP

Tue Apr 16 07:50:58 UTC 2013

Shaun,

you are right that the plans that we have so far looked at in the 
RoboEarth project are more high-level than what you had in mind. We can, 
however, also describe low-level data such as points and trajectories 
and could create action classes for moving to that point or following 
the trajectory.

The OWL-based representation is more abstract and less compact than your 
initial proposal, but using OWL client libraries (e.g. OWLAPI for Java, 
http://owlapi.sourceforge.net) still rather convenient to edit. If the 
whole use case is to dump and replay trajectory data, an OWL-based 
representation is probably overkill. In other cases, more semantics may 
however be useful: If you know that a motion is a reaching action, you 
can e.g. conclude that the trajectory in between start and end does not 
matter (and optimize it), while actions like cutting or screwing are all 
about this motion in between. Semantics also help to decide how to adapt 
actions to new situations and to describe what the numbers mean (joint 
angles vs. cartesian coordinates, coordinate frames relative to what, etc).

We use the KnowRob knowledge base (ros.org/wiki/knowrob) for parsing the 
OWL files and for answering queries. For execution, we normally use a 
converter into the CRAM plan language (ros.org/wiki/cram_core), but it's 
also fairly easy to load the files into other programs (e.g. to read it 
using the OWLAPI and to create a state machine from it).

best,
Moritz

On 04/15/2013 06:02 PM, Edwards, Shaun M. wrote:
>
> Moritz,
>
> Thank you for your reply.  I am familiar with OWL and interested in 
> your work.  I think the work that you are doing is more abstract and 
> high-level than what I propose, but I can see the overlap.  For 
> example, in the simplest use cases we would just need a list of 
> defined waypoints.  We would write an explicit program that knew how 
> to interpret the data.  Could your representation  be used for such a 
> simple case?  Do you have any software built up that supports parsing 
> of the OWL and translation into programming constructs (classes)?
>
> Shaun Edwards
>
> Senior Research Engineer
>
> Manufacturing System Department
>
> http://robotics.swri.org
>
> http://rosindustrial.swri.org/
>
> http://ros.swri.org <http://ros.swri.org/>
>
> Join the ROS-Industrial Developers List 
> <https://groups.google.com/group/swri-ros-pkg-dev/boxsubscribe>
>
> Southwest Research Institute
>
> 210-522-3277
>
> *From:*ros-users-bounces at code.ros.org 
> [mailto:ros-users-bounces at code.ros.org] *On Behalf Of *Moritz Tenorth
> *Sent:* Monday, April 15, 2013 4:33 AM
> *To:* ros-users at code.ros.org
> *Subject:* Re: [ros-users] Robot Task Description Format - Potential REP
>
> Hi,
>
> part of this seems indeed similar to what we are working on in the 
> RoboEarth project. The project aims at establishing a web-based 
> knowledge base through which robots can exchange information about 
> actions, objects and environments (diff. kinds of maps) among each 
> other, similar to  Wikipedia for humans.
>
> As part of this effort, we have worked on formal semantic 
> representations for this kind of information [1]. The "action recipes" 
> are encoded in OWL, an XML-based formal language used in the Semantic 
> Web. They can describe actions, their properties (e.g. objectActedOn, 
> fromLocation,...), their arrangement in a task (sequences, partial 
> orderings, FSM-like structures), as well as relations to objects or 
> spatial concepts (points, trajectories).
>
> Since the recipes are described in the same language as object models 
> and environment maps, it is possible to link these kinds of 
> information, for example to parameterize an action with the spatial 
> layout described in a semantic environment map.
>
> So if there will be an effort to define such a format, we'd be happy 
> to share our experiences and contribute to its definition.
>
> best,
> Moritz
>
>
> [1] Moritz Tenorth, Alexander Clifford Perzylo, Reinhard Lafrenz, 
> Michael Beetz, "The RoboEarth language: Representing and Exchanging 
> Knowledge about Actions, Objects, and Environments", /In IEEE 
> International Conference on Robotics and Automation (ICRA)/, St. Paul, 
> MN, USA, 2012.
>
> On 04/12/2013 10:28 PM, rdean at gdrs.com <mailto:rdean at gdrs.com> wrote:
>
>     You may want to check out what RoboEarth has already done, I
>     remember from an ICRA presentation that they were sharing task
>     descriptions between different robots.  This may or may not cover
>     your area of interest, or may have a core lexicon you could extend.
>
>     *From:*ros-users-bounces at code.ros.org
>     <mailto:ros-users-bounces at code.ros.org>
>     [mailto:ros-users-bounces at code.ros.org] *On Behalf Of *Edwards,
>     Shaun M.
>     *Sent:* Friday, April 12, 2013 10:40 AM
>     *To:* ros-users at code.ros.org <mailto:ros-users at code.ros.org>
>     *Subject:* [ros-users] Robot Task Description Format - Potential REP
>
>     All,
>
>     Recently we have had several projects that have required us to
>     follow a predetermined path (i.e. a set of waypoints that are
>     determined offline)  To achieve this we have used csv or yaml
>     files (with joint points and Cartesian positions) or in some cases
>     just hardcoded the path in the source file.  I have searched
>     through ROS and asked questions on ROS answers, but there doesn't
>     seem to be anything built into ROS to support this functionality
>     in a generic way.  To illustrate the need, here are several use cases:
>
>     ·3D model/data to robot path -- Several applications require a
>     robot path be defined using a 3D model.  For these applications,
>     we often use a CAD system (or 3D models in general) to define the
>     Cartesian robot path.  Example applications include, robotic
>     painting, grinding, deburring, mold trimming, inspection, etc... 
>     The Cartesian path is then turned into a robot joint path at runtime.
>
>     ·Robot path teaching -- Not all applications require intelligent
>     path planning. There are some applications that can be solved (at
>     least partially) by teaching a robot a desired path (i.e. a set of
>     waypoints to execute repeatedly).  New robots, such as Baxter,
>     illustrate this capability by allowing a human operator to move an
>     arm and record waypoints.  Note, this is not as easy as simply
>     recording joint positions.  For some applications, you may want to
>     record Cartesian positions or specify that a path segment between
>     waypoints be executed using a linear trajectory.  Because of these
>     requirements, the recorded path/trajectory is more than a joint
>     trajectory.
>
>     ·High level scripting -- Several robot tasks, such as static pick
>     and place, include lots of scripted motion and process data.  Move
>     to A, open gripper, Move to B, close gripper.  In a typical ROS
>     approach, positions are stored in yaml files and motion order and
>     process data is captured in code.  Any change in the logic or
>     order of operations requires a code change and rebuild.  A task
>     description format could capture this information generically in a
>     single place and allow on the fly configuration of nodes that
>     execute the motion.  Note, that in this use case, IO operations
>     (i.e. open gripper) are also required.
>
>     These use cases lead me to believe that a Robot Task Description
>     Format (RTDF), similar to a URDF would be useful.  I have put
>     together a minimal example here [1], but would like to expand upon
>     it to meet all the requirements of the use cases above and others.
>
>     I would like to gage the community interest in the need for such a
>     file format.  If the interest is great enough then I will move
>     forward with creating an official REP.
>
>     Thanks for your consideration,
>
>     Shaun Edwards
>
>     Senior Research Engineer
>
>     Manufacturing System Department
>
>     http://robotics.swri.org
>
>     http://rosindustrial.swri.org/
>
>     http://ros.swri.org <http://ros.swri.org/>
>
>     Join the ROS-Industrial Developers List
>     <https://groups.google.com/group/swri-ros-pkg-dev/boxsubscribe>
>
>     Southwest Research Institute
>
>     210-522-3277
>
>     [1]
>     https://github.com/mtconnect/ros_bridge/blob/master/mtconnect_example/mtconnect_cnc_robot_example/config/m16ib20/task_description.xml
>
>     *------------------------------------------------------*
>
>     This is an e-mail from General Dynamics Robotic Systems. It is for
>     the intended recipient only and may contain confidential and
>     privileged information. No one else may read, print, store, copy,
>     forward or act in reliance on it or its attachments. If you are
>     not the intended recipient, please return this message to the
>     sender and delete the message and any attachments from your
>     computer. Your cooperation is appreciated.
>
>
>
>
>     _______________________________________________
>
>     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
>
>
>
> -- 
> Dr. Moritz Tenorth     |tenorth at cs.uni-bremen.de  <mailto:tenorth at cs.uni-bremen.de>
> Universität Bremen     | Am Fallturm 1
> 29359 Bremen           | Germany
> Tel: +49 421 218-64016 | ai.uni-bremen.de/team/moritz_tenorth
>
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users

-- 
Dr. Moritz Tenorth     | tenorth at cs.uni-bremen.de
Universität Bremen     | Am Fallturm 1
29359 Bremen           | Germany
Tel: +49 421 218-64016 | ai.uni-bremen.de/team/moritz_tenorth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130416/3958d5fe/attachment-0004.html>