error loading a mesh .stl with rviz and moveit!

[Raul merino lopez]

Hello

I have this mesh dxl-hok-coup.STL (attached), and cant load it when i run my urdf on rviz, it says:

[ERROR] [1388764517.135417078]: Could not load resource [package://manfred_common/meshes/visual/dxl-hok-coup.STL ]: Unable to open file "package://manfred_common/meshes/visual/dxl-hok-coup.STL ".

[ERROR] [1388764517.135751973]: Could not load model 'package://manfred_common/meshes/visual/dxl-hok-coup.STL ' for link 'chapa': OGRE EXCEPTION(6:FileNotFoundException): Cannot locate resource package://manfred_common/meshes/visual/dxl-hok-coup.STL  in resource group Autodetect or any other group. in ResourceGroupManager::openResource at /build/buildd/ogre-1.7.4/OgreMain/src/OgreResourceGroupManager.cpp (line 753)

[ERROR] [1388764517.135907125]: Could not load model 'package://manfred_common/meshes/visual/dxl-hok-coup.STL ' for link 'chapa': OGRE EXCEPTION(6:FileNotFoundException): Cannot locate resource package://manfred_common/meshes/visual/dxl-hok-coup.STL  in resource group Autodetect or any other group. in ResourceGroupManager::openResource at /build/buildd/ogre-1.7.4/OgreMain/src/OgreResourceGroupManager.cpp (line 753)

The problem is that i can load it and visualizate with MeshLab or another one viewer. I got this file convering it from a dwg file. Some idea?

Thanks you

[Dave Hershberger]

Is "manfred_common" a ROS package?  In order for resource URIs to work which start with "package://", the first directory-name needs to be a ROS package that you can "roscd" into.  If it is, then you also need to make sure that the shell environment that RViz is running under also knows about it.

Finally, this looks like a "file not found" error.  If you do "roscd manfred_common; ls meshes/visual/dxl-hok-coup.STL", do you see the file?

Dave

[Daniel Solomon]

It looks like your file is a binary STL. Your file will have to be in STL ASCII format to load. I believe that when it fails to load, you will get the messages you described. You can convert the file using meshlab, and if it still gives you a problem, try converting it to a collada (.dae) format.

[G.A. vd. Hoorn - 3ME]

On 04/01/2014 01:09, Daniel Solomon wrote:
> It looks like your file is a binary STL. Your file will have to be in STL
> ASCII format to load. I believe that when it fails to load, you will get
> the messages you described. You can convert the file using meshlab, and if
> it still gives you a problem, try converting it to a collada (.dae) format.

In the Fanuc stack we've been using binary STLs exclusively, and we
haven't run into any problems with that. What is important to check
though is the well known 'solid' string that cannot appear in the header.

But I think Dave's answer is more likely to be the cause in this case.


Gijs

[Raul merino lopez]

The ROS path is enabled, and works. The file is inside meshes/visual, but it dont load. I have about 30 meshes .STL and all load without problem but the dxl-hok-coup.STL dont.

[G.A. vd. Hoorn - 3ME]

On 04/01/2014 14:01, Raul merino lopez wrote:
> The ROS path is enabled, and works. The file is inside meshes/visual, but
> it dont load. I have about 30 meshes .STL and all load without problem but
> the dxl-hok-coup.STL dont.

Linux is case sensitive: make sure the filename you have in your URDF is
exactly the same as the file itself (ie: .stl vs .STL).

It would also help if you could post the URDF somewhere (pastebin?).



PS: this would actually have been a good question for ROS Answers.

[Dave Hershberger]

Hey, I looked at the header for the file in question:

hersh@bunnies$ od -ax dxl-hok-coup.STL | head
0000000 A u t o C A D sp s o l i d nul nul nul
7541 6f74 4143 2044 6f73 696c 0064 0000
0000020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
0000 0000 0000 0000 0000 0000 0000 0000
*
0000120 X eot nul nul ( ( enq > nul nul nul nul U O } ?
04d8 0000 a8a8 be05 0000 8000 cf55 bf7d
0000140 R h K E \ 0 , E [ w { @ R h K E
68d2 45cb b0dc 45ac f7db 407b 68d2 45cb
0000160 \ sp , E [ w { @ ; f K E \ 0 , E

And it does indeed include the word "solid". So why is that a problem?

Dave
________________________________________
From: moveit...@googlegroups.com [moveit...@googlegroups.com] on behalf of G.A. vd. Hoorn - 3ME [g.a.van...@tudelft.nl]
Sent: Saturday, January 04, 2014 3:09 AM
To: moveit...@googlegroups.com
Subject: Re: error loading a mesh .stl with rviz and moveit!

[G.A. vd. Hoorn - 3ME]

On 04/01/2014 16:28, Dave Hershberger wrote:
> Hey, I looked at the header for the file in question:
>
> hersh@bunnies$ od -ax dxl-hok-coup.STL | head
> 0000000 A u t o C A D sp s o l i d nul nul nul
> 7541 6f74 4143 2044 6f73 696c 0064 0000
> 0000020 nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul nul
> 0000 0000 0000 0000 0000 0000 0000 0000
> *
> 0000120 X eot nul nul ( ( enq> nul nul nul nul U O } ?
> 04d8 0000 a8a8 be05 0000 8000 cf55 bf7d
> 0000140 R h K E \ 0 , E [ w { @ R h K E
> 68d2 45cb b0dc 45ac f7db 407b 68d2 45cb
> 0000160 \ sp , E [ w { @ ; f K E \ 0 , E
>
> And it does indeed include the word "solid". So why is that a problem?

Some STL loaders incorrectly assume the file is an ASCII STL file if
they find the string 'solid' in the first N bytes. I've seen the one
used by RViz / Ogre do it many times (in the past).

Simple work-around is to do a 'solid' -> 'dilos' search/replace on the
files.


Gijs

[Dave Hershberger]

What version of rviz is having this trouble, I wonder? I have rviz version 1.10.9 installed, and I just displayed the mesh with it in a Marker message. Attached see the image of the mesh from rviz... does this look right? It has an enormous offset, like 6000 meters, so it was kind of hard to find, but it loaded without error.

I looked in the rviz source code and it appears to *only* support binary STL files. I haven't tried ascii ones though. There is nothing in the code that looks for the word "solid". RViz seems to implement its own loading of the binary STL files, and it just skips the header entirely based on a byte count. Maybe I'm missing something where it tries a library first, but the code is not that complicated.

Dave

________________________________________
From: G.A. vd. Hoorn - 3ME [g.a.van...@tudelft.nl]
Sent: Saturday, January 04, 2014 7:43 AM
To: Dave Hershberger
Cc: moveit...@googlegroups.com

[G.A. vd. Hoorn - 3ME]

On 04/01/2014 16:57, Dave Hershberger wrote:
> What version of rviz is having this trouble, I wonder? I have rviz version 1.10.9 installed, and I just displayed the mesh with it in a Marker message. Attached see the image of the mesh from rviz... does this look right? It has an enormous offset, like 6000 meters, so it was kind of hard to find, but it loaded without error.
>
> I looked in the rviz source code and it appears to *only* support binary STL files. I haven't tried ascii ones though. There is nothing in the code that looks for the word "solid". RViz seems to implement its own loading of the binary STL files, and it just skips the header entirely based on a byte count. Maybe I'm missing something where it tries a library first, but the code is not that complicated.

I can't remember what version(s) I was using when I ran into this issue,
but this isn't an RViz-only problem: many STL loaders have this problem.

I also can't recall the particular error messages I've seen, but it
causes RViz (and the MoveIt setup assistant) to consider the mesh to be
corrupt. There are probably some questions on ROS Answers where this
came up as well.


Gijs

[G.A. vd. Hoorn - 3ME]

On 04/01/2014 17:07, G.A. vd. Hoorn - 3ME wrote:
> On 04/01/2014 16:57, Dave Hershberger wrote:
>> What version of rviz is having this trouble, I wonder? I have rviz
>> version 1.10.9 installed, and I just displayed the mesh with it in a
>> Marker message. Attached see the image of the mesh from rviz... does
>> this look right? It has an enormous offset, like 6000 meters, so it
>> was kind of hard to find, but it loaded without error.
>>
>> I looked in the rviz source code and it appears to *only* support
>> binary STL files. I haven't tried ascii ones though. There is nothing
>> in the code that looks for the word "solid". RViz seems to implement
>> its own loading of the binary STL files, and it just skips the header
>> entirely based on a byte count. Maybe I'm missing something where it
>> tries a library first, but the code is not that complicated.
>
> I can't remember what version(s) I was using when I ran into this issue,
> but this isn't an RViz-only problem: many STL loaders have this problem.
>
> I also can't recall the particular error messages I've seen, but it
> causes RViz (and the MoveIt setup assistant) to consider the mesh to be
> corrupt. There are probably some questions on ROS Answers where this
> came up as well.

Found one:

http://answers.ros.org/question/11569/planning_component_visualizer-bug/

I was trying to remember the assimp error message.

But I doubt this is what the OP is seeing, as he didn't report seeing
any such error message.


Gijs