Scaling issue from DAE files

[hehonglu123]

URDF loader isn't correctly handling scaling from sketchup DAE files.
Collada mesh file: https://gist.github.com/hehonglu123/0afdb2bab3d744cd5abe5fe0bb30fd9c

In Gazebo:

In Tesseract Viewer:

@johnwason

[Levi-Armstrong]

Yea, it is possible that the scale is not being handled yet.

[Levi-Armstrong]

@haudren Are you providing a scale in the urdf or are you suggesting that the dae file itself has a scale which is not being handled?

[hehonglu123]

I tried the urdf with scale and without, not affecting the result (giant). I believe there's default scale in .dae files. .stl file works fine with the default scale; but with scale parameter in urdf, it's different than what shows up in gazebo.

[Levi-Armstrong]

What visualizer are you using?

[hehonglu123]

tesseract_viewer_python

[johnwason]

I checked the output from the Mesh class, and the triangle positions are far larger than they should be. The tesseract_viewer_python passes the output directly from the Mesh class, and then adds the scale separately. I confirmed that the scale values passed to the viewer matched those specified in the URDF file. The issue seems to be a transform in the dae file that is not being applied to the position array when it is loaded.

[Levi-Armstrong]

@johnwason are you working on a fix?

[johnwason]

No, we were able to work around this problem by using STL files. The problem only seems to occur with sketchup exports.

[Levi-Armstrong]

Do you mind posting the sketup dae and the stl?

[hehonglu123]

stl: https://github.com/hehonglu123/RR_Project/blob/master/simulation/models/box2/box2.stl
dae: https://github.com/hehonglu123/RR_Project/blob/master/simulation/models/box2/model.dae

[Levi-Armstrong]

I have found the issue and not sure how best to fix it.

https://github.com/ros-industrial-consortium/tesseract/blob/b79ea6bcad011bd17761d96cf50e2f0f1c5d35c3/tesseract/tesseract_geometry/include/tesseract_geometry/mesh_parser.h#L191-L196

and

https://github.com/ros-industrial-consortium/tesseract/blob/b79ea6bcad011bd17761d96cf50e2f0f1c5d35c3/tesseract/tesseract_geometry/include/tesseract_geometry/mesh_parser.h#L279-L284

[johnwason]

Yeah, the ROS software doesn't handle collada format properly. I suggest we deprecate it in favor of glTF since collada is so ambiguous.

Does RViz have the same problem?

[Levi-Armstrong]

RViz does have the same problem.

[Levi-Armstrong]

I appears to be a assimp importer issues shown here.

[johnwason]

I tracked down the rotation problem to the way RViz imports dae files:

https://github.com/ros-visualization/rviz/blob/291df89957e2f643a3fde28e5cb239fe1f6f5b73/src/rviz/mesh_loader.cpp#L240

I suspect that this is where the scaling issue is coming from as well. Unfortunately all ROS software has this issue so it is probably not possible to fix it now.

I ran into this issue when writing the industrial_payload_manager package.

[Levi-Armstrong]

@johnwason I believe the solution is to update the documentation that all models must be exported with Z-UP configuration to work correctly?

[johnwason]

@Levi-Armstrong Yeah, that is probably the best solution. Blender can do some strange transforms during export to enforce the Y-up convention, which is the convention for game engines. Collada has a flag for Y-up or Z-up, but ROS handles Y-up inconsistently so it is best to ignore it. glTF2 is supposed to always be Y-up, but in practice most models are Z-up.

[johnwason]

Another interesting tidbit, old style game engines used screen coordinates with 0,0 in the lower left corner, X to the right, Y up, and Z into the screen. This led to a left hand coordinate system. The inconsistent use of left and right handed coordinate systems make working with game engines annoying, although newer ones are using right handed coordinate systems.

[simonschmeisser]

on the rviz side this might be fixed by ros-visualization/rviz#1685

please leave a comment if your sample file works or not

[rjoomen]

I think this can be closed.

[burakaksoy]

Could not be sure whether to create a new issue or follow up from this one but I am reproducing the scaling issue. With scale parameter in URDF when specifying a mesh file (I tested with .obj and .dae files), the Tesseract somehow takes the square of the scaling parameter

[Levi-Armstrong]

What version are you using?

[burakaksoy]

Installed through pypi,

Tesseract is v0.4.0.
The viewer is v0.2.5

[Levi-Armstrong]

That is an old version of Tesseract so likely fixed in the latest version.

[johnwason]

The version of Tesseract is 0.21.5 so I don't think anything has changed to affect this issue.

[burakaksoy]

With further investigation and help of @johnwason and @hehonglu123, the PR tesseract-robotics/tesseract_python#73 seems to resolve the issue.