URDF to Collada: joint coordinate system not observed?

[sloretz]

From ros/robot_model#169

I have a problem similar to this http://answers.ros.org/question/221675/unable-to-move-links-within-urdf-file/ , it is only that I convert from URDF to Collada.

Original URDF as seen in RViz:

After converting to Collada as seen in Openrave:

If I judge solely by eyesight, it seems to me that in the converted Collada file the visual elements are rendered not w.r.t. (local) joint coordinate systems.

I am using Indigo:

$ dpkg -l | grep indigo-collada
ii  ros-indigo-collada-parser                             1.11.11-0trusty-20160627-175110-0700                amd64        This package contains a C++ parser for the Collada robot description format.
ii  ros-indigo-collada-urdf                               1.11.11-0trusty-20161111-194651-0800                amd64        This package contains a tool to convert Unified Robot Description Format (URDF) documents into COLLAborative Design Activity (COLLADA) documents.

Is this a known problem, maybe, already solved in Kinectic?

Thanks.

[hemangchawla]

I face the same issue in kinetic.

[fuzzyTew]

I'm also encountering this issue in lunar.

Here's an isolated test case. It seems that the orientation parameter of the link visual origin is completely ignored. This makes an 'X' appear in rviz but the two boxes render coincident as one box in openrave.

<?xml version="1.0"?>
<robot name="TestCase">
        <link name="base_link"/>
        <link name="box1">
                <visual>
                        <geometry> <box size="4.0 0.25 1.0"/> </geometry>
                </visual>
        </link>
        <joint name="box1" type="fixed">
                <parent link="base_link"/>
                <child link="box1"/>
        </joint>
        <link name="box2">
                <visual>
                        <geometry> <box size="4.0 0.25 1.0"/> </geometry>
                        <origin rpy="0 0 0.785398"/>
                </visual>
        </link>
        <joint name="box2" type="fixed">
                <parent link="base_link"/>
                <child link="box2"/>
        </joint>
</robot>

[richard-mck]

I had the same issue with my URDF. I was able to work around it by recreating all my STL models so that their joints were coincident with the origin. Then I specified their position using the joint origin rather than the link origin. Here's an example using a modified version of the test case above:

<?xml version="1.0"?>
<robot name="TestCase">
        <link name="base_link"/>
        <link name="box1">
                <visual>
                        <geometry> <box size="4.0 0.25 1.0"/> </geometry>
                </visual>
        </link>
        <joint name="box1" type="fixed">
                <parent link="base_link"/>
                <child link="box1"/>
        </joint>
        <link name="box2">
                <visual>
                        <geometry> <box size="4.0 0.25 1.0"/> </geometry>

                </visual>
        </link>
        <joint name="box2" type="fixed">
                <parent link="base_link"/>
                <child link="box2"/>
                <origin rpy="0 0 0.785398"/>
        </joint>
</robot>

As you can see, it considers only the joint origin, not the model origin.

[ShuiXinYun]

same problem... ... IN Kinetic URDF in RVIZ: Converted dae in OpenRAVE:

[blubbi321]

Same problem here.

Did this ever work before? Would be nice if I didnt have to rebuild all my STL files ..

[kumar-akshay324]

Any updates on this issue?

[moliqingwa]

I have the same issue.

[clalancette]

For all of those running into this issue: can you please try out the fix in https://github.com/ros/collada_urdf/pull/32/ and see if it solves the problem for you? Having some additional confirmation of that would help.

[corot]

For all of those running into this issue: can you please try out the fix in #32 and see if it solves the problem for you? Having some additional confirmation of that would help.

I dropped my comment; on openrave the robot looks just fine. Sorry for the noise.

[rkoyama1623-2021]

By following updates, I manage to generate collada model of PR2 from its URDF file. https://github.com/ros/collada_urdf/compare/kinetic-devel...rkoyama1623:beb1d3a5f45a4a15eca253ace88bfbc1bcf9582e

rosrun xacro xacro $(rospack find pr2_description)/robots/pr2.urdf.xacro > pr2.urdf
rosrun collada_urdf urdf_to_collada pr2.urdf output.dae
meshlab output.dae

Before:

After:

[rkoyama1623-2021]

There are several lines adding transformation.

https://github.com/ros/collada_urdf/blob/kinetic-devel/collada_urdf/src/collada_urdf.cpp#L1217 https://github.com/ros/collada_urdf/blob/kinetic-devel/collada_urdf/src/collada_urdf.cpp#L1268-L1270

As a result, there are multiple transformations for links other than the root link in output.dae . The following is an excerpt of the collada file generated by the current command.

<node id="vkmodel0_node1" name="base_footprint" sid="node1">
  <translate>0 0 0</translate>
  <rotate>1 0 0 0</rotate>
  <instance_geometry url="#gkmodel0_base_footprint_geom0">
    <bind_material>
      <technique_common>
        <instance_material symbol="mat0" target="#gkmodel0_base_footprint_geom0_mat"/>
      </technique_common>
    </bind_material>
  </instance_geometry>
  <node id="vkmodel0_node3" name="base_link" sid="node3">
    <translate>-0 -0 -0</translate>  <!-- first transformation -->
    <rotate>1 0 0 0</rotate>
    <translate>0 0 0.051</translate> <!-- second transformation -->
    <rotate>1 0 0 0</rotate>
    <rotate sid="node_base_footprint_joint_axis0">0 0 0 0</rotate>
    <translate>0 0 0</translate> <!-- third transformation -->
    <rotate>1 0 0 0</rotate>
    <instance_geometry url="#gkmodel0_base_link_geom0">
      <bind_material>
        <technique_common>
          <instance_material symbol="mat0" target="#gkmodel0_base_link_geom0_mat"/>
        </technique_common>
      </bind_material>
    </instance_geometry>

I think these multiple transformations are redundant, and for example, meshlab uses only the last transformation. The above update, I made, remove the third transformation. By the way, I'm not sure, but afraid the_WriteTransformation function should multiply transformation instead of adding a transformation tag. I mean, the above update may not be in the proper way...