0
$\begingroup$

Rosanswers logo

I'm currently trying to get a nicer looking robot model by adding color to the geometry of a robot body in blender (2.61) and exporting to .dae (COLLADA) instead of plain .stl mesh. My first try was to do this not by adding textures, but setting the material of different parts of the model to be colored differently. I'm talking about the model for a single link only, and everything works fine if exporting to stl (but there's no color then, obviously).

Now, if I add the colors and export to collada using blender I get the following:

  • Reimport to Blender: Looks fine, exactly as exported
  • Open with Meshlab: Parts of the geometry are scaled by a factor of ~30. Some vertex coordinates are very wrong.
  • Open with g3viewer: The rotations between different parts of the model are off
  • Use in URDF/gazebo: Model is not recognizable at all, there are a few polygon here and there
  • Use in URDF/rviz: Geometry is fine, material seems be interpreted not quite correctly (too bright), but the color settings seem to work (a red part is a little bit red)

ROS version used is electric from .debs on Natty/64bit.

Any tips on how to improve the results are greatly appreciated.

/edit: Image of gazebo and rviz side by side (for gazebo on the left, the bounding box is on, which is based on the .stl mesh). Obviously, in gazebo only a small fraction of faces is visualized, while geometry in rviz is fine.

image description

/edit2: The above was done by selecting all different needed parts of the model in Blender and then exporting to .dae. If I instead first join all different parts inside Blender by selecting them and pressing CTRL+J and then export, the model looks much better. It works in Meshlab and g3viewer, only gazebo still gives severe problems as can be seen here (even if it looks better than before):

image description

This actually looks kind of similar to the Pelican model posted in this question.

/edit: Update with latest insights: So far it looks like Blender 2.61 Collada export is somewhat broken, at least for me on my 64 bit Natty system (I stated oneiric above before, was wrong due to working on too many different machines :) ).

/edit: As it turned out, this is related to gazebo not coping well with quad based polygons that get exported into COLLADA files by Blender 2.61. See my answer below for details.

By opening .stl or .dae generated from Blender and re-saving as .dae using meshlab one can also get get .dae files that look non-broken in gazebo. Unfortunately, the vertex materials defined in Blender seem to get lost in the process. Another example:

.dae exported from Blender: gazebo result

.dae by opening Blender export and resaving in meshlab: gazebo result

DimitriProsser confirmed that the Blender export does not work for versions > 2.49 here

/edit: Comparison: Blender 2.61 export, gazebo on the left, rviz on the right Exported with 2.61, gazebo left, rviz right

Blender 2.49b export, gazebo on the left, rviz on the right image description

Unfortunately, lighting affects exactly the opposite side of the model (away from the light source), which looks like a problem with normals.

This is how it looks in rviz, gazebo and meshlab (note that in meshlab, normals appear to be correct and lighting there works). As can be seen, in both rviz and meshlab the back-facing polygons are drawn, while the front-facing ones are translucent for some reason:

image description

If I flip the normals on the model and export, the normals are facing into the wrong direction in meshlab, but in rviz and gazebo the front facing polygons are now drawn. Unfortunately, the lighting is wrong, as polys facing away from the light are now lit (In the gazebo screenshot, the light is below the quadrotor and the top is clearly lit up):

image description

I'm at a loss as to what else beside flipping normals I can do, any help is greatly appreciated.

/edit: I remodeled the quadrotor model and the "backfacing" error is gone now. It appears that gazebo sometimes still is a bit picky with regards to COLLADA files for no immediately recognizable reason.

/edit: The correct meshes and blender model are available here in svn as part of the hector_quadrotor_urdf package.


Originally posted by Stefan Kohlbrecher on ROS Answers with karma: 24361 on 2012-01-19

Post score: 6


Original comments

Comment by sam on 2012-02-09:
You have 6 pictures for me,and the first and second are disappeared. It says domain unregistered.

Comment by Stefan Kohlbrecher on 2012-02-09:
For me, all images are visible. Which ones are missing for you?

Comment by sam on 2012-02-09:
Are some pictures couldn't be seen in your post?

Comment by Stefan Kohlbrecher on 2012-01-20:
Hi John, the mesh (.stl and .dae versions) are available here: http://code.google.com/p/tu-darmstadt-ros-pkg/source/browse/#svn%2Ftrunk%2Fhector_quadrotor%2Fhector_quadrotor_urdf%2Fmeshes%2Fquadrotor I'll also update the original post. [Note: The meshes are corrected now and no more erroneous]

Comment by hsu on 2012-01-20:
can you please post or provide a link for the mesh? I have some ideas why this might be happening in gazebo and would like to test it out. Thanks.

