Problem with collision meshes

[AmiQuijano]

I am currently working with Tesseract version 29.1 on a Realman robot with a camera plate and a camera on its end effector. For the camera plate collision mesh I am using an .stl file while for the camera I am using a box. However, collision meshes of these last two parts appear to be huge even if in the .xacro they are scaled properly:

Example:

<collision> 
  <origin xyz="0 0 0" rpy="-1.5708 0 0" />
  <geometry>
    <mesh filename="package://my_pkg/meshes/camera_connection_plate.STL" scale="0.001 0.001 0.001"/>
  </geometry>
</collision>

Realman alone:

Realman with camera plate and camera (right is zoomed out to let you see how big the boxes are):

What could be the issue?

On the other hand, I am working with a custom robot for which I am using .dae for the collision meshes in the .xacro. However, the collision boxes are bigger than the actual link. Is there any way to make the boxes smaller, thus closer to the actual dimensions of the links? I tried changing the meshes (.dae) for boxes in the .xacro but then I got the same problem as above, i.e. I got huge collision boxes.

I am not sure whether I am using bullet or FCL. Howe can I check this and how can I switch between them?

Thank you a lot!

[marip8]

I am not sure whether I am using bullet or FCL. Howe can I check this and how can I switch between them?

This is defined in a YAML file reference by your SRDF, like this example. You can change this in the YAML file by changing the value of the default key for the discrete and continuous sections.

You can also specify the contact manager programatically using the Environment class (see here).

[marip8]

However, the collision boxes are bigger than the actual link. Is there any way to make the boxes smaller, thus closer to the actual dimensions of the links?

The tesseract URDF package has a feature (tesseract:make_convex) that can tell tesseract to turn collision meshes into convex hulls automatically (see snippet below).

tesseract/tesseract_support/urdf/abb_irb2400.urdf

Line 6 in 5bbc198

<robot name="abb_irb2400" xmlns:xacro="http://ros.org/wiki/xacro" xmlns:tesseract="https://github.com/tesseract-robotics/tesseract" tesseract:make_convex="true">

By default I believe the global option is set to true, so that may be why your collision meshes look bigger than your visual meshes. Using convex hulls for collision models is generally a good idea because it makes collision checking faster, but you could turn this option off globally if it makes more sense for your application.

I would also check that your meshes don't have stray vertices that don't participate in any triangles. If you make a convex hull of a mesh like this, the convex hull will include the unconnected vertices. If one of these vertices is far away from the rest of the mesh, the convex hull of that mesh will be very large.

[AmiQuijano]

Thank you for your replies.

I have tried switching tesseract:make_convex="false" to 'false but I'm still getting the huge collision meshes.
The weirdest thing is that even if I use boxes (primitive shape) instead of meshes such as

<collision>
  <origin xyz="0 0 0.03" rpy="0 0 0" />
  <geometry>
    <box size= "0.095 0.205 0.06"/>
  </geometry>
</collision>

then the result is still huge cubes:

This happens regardless the value of make_covex
The parser correctly reads the box size, but I am not sure where the information is being lost...

Thank you!

[AmiQuijano]

This is defined in a YAML file reference by your SRDF, like this example. You can change this in the YAML file by changing the value of the default key for the discrete and continuous sections.

You can also specify the contact manager programatically using the Environment class (see here).

Regarding this, how and where can I specify whether to use continuous or discrete collision checking?

[marip8]

I have tried switching tesseract:make_convex="false" to 'false but I'm still getting the huge collision meshes.
The weirdest thing is that even if I use boxes (primitive shape) instead of meshes such as ... then the result is still huge cubes:

For reference, the large cubes you are referring to are just bounding boxes and they are only used for visualization within tesseract_qt and tesseract_rviz. There may be an issue that the bounding boxes are not being scaled to match the underlying meshes/primitives. The visual/collision meshes/primitive shapes in the image you attached look appropriately sized to me. Is that not the case?

Regarding this, how and where can I specify whether to use continuous or discrete collision checking?

Inverse kinematics only uses discrete collision checking (continuous collision checking requires 2+ states). The motion planner and task profiles that use collision expose the ability to choose the type of contact manager using tesseract_collision::CollisionCheckConfig::type, such as here for the OMPL planner. For the most part, our recommendation is to use type Discrete or LVSDiscrete

[AmiQuijano]

For reference, the large cubes you are referring to are just bounding boxes and they are only used for visualization within tesseract_qt and tesseract_rviz. There may be an issue that the bounding boxes are not being scaled to match the underlying meshes/primitives. The visual/collision meshes/primitive shapes in the image you attached look appropriately sized to me. Is that not the case?

Yes, the visual and collision meshes/primitives are appropriately sized. The reason I thought this was a problem was:

I tested both realman and custom robots with the same script (based on freespace_hybrid_example.cpp), and only changed the URDF, SRDF, and YAML files to match the specific robot. However, I noticed that there are self collisions between non adjacent links with the custom robot in trajectories labeled as “successful”.
The collision meshes/primitives are correct as does the SRDF and YAML. The only weird thing I noticed was the green collision boxes being larger than the actual mesh/primitive, thus making many links to be already in collision from the initial state). This is why I thought the green overlapping collision boxes were the problem…

[AmiQuijano]

Any idea of what could be the problem?

[Levi-Armstrong]

Is this somewhere public that I can pull down and test?