importing collada vs stl

[Benjamin Cohen]

moveit-users,

I'm new to the collada game so I don't know if this is my lack of understanding or a bug. 

I'm finding that if I use this function --> Mesh* createMeshFromResource(const std::string& resource, const Eigen::Vector3d &scale) in geometric_shapes/mesh_operations.h, I'm getting a different result when I send in a Collada file vs the STL equivalent (that I made by converting the .dae file in Meshlab). When I send in the STL file, I get the expected output but when I send in the .dae file, I get the correct mesh but rotated incorrectly.  I'm determining the expected output based on the axis that I'm visualizing when I'm opening the .dae file in Meshlab.

Can anyone clue me in as to why this is happening? Is it possible that createMeshFromResource() is not supposed to be used on Collada files?

In the attached shelf1.zip:

1) STL: shelf1/models/shelf.stl

The bookshelf is standing upright.

2) Collada: shelf1/models/cabwall0.dae

The bookshelf is laying down. Only a 90 degree rotation.

thanks a lot,

-- ben

[Ioan Sucan]

Ben,

I have not confirmed this, but I think assimp does not load the scale of collada files correctly, which would explain some differences. However, this does not explain rotation matrices. I'll take a look at the files you sent in a bit.

Ioan

[Benjamin Cohen]

Thanks Ioan!

To make it easier for you(anyone) to test, I made a small package with code that visualizes the STL and Collada versions of the mesh as well as the vertices that are parsed using createMeshFromResource(). 

(Reminder: I downloaded the Collada version of the file from 3D warehouse and converted it to STL using meshlab. It is possible that meshlab has a bug but I reloaded both files into meshlab and meshlab thinks that they both have the same axis).

I attached screenshots of rviz from when I ran the code on four different objects. The vertices of the shelf, door and sofa are rotated incorrectly. The car has the scale problem that you mentioned in your last email.

meshes are visualized at same pose:

stl: red

collada: blue

vertices are visualized at same pose:

stl: green

collada: yellow

To run the code:

1) Put in path and rosmake test_collada

2) Launch one of the launch files:

a) roslaunch test_collada shelf.launch

b) roslaunch test_collada door.launch

c) roslaunch test_collada sofa.launch

d) roslaunch test_collada car.launch

Thanks in advance man,

-- ben

[E. Gil Jones]

Hey guys,

Anyone figure anything out about this?  I think I may be having the same problem, though with DAE files generated from Blender.  I started to dig a little bit, and this may be a red herring, but I have a robot with a set of collada meshes that have the correct orientation and a set that don't.  The ones that work all have an entry at the top of the file that states <up_axis>Y_UP</up_axis>, and all the ones that don't have an entry that states <up_axis>Z_UP</up_axis>.  I looked at Ben's meshes, and all of them have Z_UP - the one that doesn't work for me.  It's possible that Meshlab interprets this value correctly - Rviz seems to do the right thing as well.  Or maybe this isn't the problem.  In any case, I'd love to see a fix for this - this could definitely silently be causing a bunch of problems, as shapes will be incorrectly loaded for collision detection purposes and cause unsafe behavior.

-Gil

[Jonathan Bohren]

This sounds like the problem that was fixed in rviz a long time ago:

https://code.ros.org/trac/ros-pkg/ticket/4274 

This resulted in:

https://github.com/ros-visualization/rviz/blob/hydro-devel/src/rviz/mesh_loader.cpp#L226

I fixed something similar in the realtime urdf filter last year:

https://github.com/blodow/realtime_urdf_filter/commit/7ecec29e1c2186498349f78dbb27d9739572854b

-j

--
Jonathan Bohren
Laboratory for Computational Sensing and Robotics
http://dscl.lcsr.jhu.edu/People/JonathanBohren

[Ioan Sucan]

Hey Gil,

What you are talking about does not sound like a red herring to me. I'll look into it. I think Jon pointed at the solution already.

Ioan

[Ioan Sucan]

Ok,

I looked at the code in geometric_shapes, which is responsible for loading meshes, and the code in rviz for loading meshes.

I tried this with the car mesh Ben had sent a while back, which has a Z_UP up axis.

The .stl file and .dae look different -- orientation seems messed up, as was pointed out in this thread.

If I change the collada file to use Y_UP instead of Z_UP, moveit loads the collada file at a different orientation (using assimp) and the mesh looks the same as the stl.

This tells me that the up axis is processed somehow by assimp, and moveit uses that transform for the loaded mesh. This suggest the transform is not properly considered when converting the .dae file to stl (for Ben's problem). I am reluctant to believe Blender has a bug loading .dae files; in any case, Gil, can you try modifying the up axis and see if that makes a difference in how your meshes are oriented in Blender?

As for the fix in rviz, that is skipping a root transform for the model. That has no effect for simple scenes with one mesh. Just in case, I tried it, and it made no difference for me. It may be the case that was important for older versions of assimp, but I am not sure it is relevant now.

Ioan

[E. Gil Jones]

Hmmm - changing the meshes from Z_UP to Y_UP means that they now get loaded correctly by moveit/assimp.  That suggests to me that perhaps the export assigned the incorrect orientation.  Changing the orientation does affect Blender's import - the Y_UP axis looks correct there as well.  I will check with the original person who exported to make sure that they check for this in the future.

In any case, for me this is solved.  Thanks for looking into it.

-Gil