MARS has trouble loading meshes correctly #129
Comments
|
Will close this during further researching this topic and reopen later. |
|
I elaborated a bit more and therefore reopen |
hwiedPro
changed the title
|
@hwiedPro
STL Issue:
Obj Issue:
NOTE: please be carefully to merge loading branch into devel, since the current models will be not loaded properly |
|
Regarding the OBJ Export, please checkout the ReaderWriter::Options for ReaderWriterOBJ: This is exactly the rotation we need to apply to the obj files e.g. in phobos to later import them correctly with the current verion in MARS. See https://codedocs.xyz/openscenegraph/OpenSceneGraph/a01746.html#a2304aa40f119d6a0d852f7b709be6e74 |
ToDo: Review the mesh import to MARS
Obj mesh orientations are interpreted not consistently, I guess this comes from the old default how they were exported from blender by default.
I had a look on the behaviour of pyBullet, Gazebo, rock-roboviz and MARS using the doc/a test model; and also into the mesh formats.
This I will explain deeper in the following.
As described below the most simulators and mesh formats are consistent, I suggest the following that MARS should be adapted to interpret obj (bobj), stl and dae accordingly.
Test data
I created the mesh above in blender to identify the axes when loaded. (Color coding: RGB = XYZ)The length and points of the arms display the axis by their length and vertices at their end: x=1, y=2, z=3
This mesh is included in the following URDF:
The mesh I exchanged vs their DAE/STL/OBj version during testing.
Mesh formats
STL
STL saves vertices in the following format:
When using the convention Z is Up and Y is Forward, the STL base frame has the same orientation as intended by the mesh. See the format example which shows a face that was created with vertices on all axis with different distances from the origin: x = 1 y =2 z =3.
Wavefront OBJ
OBJ saves vertices in the following format:
Equally to STL the OBJ origin is the same as the origin during creation when using the export convention Z is Up and Y is Forward.
Collada DAE
In DAE vertices are saved in the following format:
Again DAE uses the same origin as STL and OBJ.
Expectation
As URDF gives transformations from root->link->mesh the orientation of the mesh is clearly defined. I'd expect that the mesh will placed accordingly.
As the test URDF, presented above, has only zero transformations and the mesh is oriented in all tested mesh formats without any orientation, I'd expect that in all simulators the X-arm of the mesh will point in X-direction, Y-arm in Y-direction and Z-arm in Z-direction.
Testing the simulators
pyBullet
PyBullet fulfils the expectation for all formats.
MARS
In the images X is pointing in to the right, Y up and Z into the screen. MARS fulfils the expectation for STL and DAE, but obj seems to be loaded differently. Here showing only the visual representation.
Further bugs
STL collisions #98
Please note that MARS seems to load STL Meshes also differently depending on whether the mesh is loaded as visual or collision (see also #98). I reproduced this issue
I also tested MARS with the collisions.
DAE Collisions
Loading the URDF with DAE as a collision mesh was not possible and threw a segmentation fault.
returned:
with the following backtrace
GAZEBO
For Gazebo I had to adapt the URDF a little, but those changes doesn't affect the behaviour of mesh interpretation:
Regarding the loading of meshes Gazebo beaves exactly as expected. In the images the Origin-Frame of Gazebo is pointing as follows: X is pointing away from the viewer into the screen plane, Y is pointing to the left and Z is pointing upwards. The greyish stuff in front is the shadow of the test mesh.
I suggest for MARS adding the orientation info how the obj-meshes should be parsed in SMURF.
The text was updated successfully, but these errors were encountered: