[Documentation] [TitleIndex] [WordIndex

Semantic Robot Description Format (SRDF) review

Proposer: Sachin Chitta, Kaijen Hsiao, Gil Jones, Ioan Sucan, John Hsu


This format is intended to represent information about the robot that is not in the URDF file, but it is useful for a variety of applications. The intention is to include information that has a semantic aspect to it.

One thing to note is that there is also a proposal to add a sensor definition to the URDF format, as well as officially supporting the <mimic> tag for a joint. Those extensions would actually be handled by the URDF parser, and would not be part of this format.



Generic Example

<?xml version="1.0"?>

 <!-- This does not replace URDF, and is not an extension of URDF.
      This is a format for representing semantic information about the robot structure.
      A URDF file must exist for this robot as well, where the joints and the links that are referenced are defined -->
 <robot name="some robot">

   <group name="group1">
      <!-- when a link is specified, the parent joint of that link (if it exists) is automatically included -->
      <link name="..."/>
      <link name="..."/>

      <!-- when a joint is specified, the child link of that joint (which will always exist) is automatically included -->
      <joint name="..." />

      <!-- when a chain is specified, all the links along the chain (including endpoints) are included in the group. Additionally, all the joints that are parents to included links are also included. This means that joints along the chain and the parent joint of the base link are included in the group -->
      <chain base_link="l_shoulder_pan_link" tip_link="l_wrist_roll_link"/>
      <chain base_link="r_shoulder_pan_link" tip_link="r_wrist_roll_link"/>

   <!-- groups can also be formed by referencing to already defined group names -->
   <group name="arms">
      <group name="left_arm"/>
      <group name="right_arm"/>
      <link name="..." />

   <!-- define a named state/configuration of a group -->
   <group_state name="name of this state" group="name of group the state is for">
      <joint name="name of joint in group" value="" />
      <!-- all joints must be specified for the state to be valid -->

   <!-- Define how the robot moves in its environment, i.e., connection to robot's root link -->
   <virtual_joint name="world_joint" type="planar" parent_frame="some fixed frame" child_link="robot's root link name"/> <!-- type can be planar, floating or fixed -->

   <!-- We can then include the virtual joint in groups -->
   <group name="whole_body">
      <group name="arms"/>
      <joint name="world_joint"/>

   <!-- define end effectors -->
   <end_effector name="some diff name" parent_link="..." group="group_name"/>

   <!-- By default it is assumed that any link of the robot could potentially come into collision with any other link in the robot. This tag disables collision checking between a specified pair of links. There can be many such tags in this file.-->
   <disable_collisions link1="link1" link2="link2" />


Example for the PR2

<?xml version="1.0"?>

<robot name="pr2">

   <virtual_joint name="world_joint" type="planar" parent_frame="odom" child_link="base_footprint"/> 

   <group name="right_arm">
      <chain base_link="torso_lift_link" tip_link="r_wrist_roll_link"/>

   <group name="left_arm">
      <chain base_link="torso_lift_link" tip_link="l_wrist_roll_link"/>

   <group name="arms">
      <group name="left_arm"/>
      <group name="right_arm"/>

   <group_state name="tuck_arms" group="arms">
      <joint name="l_shoulder_pan_joint" value="0.2" />
      <!-- ... the rest of the joint values... -->

   <group name="base">
      <joint name="world_joint"/>

   <group name="whole_body">
      <group name="arms"/>
      <group name="base"/>
      <joint name="torso_lift_joint"/>

   <group name="l_end_effector">
      <joint name="l_gripper_palm_joint" />
      <joint name="l_gripper_l_finger_joint" />
      <joint name="l_gripper_l_finger_tip_joint" />
      <joint name="l_gripper_led_joint" />
      <joint name="l_gripper_motor_accelerometer_joint" />
      <joint name="l_gripper_motor_slider_joint" />
      <joint name="l_gripper_motor_screw_joint" />
      <joint name="l_gripper_r_finger_joint" />
      <joint name="l_gripper_r_finger_tip_joint" />
      <joint name="l_gripper_joint" />
      <joint name="l_gripper_tool_joint" />

   <group name="r_end_effector">
      <joint name="r_gripper_palm_joint" />
      <joint name="r_gripper_l_finger_joint" />
      <joint name="r_gripper_l_finger_tip_joint" />
      <joint name="r_gripper_led_joint" />
      <joint name="r_gripper_motor_accelerometer_joint" />
      <joint name="r_gripper_motor_slider_joint" />
      <joint name="r_gripper_motor_screw_joint" />
      <joint name="r_gripper_r_finger_joint" />
      <joint name="r_gripper_r_finger_tip_joint" />
      <joint name="r_gripper_joint" />
      <joint name="r_gripper_tool_joint" />

   <end_effector name="r_end_effector" parent_link="r_wrist_roll_link" group="r_end_effector"/>
   <end_effector name="l_end_effector" parent_link="l_wrist_roll_link" group="l_end_effector"/>

   <disable_collisions link1="r_shoulder_pan_link" link2="r_shoulder_lift_link" />
   <!-- and many more disable_collisions tags -->


Question / concerns / comments

Enter your thoughts on the API and any questions / concerns you have here. Please sign your name. Anything you want to address in the API review should be marked down here before the start of the meeting.

Jonathan Bohren

Shaun Edwards

Mike Ferguson

E. Gil Jones

Comments to the above:

Thibault Kruse

Work has been done in our lab published in ICRA 2011 "Towards Semantic Robot Description Languages", by Lars Kunze and Tobias Roehm and Michael Beetz. While that was not a lightweight XML extention to URDF, inspiration may be drawn from it. PDF link

I am aware anyone can extend URDF for their own purpose, so i will just give ideas that crossed my mind.

Moritz Tenorth

The work Thibault referred to is also available in ROS: http://wiki/mod_srdl Its objective is also to add semantics to the URDF specification, and SRDL is in some parts similar to this proposal (e.g. that parts of kinematic chains can be annotated to be a hand or an arm). However, there are some differences:

  1. As file format, we use OWL, which is still a valid XML document and can be treated as such, but the semantics of the nodes and attributes are well defined by linking the description to a robot ontology in the KnowRob knowledge base. This allows to load the description into the knowledge base and perform reasoning about e.g. which components a robot has.

  2. Apart from hardware components like sensors and actuators, the system also supports software components and abstract capabilities (e.g. navigation or object recognition). These capabilities can usually be provided in different ways, and we are working on heuristics to determine their presence automatically (e.g. navigation capabilities are present if a move_base action is available).
  3. One can specify requirements an action has in terms of components and capabilities, and match them against a robot description in SRDL. This allows to verify that a robot has the capabilities it needs to perform the task and to determine which ones are missing.

SRDL is used in the RoboEarth project (www.roboearth.org) for determining which capabilities are required to perform an action. RoboEarth works on exchanging knowledge about actions, objects and the environment between robots, and being able to decide if a task description is suitable for a robot is an important reasoning task in this application.

David Lu!!

I am glad to see this area getting some attention. My instinct is to agree with everyone who says that this should integrated with URDF.

  1. There was talk (in tickets and on ros-users) of "URDF 2.0". Are there any official plans for that? Are these those plans?
  2. One thing I had mentioned long ago on ros-users was that some of these things (especially grouping) are already contained in the files via xacro macros. We already write URDF in a way that they are grouped; I feel we should be able to extend that format to include this information.

  3. While we're upheaving things, I'd really love to see gazebo tags disappear in favor of more generic meaningful labels.
  4. Similarly, I'm glad to see that mimic and sensor are being officiated. Any reason transmission is being left out?

Adolfo Rodriguez Tsouroukdissian

Review is now closed



2024-07-20 14:46