Bug: getCollisionShapeData (PyBullet)

[bttner]

The function getCollisionShapeData has two problems which can be best understood by executing the example file shape_mix.py.txt with shape_mix.urdf.txt:

Terminal output

Note: Each link has the same amount of visual and collision shapes and all shapes have the same configuration (length, etc). Thus, the output of getCollisionShapeData(objectUniqueId, linkIndex) and getVisualShapeData(objectUniqueId) are expected to be the same.

Problems

1. Let CSD(linkIndex) denote the returned tuple of getCollisionShapeData(objectUniqueId, linkIndex) . The first element of CSD(-1) contains the correct link index which is -1, the consecutive ones do not (they are all zero; this is also the case if the body only consists of the base link itself). Moreover, it appears that no link index is assigned to the second element of CSD(0) as the index is falsely stated as 1072693248. Edit: The same goes for CSD(1), CSD(2), ....
2. getCollisionShapeData can not handle cylindric shapes, which is why the third element of CSD(-1) and CSD(0) does not match the respective entry in the output of getVisualShapeData. It appears that cylinders are understood and stored as mesh-like geometries in Bullet but PhysicsServerCommandProcessor::extractCollisionShapes can not recover that the mesh is actually a cylinder. Thus, a mismatch between the URDF specification and the output of getCollisionShapeData occurs.

[bttner]

Well, I just realized that one can set the flag URDF_USE_IMPLICIT_CYLINDER to tell Bullet to not convert a cylinder to a convex hull. Then the output is as expected (except for the wrongly assigned link indices -> see problem 1).

Regardless, it would be great if Bullet could recover the information that the convex hull is actually a cylinder and return the appropriate shape type and dimensions.