Closed hehonglu123 closed 2 months ago
Yea, it is possible that the scale is not being handled yet.
@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.
What visualizer are you using?
tesseract_viewer_python
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.
@johnwason are you working on a fix?
No, we were able to work around this problem by using STL files. The problem only seems to occur with sketchup exports.
Do you mind posting the sketup dae and the stl?
I have found the issue and not sure how best to fix it.
and
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?
RViz does have the same problem.
I appears to be a assimp importer issues shown here.
I tracked down the rotation problem to the way RViz imports dae files:
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
I think this can be closed.
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
What version are you using?
Installed through pypi,
Tesseract is v0.4.0. The viewer is v0.2.5
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.
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