Hello List,
Nate, thank you very much for your help!
Unfortunately your world file produced the same result as I had before; the
pyramid collides with the ground plane but the laser does not recognize it (and
a collision with an dynamic objects does not work either). I am working with
the latest Gazebo and Ode SVN versions.
I made some experiments and found out that the ground plate of the pyramid is
recognized in physics - I made some screenshots of that to give you an
impression (using your config file + the model posted before):
www.volker-darius.de/projects/gazebo/Pyramid - dynamic, ground
collision works, rays dont.png
www.volker-darius.de/projects/gazebo/Pyramid - dynamic, ground
collision works, rays dont, bounding box.png
www.volker-darius.de/projects/gazebo/Pyramid - Ground plate collides,
rest doesnt.png
www.volker-darius.de/projects/gazebo/Pyramid - dynamic, ground
collision works, rays dont.png
www.volker-darius.de/projects/gazebo/Pyramid - Ground plate collides,
rest doesnt, other side.png
Well, I thought that it might be a ODE/OPCODE problem and recompiled the
ode-libraries with different configuration (debug/release, opcode/gimpact,
single/double precision..) parameters, but they all produced the same results.
Having a look at the code (physics/TrimeshGeom.cc), I found the following at
line 143f:
*(vertPtr+1) = (*pFloat++) * scale.x;
*(vertPtr+2) = (*pFloat++) * scale.y;
*(vertPtr+0) = (*pFloat++) * scale.z;
As the order of the vertices determines the direction of the normal, which is
probably used for collision detection..is it possible, that the order is wrong?
I know that the coordinate system of OGRE-meshes and Gazebo differs, so the
scale parameters might be right, but are the vertices-pointer too? I tried
changing them and it had indeed effect on the collision, it did not work very
accurate, but at least there was some reaction of the physics at all.
Ideas, anyone? :-))
Thanks in advance,
Volker
-----Ursprüngliche Nachricht-----
Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Nate Koenig
Gesendet: Montag, 3. Dezember 2007 20:03
An: Gazebo developers
Betreff: Re: [PlayerStage-Gazebo] trimesh / ode problem
Hello,
The pyramid model that you include in your email work for me. At the
end of this email is the world file that I used.
I don't plan on putting in support for physX, primarily because it's
not opensource and I don't want to pay for a physics engine.
-nate
<?xml version="1.0"?>
<gazebo:world
xmlns:xi="http://www.w3.org/2001/XInclude";
xmlns:gazebo="http://playerstage.sourceforge.net/gazebo/xmlschema/#gz";
xmlns:model="http://playerstage.sourceforge.net/gazebo/xmlschema/#model";
xmlns:sensor="http://playerstage.sourceforge.net/gazebo/xmlschema/#sensor";
xmlns:body="http://playerstage.sourceforge.net/gazebo/xmlschema/#body";
xmlns:geom="http://playerstage.sourceforge.net/gazebo/xmlschema/#geom";
xmlns:joint="http://playerstage.sourceforge.net/gazebo/xmlschema/#joint";
xmlns:interface="http://playerstage.sourceforge.net/gazebo/xmlschema/#interface";
xmlns:rendering="http://playerstage.sourceforge.net/gazebo/xmlschema/#rendering";
xmlns:renderable="http://playerstage.sourceforge.net/gazebo/xmlschema/#renderable";
xmlns:controller="http://playerstage.sourceforge.net/gazebo/xmlschema/#controller";
xmlns:physics="http://playerstage.sourceforge.net/gazebo/xmlschema/#physics"; >
<verbosity>5</verbosity>
<physics:ode>
<stepTime>0.02</stepTime>
<gravity>0 0 -9.80665</gravity>
<cfm>1e-5</cfm>
<erp>0.8</erp>
</physics:ode>
<rendering:gui>
<type>fltk</type>
<size>640 480</size>
<pos>0 0</pos>
</rendering:gui>
<rendering:ogre>
<ambient>1.0 1.0 1.0 1.0</ambient>
<sky>
<material>Gazebo/CloudySky</material>
</sky>
</rendering:ogre>
<model:physical name="plane1_model">
<xyz>0 0 0</xyz>
<rpy>0 0 0</rpy>
<static>true</static>
<body:plane name="plane1_body">
<geom:plane name="plane1_geom">
<normal>0 0 1</normal>
<size>2000 2000</size>
<segments>10 10</segments>
<uvTile>100 100</uvTile>
<material>Gazebo/GrassFloor</material>
</geom:plane>
</body:plane>
</model:physical>
<model:physical name="cam2_model">
<xyz>0 3.5 0.9</xyz>
<rpy>0 -15 90</rpy>
<static>true</static>
<body:empty name="cam2_body">
<sensor:camera name="cam2_sensor">
<imageSize>800 600</imageSize>
<hfov>60</hfov>
<nearClip>0.1</nearClip>
<farClip>100</farClip>
<saveFrames>false</saveFrames>
<saveFramePath>frames</saveFramePath>
</sensor:camera>
</body:empty>
</model:physical>
<model:physical name="pyramid">
<xyz>-2 0 1.5</xyz>
<static>false</static>
<body:trimesh name="pyramid_body">
<geom:trimesh name="pyramid_geom">
<xyz>0 0 0.25</xyz>
<mesh>unitpyramid.mesh</mesh>
<material>Gazebo/WoodPallet</material>
<mass>1.0</mass>
</geom:trimesh>
</body:trimesh>
</model:physical>
<model:physical name="laser">
<rpy> 0 0 180</rpy>
<include embedded="false">
<xi:include href="laser.model" />
</include>
</model:physical>
</gazebo:world>
On Dec 3, 2007 10:18 AM, Volker Darius <[EMAIL PROTECTED]> wrote:
> Hello list,
>
> I do have some problems with trimesh files in Gazebo. Ok, many people
> had problems with that before, I know, but.. in the end I tried a very
> simple example of a pyramid (see attached Ogre XML), which worked fine
> for visualization but not for collision / physics. The config file works
> fine for other, even far more complex meshes. By trying several
> variations, I found out that it must have something to do with the order
> of faces/vertices. Manually transforming a Cube to a Pyramid works, too
> (different face/vertice order..) and I do not really see the problem
> within that pyramid mesh file. Does anyone have an idea?
>
> The mesh file is exported from Maya via the Ogre-Exporter Plugin, which
> works with many, but unfortunately not all meshes. I attached the XML
> Code of the pyramid which can be easily converted to a mesh file using
> the OgreXMLExport tool which comes with Ogre.
>
> Btw, has someone thought about integrating PhysX into Gazebo, as it
> seems to be a bit more powerful with trimesh-trimesh collisions and can
> support a higher number of objects?
>
> Kind regards,
>
> Volker
>
> \\ ------------------------ UnitPyramid.mesh.xml
> ------------------------
> <mesh>
> <submeshes>
> <submesh material="lambert1" usesharedvertices="false"
> use32bitindexes="false" operationtype="triangle_list">
> <faces count="6">
> <face v1="0" v2="1" v3="2" />
> <face v1="3" v2="4" v3="5" />
> <face v1="6" v2="7" v3="8" />
> <face v1="9" v2="10" v3="11" />
> <face v1="12" v2="13" v3="14" />
> <face v1="15" v2="16" v3="17" />
> </faces>
> <geometry vertexcount="18">
> <vertexbuffer positions="true" texture_coord_dimensions_0="2"
> texture_coords="1">
> <vertex>
> <position x="-0.5" y="-0.353553" z="-0.5" />
> <texcoord u="0.5" v="1" />
> </vertex>
> <vertex>
> <position x="0.5" y="-0.353553" z="-0.5" />
> <texcoord u="0.75" v="0.75" />
> </vertex>
> <vertex>
> <position x="-0.5" y="-0.353553" z="0.5" />
> <texcoord u="0.25" v="0.75" />
> </vertex>
> <vertex>
> <position x="-0.5" y="-0.353553" z="0.5" />
> <texcoord u="0.25" v="0.75" />
> </vertex>
> <vertex>
> <position x="0.5" y="-0.353553" z="-0.5" />
> <texcoord u="0.75" v="0.75" />
> </vertex>
> <vertex>
> <position x="0.5" y="-0.353553" z="0.5" />
> <texcoord u="0.5" v="0.5" />
> </vertex>
> <vertex>
> <position x="-0.5" y="-0.353553" z="-0.5" />
> <texcoord u="0.5" v="1" />
> </vertex>
> <vertex>
> <position x="-0.5" y="-0.353553" z="0.5" />
> <texcoord u="0.25" v="0.75" />
> </vertex>
> <vertex>
> <position x="0" y="0.353553" z="0" />
> <texcoord u="0.5" v="-0" />
> </vertex>
> <vertex>
> <position x="-0.5" y="-0.353553" z="0.5" />
> <texcoord u="0.25" v="0.75" />
> </vertex>
> <vertex>
> <position x="0.5" y="-0.353553" z="0.5" />
> <texcoord u="0.5" v="0.5" />
> </vertex>
> <vertex>
> <position x="0" y="0.353553" z="0" />
> <texcoord u="0.5" v="-0" />
> </vertex>
> <vertex>
> <position x="0.5" y="-0.353553" z="0.5" />
> <texcoord u="0.5" v="0.5" />
> </vertex>
> <vertex>
> <position x="0.5" y="-0.353553" z="-0.5" />
> <texcoord u="0.75" v="0.75" />
> </vertex>
> <vertex>
> <position x="0" y="0.353553" z="0" />
> <texcoord u="0.5" v="-0" />
> </vertex>
> <vertex>
> <position x="0.5" y="-0.353553" z="-0.5" />
> <texcoord u="0.75" v="0.75" />
> </vertex>
> <vertex>
> <position x="-0.5" y="-0.353553" z="-0.5" />
> <texcoord u="0.5" v="1" />
> </vertex>
> <vertex>
> <position x="0" y="0.353553" z="0" />
> <texcoord u="0.5" v="-0" />
> </vertex>
> </vertexbuffer>
> </geometry>
> </submesh>
> </submeshes>
> </mesh>
> \\ ------------------------ UnitPyramid.mesh.xml
> ------------------------
> __
>
> volker darius
>
>
>
>
> -------------------------------------------------------------------------
> SF.Net email is sponsored by: The Future of Linux Business White Paper
> from Novell. From the desktop to the data center, Linux is going
> mainstream. Let it simplify your IT future.
> http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
> _______________________________________________
> Playerstage-gazebo mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo
>
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Playerstage-gazebo mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Playerstage-gazebo mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/playerstage-gazebo