Comment by Stefan Kohlbrecher on 2012-02-13:
I reuploaded both, they should appear now.

$\endgroup$

3 Answers 3

0
$\begingroup$

Rosanswers logo

URDF/rviz: There is a bug in RViz that replaces the ambient color of Collada materials by light gray if at least one component of the specified ambient color is 0.0 (see Ticket #5237). According to the changelog, this bug is fixed in robot_model 1.6.4, which seems to be not in the electric .deb repository yet.


Originally posted by Stefan Osswald with karma: 281 on 2012-01-19

This answer was NOT ACCEPTED on the original site

Post score: 3


Original comments

Comment by Stefan Kohlbrecher on 2012-01-20:
That's good news, so I guess I can wait this one out. So there's only the gazebo problem left (which might also disappear with the new version in Fuerte, but that's still some time away).

$\endgroup$
0
$\begingroup$

Rosanswers logo

I opened hector_quadrotor_urdf/meshes/quadrotor/quadrotor_base.stl with meshlab and simply re-saving it seems to have fixed some issues.image description

as for the dae file, I had to open it with meshlab and invert all normals for shading to appear. image description

Here are the links to the modified meshes: stl dae

For dae, add scale tag to scale correctly:

<mesh filename="package://hector_quadrotor_urdf/meshes/quadrotor/quadrotor_base.dae" scale="0.01 0.01 0.01"/>

Originally posted by hsu with karma: 5780 on 2012-01-23

This answer was NOT ACCEPTED on the original site

Post score: 2


Original comments

Comment by Stefan Kohlbrecher on 2012-01-26:
One more update to the original post. Getting closer to working around Blender (2.61) and gazebo not working together, but not quite there yet. There's a very strange rendering problem, as described at the bottom of the original question.

Comment by Stefan Kohlbrecher on 2012-01-23:
I updated the original post and added the blender source file, in case this is of interest to you, John.

Comment by Stefan Kohlbrecher on 2012-01-23:
Ok, scale seems to be some non-power of 10 though. I found that I can easily get a correctly scaled .dae by opening my original .stl and saving to .dae using meshlab though. Weird that exporting to .dae directly from Blender gives so many problems.

Comment by hsu on 2012-01-23:
@Stefan I updated the comment to scale the dae mesh. If dae is textured with belnder, wings3d or other tools, it should work with gazebo.

Comment by Stefan Kohlbrecher on 2012-01-23:
Too large scale: http://img718.imageshack.us/img718/8412/quadrotordaescale.png The green box is the bounding volume from the .stl (only set visual to use the .dae file, while collision comes from the correctly scaled .stl).

Comment by Stefan Kohlbrecher on 2012-01-23:
Thanks for the fast reply John. The .dae you provided indeed looks nice (has shading), but for me the scale is suddenly off by quite a huge amount (factor 10 or more). The model also lost color information. Is using materials for color supported by gazebo, or should I use textures?

$\endgroup$
0
$\begingroup$

Rosanswers logo

As noted here, .dae export does not work correctly for use of .dae meshes in gazebo since Blender versions > 2.49 . So everyone having problems like those described in my original posting should probably first check their Blender versions.

After playing around some more, it turns out that you have to convert your mesh data to triangles first for the Blender 2.61 .dae export (Select all, then CTRL+T). Apparently, quads will be saved to the COLLADA file otherwise, which gazebo cannot interpret correctly, leading to the polygon mess in the images I posted. The model occassionally still has it's backfacing polygons rendered for me though, as described with pictures in the original post. Update: In this case, a export to .stl, opening that file in meshlab, saving to stl again, and re-importing to blender usually fixes the issue. This doesn't hurt too much if one first models geometry, then checks it in gazebo, and only afterwards applies material and textures. OTOH, doing the materials and textures and finding out something with rendering is wrong afterwards can be pretty annoying.


Originally posted by Stefan Kohlbrecher with karma: 24361 on 2012-01-23

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by Stefan Kohlbrecher on 2012-01-28:
Recreated on the Gazebo KForge trac here: https://kforge.ros.org/gazebo/trac/ticket/40 Closed the one on code.ros.org as a duplicate.

Comment by Stefan Kohlbrecher on 2012-01-28:
Oops, just noted I'm on the wrong trac(k) ;) Should I recreate the ticket on kforge?

Comment by Stefan Kohlbrecher on 2012-01-27:
@John: Done, see https://code.ros.org/trac/ros-pkg/ticket/5360 Thanks for looking into it.

Comment by hsu on 2012-01-27:
good to know. Can you file a ticket for quads support on trac (https://kforge.ros.org/gazebo/trac)? Thanks!

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.