tesseract
tesseract copied to clipboard
tesseract-robotics
Scaling issue from DAE files
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
@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?
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.
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.
No, we were able to work around this problem by using STL files. The problem only seems to occur with sketchup exports.
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
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
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?
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.
@johnwason I believe the solution is to update the documentation that all models must be exported with Z-UP configuration to work correctly?
@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.
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.
on the rviz side this might be fixed by https://github.com/ros-visualization/rviz/pull/1685
please leave a comment if your sample file works or not
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
That is an old version of Tesseract so likely fixed in the latest version.
The version of Tesseract is 0.21.5 so I don't think anything has changed to affect this issue.
With further investigation and help of @johnwason and @hehonglu123, the PR https://github.com/tesseract-robotics/tesseract_python/pull/73 seems to resolve the issue.