Incorrect Collisions Detected

[davetcoleman]

I've had this issue since getting Baxter, but I'm trying to really track it down now. As seen in the image, the elbow and forearm are in collision with the pedestal (collisions marked bright green).

Looking at the robot_model with collision visuals enabled, you can see this doesn't appear to be a geometry issue with the URDF

Nothing appears wrong in the consoles.

My current URDF can be found here

Not sure how to investigate this further, thanks!

[davetcoleman]

No errors are displayed in any of the consoles, with debug output enabled.

To reproduce this issue:

git clone git@github.com:davetcoleman/baxter_common.git -b dual_parallel_collision_work

build then

roslaunch baxter_moveit_config_test demo.launch

And choose random goal poses and observe the collisions.

[isucan]

I believe this is the issue of incorrect scale being loaded from the DAE file. And probably that issue persists in the converted STL somehow. If we replace the representation of the pedestal's collision, things seem to work fine. So I removed this bit from the URDF:

 <collision>
      <origin rpy="0 0 0" xyz="0 0 -0.4"/>
      <geometry>
        <mesh filename="package://baxter_description/meshes/base/pedestal_link_collision.DAE"/>
      </geometry>
    </collision>

and added the following bit instead:

    <collision>
      <origin rpy="0 0 0" xyz="0 0 -0.4"/>
      <geometry>
        <cylinder length="0.6" radius="0.15"/>
      </geometry>
    </collision>
    <collision>
      <origin rpy="0 0 0" xyz="0 0 -0.78"/>
      <geometry>
        <box size="0.8 0.8 0.25"/>
      </geometry>
    </collision>

Basically the pedestal is now 2 geoms: a cylinder with a box. Support for multiple geometries has been added in ROS Hydro. You should also regenerate the collision matrix.

[davetcoleman]

Thanks Ioan, adding those geometries fixed my issue with the pedestal. I'm also having the same issue with the torso link:

All of the teal/blue color links are in collision with the torso when I move to random positions. I have hacked into the rviz plugin to allow the "Query Goal State" pose to be shown with collision geometry, not visual geometry. Using this, it appears scale is ok. How do I report to Rethink (@rethink-kmaroney @rethink-cgindel) how to fix this and how to fix the pedestal?

[davetcoleman]

@isucan, you mentioned you were still looking into this. Do you have any suggestions for this issue?

[isucan]

The problem is that even if you display the collision geometry, the code for displaying meshes is different from the code that loads collision objects. What we would need to see exactly what the planners see is to generate markers from the shapes the robot includes. I suspect this is an issue of how transforms are applied to the loaded meshes. I am not sure this is a bug in the meshes. It may be an issue in assimp, or how I am using assimp. I think we need more debug info -- generating markers as suggested above.

[davetcoleman]

I'm not sure I know enough to look into assimp issues, but I'd love for this bug to be fixed.

[guihomework]

Hi, I encountered the exact same problem with the shadow hand fingertip meshes, they were never colliding when expected in moveit with the DAE files but box/cylinders collision geometries would collide correctly. We cannot live with boxes as we need to extract rather precise fingertip contacts from gazebo Then I had the crazy idea to open the dae and modify a single letter :

Z_UP to Y_UP

Surprisingly, this change does not affect at all the display of the collision in rviz, and did not affect gazebo contact detection either, and ... fixes the planner collision checking with dae files.

I tested this on the provided baxter example and the fix works as you can see in this picture

I don't know where to fix that in the planner code (maybe assimp takes care of the axis up tag and other mesh loaders don't ?) On my side, I will just change my dae files now hoping there is no unseed side effect to occur later.

hope this helps.