pyode-user — PyODE User Discussions

Re: [Pyode-user] dependence upon position?

[Ethan Glasser-C. <gl...@cs...>]

mi...@mi... wrote:
> but their behavior is markedly different. Why?

They behave the same on my machine, but both generate this message:

ODE Message 3: LCP internal error, s <=3D 0 (s=3D-0.0000e+00)

Ethan

Re: [Pyode-user] dependence upon position?

[Hart's A. <bha...@ya...>]

setting your worlds ERP and CFM to zero seems to fix this, not sure why tho..
-brett


--- mi...@mi... wrote:

> Hi folks,
> 
> A friend (he's probably joining pyode-user as I send this) sent me the two small python scripts
> (attached). They both drop a block near another. They are the same except for one being at
> (0,0,0) the other at (10,10,10), but their behavior is markedly different. Why?
> 
> Is there any way to ensure that behavior has positional independence? ...at least in fairly
> ordinary ranges. I know things will get crazy near the limits of numerical precision, but this
> is just a little over 10 units from the center of the universe.
> 
> Is there some other parameter that needs to be handled to take account of the position?
> 
> Best wishes,
> 
>     - Miriam
> -- 
> ---------=---------=---------=---------=---------=---------=------
> A life! Cool! Where can I download one of those from?
> ---------=---------=---------=---------=---------=---------=------
> Website: http://miriam-english.org
> Blog: http://www.livejournal.com/users/miriam_e/
> > # pyODE example 3: Collision detection
> # origin
> 
> # Originally by Matthias Baas.
> # Updated by Pierre Gay to work without pygame or cgkit.
> 
> import sys, os, random, time
> from math import *
> from OpenGL.GL import *
> from OpenGL.GLU import *
> from OpenGL.GLUT import *
> 
> import ode
> 
> # geometric utility functions
> def scalp (vec, scal):
>     vec[0] *= scal
>     vec[1] *= scal
>     vec[2] *= scal
> 
> def length (vec):
>     return sqrt (vec[0]**2 + vec[1]**2 + vec[2]**2)
> 
> # prepare_GL
> def prepare_GL():
>     """Prepare drawing.
>     """
> 
>     # Viewport
>     glViewport(0,0,640,480)
> 
>     # Initialize
>     glClearColor(0.8,0.8,0.9,0)
>     glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
>     glEnable(GL_DEPTH_TEST)
>     glDisable(GL_LIGHTING)
>     glEnable(GL_LIGHTING)
>     glEnable(GL_NORMALIZE)
>     glShadeModel(GL_FLAT)
> 
>     # Projection
>     glMatrixMode(GL_PROJECTION)
>     glLoadIdentity()
>     gluPerspective (45,1.3333,0.2,20)
> 
>     # Initialize ModelView matrix
>     glMatrixMode(GL_MODELVIEW)
>     glLoadIdentity()
> 
>     # Light source
>     glLightfv(GL_LIGHT0,GL_POSITION,[0,0,1,0])
>     glLightfv(GL_LIGHT0,GL_DIFFUSE,[1,1,1,1])
>     glLightfv(GL_LIGHT0,GL_SPECULAR,[1,1,1,1])
>     glEnable(GL_LIGHT0)
> 
>     # View transformation
>     gluLookAt (2.4, 3.6, 4.8, 0.5, 0.5, 0, 0, 1, 0)
> 
> # draw_body
> def draw_body(body):
>     """Draw an ODE body.
>     """
> 
>     x,y,z = body.getPosition()
>     R = body.getRotation()
>     #rot = [R[0], R[3], R[6], 0.,
>     #       R[1], R[4], R[7], 0.,
>     #       R[2], R[5], R[8], 0.,
>     #       x, y, z, 1.0]
>     rot = [1, 0.0, 0.0, 0.0,
>            0.0, 1, 0.0, 0.0,
>            0.0, 0.0, 1.0, 0.0,
>            x, y, z, 1.0]
>     glPushMatrix()
>     glMultMatrixd(rot)
>     if body.shape=="box":
>         sx,sy,sz = body.boxsize
>         glScale(sx, sy, sz)
>         glutSolidCube(1)
>     glPopMatrix()
> 
> 
> # create_box
> def create_box(world, space, density, lx, ly, lz):
>     """Create a box body and its corresponding geom."""
> 
>     # Create body
>     body = ode.Body(world)
>     M = ode.Mass()
>     M.setBox(density, lx, ly, lz)
>     body.setMass(M)
> 
>     # Set parameters for drawing the body
>     body.shape = "box"
>     body.boxsize = (lx, ly, lz)
> 
>     # Create a box geom for collision detection
>     geom = ode.GeomBox(space, lengths=body.boxsize)
>     geom.setBody(body)
> 
>     return body
> 
> # create box object
> def create_object(posx, posy, posz):
>     """create one box at a given position."""
> 
>     global bodies, counter, objcount
> 
>     body = create_box(world, space, 1000, 1.0,1.0,1.0)
>     body.setPosition((posx, posy, posz))
>     bodies.append(body)
>     #counter=0
>     objcount+=1
> 	
> 
> # drop_object
> def drop_object(posx, posy, posz):
>     """Drop an object into the scene."""
> 
>     global bodies, counter, objcount
> 
>     body = create_box(world, space, 1000, 1.0,1.0,1.0)
>     body.setPosition((posx, posy, posz))
>     bodies.append(body)
>     #counter=0
>     objcount+=1
> 
> # Collision callback
> def near_callback(args, geom1, geom2):
>     """Callback function for the collide() method.
> 
>     This function checks if the given geoms do collide and
>     creates contact joints if they do.
>     """
> 
>     # Check if the objects do collide
>     contacts = ode.collide(geom1, geom2)
> 
>     # Create contact joints
>     world,contactgroup = args
>     for c in contacts:
>         c.setBounce(0.2)
>         c.setMu(5000)
>         j = ode.ContactJoint(world, contactgroup, c)
>         j.attach(geom1.getBody(), geom2.getBody())
> 
> 
> 
> ######################################################################
> 
> # Initialize Glut
> glutInit ([])
> 
> # Open a window
> glutInitDisplayMode (GLUT_RGB | GLUT_DOUBLE)
> 
> x = 0
> y = 0
> width = 640
> height = 480
> glutInitWindowPosition (x, y);
> glutInitWindowSize (width, height);
> glutCreateWindow ("(0,0,0)")
> 
> # Create a world object
> world = ode.World()
> world.setGravity( (0,-9.81,0) )
> world.setERP(0.8)
> world.setCFM(1E-5)
> 
> # Create a space object
> space = ode.Space()
> 
> # Create a plane geom which prevent the objects from falling forever
> floor = ode.GeomPlane(space, (0,1,0), 0)
> 
> # A list with ODE bodies
> bodies = []
> 
> # A joint group for the contact joints that are generated whenever
> # two bodies collide
> contactgroup = ode.JointGroup()
> 
> # Some variables used inside the simulation loop
> fps = 50
> dt = 1.0/fps
> running = True
> state = 0
> counter = 0
> objcount = 0
> lasttime = time.time()
> 
> 
> # keyboard callback
> def _keyfunc (c, x, y):
>     sys.exit (0)
> 
> glutKeyboardFunc (_keyfunc)
> 
> # draw callback
> def _drawfunc ():
> 
=== message truncated ===> # pyODE example 3: Collision detection
> # 1000
> 
> # Originally by Matthias Baas.
> # Updated by Pierre Gay to work without pygame or cgkit.
> 
> import sys, os, random, time
> from math import *
> from OpenGL.GL import *
> from OpenGL.GLU import *
> from OpenGL.GLUT import *
> 
> import ode
> 
> # geometric utility functions
> def scalp (vec, scal):
>     vec[0] *= scal
>     vec[1] *= scal
>     vec[2] *= scal
> 
> def length (vec):
>     return sqrt (vec[0]**2 + vec[1]**2 + vec[2]**2)
> 
> # prepare_GL
> def prepare_GL():
>     """Prepare drawing.
>     """
> 
>     # Viewport
>     glViewport(0,0,640,480)
> 
>     # Initialize
>     glClearColor(0.8,0.8,0.9,0)
>     glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
>     glEnable(GL_DEPTH_TEST)
>     glDisable(GL_LIGHTING)
>     glEnable(GL_LIGHTING)
>     glEnable(GL_NORMALIZE)
>     glShadeModel(GL_FLAT)
> 
>     # Projection
>     glMatrixMode(GL_PROJECTION)
>     glLoadIdentity()
>     gluPerspective (45,1.3333,0.2,20)
> 
>     # Initialize ModelView matrix
>     glMatrixMode(GL_MODELVIEW)
>     glLoadIdentity()
> 
>     # Light source
>     glLightfv(GL_LIGHT0,GL_POSITION,[0,0,1,0])
>     glLightfv(GL_LIGHT0,GL_DIFFUSE,[1,1,1,1])
>     glLightfv(GL_LIGHT0,GL_SPECULAR,[1,1,1,1])
>     glEnable(GL_LIGHT0)
> 
>     # View transformation
>     gluLookAt (12.4, 13.6, 14.8, 10.5, 10.5, 10, 0, 1, 0)
> 
> # draw_body
> def draw_body(body):
>     """Draw an ODE body.
>     """
> 
>     x,y,z = body.getPosition()
>     R = body.getRotation()
>     #rot = [R[0], R[3], R[6], 0.,
>     #       R[1], R[4], R[7], 0.,
>     #       R[2], R[5], R[8], 0.,
>     #       x, y, z, 1.0]
>     rot = [1, 0.0, 0.0, 0.0,
>            0.0, 1, 0.0, 0.0,
>            0.0, 0.0, 1.0, 0.0,
>            x, y, z, 1.0]
>     glPushMatrix()
>     glMultMatrixd(rot)
>     if body.shape=="box":
>         sx,sy,sz = body.boxsize
>         glScale(sx, sy, sz)
>         glutSolidCube(1)
>     glPopMatrix()
> 
> 
> # create_box
> def create_box(world, space, density, lx, ly, lz):
>     """Create a box body and its corresponding geom."""
> 
>     # Create body
>     body = ode.Body(world)
>     M = ode.Mass()
>     M.setBox(density, lx, ly, lz)
>     body.setMass(M)
> 
>     # Set parameters for drawing the body
>     body.shape = "box"
>     body.boxsize = (lx, ly, lz)
> 
>     # Create a box geom for collision detection
>     geom = ode.GeomBox(space, lengths=body.boxsize)
>     geom.setBody(body)
> 
>     return body
> 
> # create box object
> def create_object(posx, posy, posz):
>     """create one box at a given position."""
> 
>     global bodies, counter, objcount
> 
>     body = create_box(world, space, 1000, 1.0,1.0,1.0)
>     body.setPosition((posx, posy, posz))
>     bodies.append(body)
>     #counter=0
>     objcount+=1
> 	
> 
> # drop_object
> def drop_object(posx, posy, posz):
>     """Drop an object into the scene."""
> 
>     global bodies, counter, objcount
> 
>     body = create_box(world, space, 1000, 1.0,1.0,1.0)
>     body.setPosition((posx, posy, posz))
>     bodies.append(body)
>     #counter=0
>     objcount+=1
> 
> # Collision callback
> def near_callback(args, geom1, geom2):
>     """Callback function for the collide() method.
> 
>     This function checks if the given geoms do collide and
>     creates contact joints if they do.
>     """
> 
>     # Check if the objects do collide
>     contacts = ode.collide(geom1, geom2)
> 
>     # Create contact joints
>     world,contactgroup = args
>     for c in contacts:
>         c.setBounce(0.2)
>         c.setMu(5000)
>         j = ode.ContactJoint(world, contactgroup, c)
>         j.attach(geom1.getBody(), geom2.getBody())
> 
> 
> 
> ######################################################################
> 
> # Initialize Glut
> glutInit ([])
> 
> # Open a window
> glutInitDisplayMode (GLUT_RGB | GLUT_DOUBLE)
> 
> x = 0
> y = 0
> width = 640
> height = 480
> glutInitWindowPosition (x, y);
> glutInitWindowSize (width, height);
> glutCreateWindow ("(10,10,10)")
> 
> # Create a world object
> world = ode.World()
> world.setGravity( (0,-9.81,0) )
> world.setERP(0.8)
> world.setCFM(1E-5)
> 
> # Create a space object
> space = ode.Space()
> 
> # Create a plane geom which prevent the objects from falling forever
> floor = ode.GeomPlane(space, (0,1,0), 10)
> 
> # A list with ODE bodies
> bodies = []
> 
> # A joint group for the contact joints that are generated whenever
> # two bodies collide
> contactgroup = ode.JointGroup()
> 
> # Some variables used inside the simulation loop
> fps = 50
> dt = 1.0/fps
> running = True
> state = 0
> counter = 0
> objcount = 0
> lasttime = time.time()
> 
> 
> # keyboard callback
> def _keyfunc (c, x, y):
>     sys.exit (0)
> 
> glutKeyboardFunc (_keyfunc)
> 
> # draw callback
> def _drawfunc ():
> 
=== message truncated ===>
-------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV>
_______________________________________________
> Pyode-user mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyode-user
> 



 
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com

[Pyode-user] effect of start time on ode physics

[chris <dra...@gm...>]

Hi,

I have been doing some experiments as part of my phd and, tho the
theory predicts some differences in physics results, it was still
surprising to see it in actuality. the following differ only in the
start time (the second has a start time of 8000), but the final
resting place of the RH block is quite different from its position
when running the first example, even tho the spatial positions, size
of everything, duration of sim and grav constant are the same.

http://www.planet-earth.org/pyode/preciseBlocks.py
http://www.planet-earth.org/pyode/preciseBlocksTime8000.py

Can anyone explain to me what is happening inside ode to produce these
different results? I can explain the results abstractly, but not in
detailed terms relating to the specifics of pyode.

thanks,

chris

[Pyode-user] dependence upon position?

[<mi...@mi...>]

Hi folks,

A friend (he's probably joining pyode-user as I send this) sent me the two small python scripts (attached). They both drop a block near another. They are the same except for one being at (0,0,0) the other at (10,10,10), but their behavior is markedly different. Why?

Is there any way to ensure that behavior has positional independence? ...at least in fairly ordinary ranges. I know things will get crazy near the limits of numerical precision, but this is just a little over 10 units from the center of the universe.

Is there some other parameter that needs to be handled to take account of the position?

Best wishes,

    - Miriam
-- 
---------=---------=---------=---------=---------=---------=------
A life! Cool! Where can I download one of those from?
---------=---------=---------=---------=---------=---------=------
Website: http://miriam-english.org
Blog: http://www.livejournal.com/users/miriam_e/

Re: [Pyode-user] PATCH: LMotor

[Matthias B. <ba...@ir...>]

Ethan Glasser-Camp wrote:
> [Sorry Matthias for the triplicate post! Yeesh, where is my brain?]

No problem. :)

> Matthias Baas wrote:
>> Finally, I've upgraded to ODE 0.7 as well (Windows only, using the 
>> binaries). I haven't committed the updated setup script yet. It seems 
>> that trimeshes are now always part of ODE and we don't have to 
>> distinguish between the two versions anymore. Is this correct? (this 
>> would simplify the setup script quite a bit).
> 
> Hi,
> 
> First, thanks for applying my patches. :)

You're welcome.

> Second, it looks to me like you can still run ODE's ./configure with a
> --disable-opcode, which disables trimesh support. But I admit I don't
> really know a lot about either codebase. I, too, would prefer if
> trimesh support was mandatory, but I'm not sure if this is actually
> the case.

I suppose if we'd also want to support ODE without trimesh support we 
would have to parse ode/config.h and check the dTRIMESH_ENABLED macro.

- Matthias -

Re: [Pyode-user] Installation

[Matthias B. <ba...@ir...>]

Branton Davis wrote:
> I was confused from the start, as the PyODE setup script expects a 
> user-settings file to be located under a config directory, neither of 
> which exists in my ODE installation, unless I've missed something.  My 
> ODE installation consists of a directory of 21 C header files 
> (/usr/local/include/ode) as well as /usr/local/lib/libode.a .  So, the 
> first thing that comes to mind is that since the PyODE install docs 
> state that it requires ODE 0.5, it must ONLY work with that version.  Is 
> this correct?  If so, where do I get this version, since ode.org seems 
> to only offer the latest and greatest (again, unless I've missed something)?

Please try the setup script that is attached to this mail and let me 
know if it worked for you. In your case it should even work right out of 
the box.

- Matthias -

Re: [Pyode-user] PATCH: LMotor

[Ethan Glasser-C. <gl...@cs...>]

[Sorry Matthias for the triplicate post! Yeesh, where is my brain?]

Matthias Baas wrote:
> Finally, I've upgraded to ODE 0.7 as well (Windows only, using the=20
> binaries). I haven't committed the updated setup script yet. It seems=20
> that trimeshes are now always part of ODE and we don't have to=20
> distinguish between the two versions anymore. Is this correct? (this=20
> would simplify the setup script quite a bit).

Hi,

First, thanks for applying my patches. :)

Second, it looks to me like you can still run ODE's ./configure with a
--disable-opcode, which disables trimesh support. But I admit I don't
really know a lot about either codebase. I, too, would prefer if
trimesh support was mandatory, but I'm not sure if this is actually
the case.

Ethan

[Pyode-user] Installation

[Branton D. <san...@gm...>]

Hello!  I just heard about PyODE and decided to try it out, but can't 
seem to get anywhere.  I would truly appreciate any help.

Here are my details:

I'm running Mac OS 10.4.7 on an Intel Macbook Pro (2.16 GHz Intel Core Duo).
I have Python 2.4.4 and it works dandy.
I have ode 0.7 installed and running just fine (all the tests work).
I also have Pyrex 0.9.4.1 installed, though I haven't tested it.

I was confused from the start, as the PyODE setup script expects a 
user-settings file to be located under a config directory, neither of 
which exists in my ODE installation, unless I've missed something.  My 
ODE installation consists of a directory of 21 C header files 
(/usr/local/include/ode) as well as /usr/local/lib/libode.a .  So, the 
first thing that comes to mind is that since the PyODE install docs 
state that it requires ODE 0.5, it must ONLY work with that version.  Is 
this correct?  If so, where do I get this version, since ode.org seems 
to only offer the latest and greatest (again, unless I've missed something)?

Thanks for any help!

Branton Davis

Re: [Pyode-user] PATCH: Cylinder

[Matthias B. <ba...@ir...>]

Ethan Glasser-Camp wrote:
> Adds support for the GeomCylinder type.

Your patches from yesterday are applied.
Thanks!

- Matthias -

Re: [Pyode-user] PATCH: LMotor

[Matthias B. <ba...@ir...>]

Ethan Glasser-Camp wrote:
> -    dGeomID dCreateCCylinder (dSpaceID space, dReal radius, dReal length)
> +    dGeomID dCreateCapsule (dSpaceID space, dReal radius, dReal length)

Is there actually a difference between those functions (except the 
name)? Or are those just aliases for the same functions. Will the 
ccylinder functions ever be removed from the API?

- Matthias -

[Pyode-user] PATCH: Cylinder

[Ethan Glasser-C. <gl...@cs...>]

Adds support for the GeomCylinder type.

Ethan

Re: [Pyode-user] PATCH: LMotor

[Ethan Glasser-C. <gl...@cs...>]

Ethan Glasser-Camp wrote:
> I'd like to write support for Cylinder and change CCylinder to
> Capsule, but I haven't written these patches yet.

The attached patch should change CCylinder to Capsule, but keep the
GeomCCylinder name around for backwards compatibility.

Ethan

Re: [Pyode-user] PATCH: LMotor

[Ethan Glasser-C. <gl...@cs...>]

Ethan Glasser-Camp wrote:
> There is still at least one (minor) thing wrong with LMotor patch I
> wrote, but I'll address these in a further patch.

Here -- rel is actually not ignored in ODE 0.7, there's just a comment
in the source code that says it is. And I added LMotor to the list of
classes in ode.pyx.

Ethan

Re: [Pyode-user] PATCH: LMotor

[Ethan Glasser-C. <gl...@cs...>]

Matthias Baas wrote:
> Ethan Glasser-Camp wrote:
>> Ethan Glasser-Camp wrote:
>>> Yikes, looks like I goofed. The getMode/setMode functions should be
>> Jeez, can you tell I never used pyrex before?
>>
>> This time the patch actually builds, and appears to work.
>=20
> I've just applied and committed the patch. I've also applied the patch =

> that Leonard Ritter has posted a while ago that adds support for the=20
> Plane2DJoint.

There is still at least one (minor) thing wrong with LMotor patch I
wrote, but I'll address these in a further patch.

> Are there any other mails I've overlooked that also contain patches=20
> you'd like to be applied?

I'd like to write support for Cylinder and change CCylinder to
Capsule, but I haven't written these patches yet.

Ethan

Re: [Pyode-user] PATCH: LMotor

[Matthias B. <ba...@ir...>]

Ethan Glasser-Camp wrote:
> Ethan Glasser-Camp wrote:
>> Yikes, looks like I goofed. The getMode/setMode functions should be
> 
> Jeez, can you tell I never used pyrex before?
> 
> This time the patch actually builds, and appears to work.

I've just applied and committed the patch. I've also applied the patch 
that Leonard Ritter has posted a while ago that adds support for the 
Plane2DJoint.

Finally, I've upgraded to ODE 0.7 as well (Windows only, using the 
binaries). I haven't committed the updated setup script yet. It seems 
that trimeshes are now always part of ODE and we don't have to 
distinguish between the two versions anymore. Is this correct? (this 
would simplify the setup script quite a bit).

Are there any other mails I've overlooked that also contain patches 
you'd like to be applied?

- Matthias -

Re: [Pyode-user] PATCH: LMotor

[Ethan Glasser-C. <gl...@cs...>]

Ethan Glasser-Camp wrote:
> Yikes, looks like I goofed. The getMode/setMode functions should be

Jeez, can you tell I never used pyrex before?

This time the patch actually builds, and appears to work.

Ethan

Re: [Pyode-user] FixedJoint missing setParam?

[Ethan Glasser-C. <gl...@cs...>]

Hart's Antler wrote:
> i think the FixedJoint is missing setParameter for doing custom cfm and=
 erp.  also i've noticed
> that at least for some joint types, getfeedback works, but setfeedback =
does not.  anybody else
> having the same problems?
> -brett

Hi,

I don't see any dJointGetFixedParam/dJointSetFixedParam functions in
ODE 0.7. Likewise, I don't see any place for the parameters in the
dxFixedJoint structure. So, the functions are missing upstream.

Ethan

[Pyode-user] FixedJoint missing setParam?

[Hart's A. <bha...@ya...>]

i think the FixedJoint is missing setParameter for doing custom cfm and erp.  also i've noticed
that at least for some joint types, getfeedback works, but setfeedback does not.  anybody else
having the same problems?
-brett



 
____________________________________________________________________________________
Cheap Talk? Check out Yahoo! Messenger's low PC-to-Phone call rates 
(http://voice.yahoo.com)

Re: [Pyode-user] PATCH: LMotor

[Ethan Glasser-C. <gl...@cs...>]

Yikes, looks like I goofed. The getMode/setMode functions should be
removed; they don't have any equivalent for LMotors. Also, the 'rel'
argument is currently ignored in the LMotor class; a note should be
made of that in the docstring.

A new patch is attached that addresses these issues.

Sorry about that!

Ethan

[Pyode-user] PATCH: LMotor

[Ethan Glasser-C. <gl...@cs...>]

Adds support for the LMotor motor, which is in ODE 0.7. This motor
parallels the AMotor code, so I copied and search-replaced. Please apply.

Ethan

Re: [Pyode-user] Not-really-fixed joints

[Ethan Glasser-C. <gl...@cs...>]

Hart's Antler wrote:
> Hi Ethan,
>=20
> not sure if this will do what you want, but when i want to make an obje=
ct follow a point i use a
> magnet function, it won't be perfect, it will slip a little, try adjust=
ing the value of magnet
>=20
> target =3D vec3( x,y,z )
> magnet =3D 100
> v1 =3D vec3( body.getPosition() )
> v2 =3D target-v1
> body.addForce( v2.normalize()*magnet )

This is a useful stopgap, thanks.

I see that the ODE manual says:

"How can an immovable body be created?

In other words, how can you create a body that doesn't move, but that
interacts with other bodies? The answer is to create a geom only,
without the corresponding rigid body object. The geom is associated
with a rigid body ID of zero. Then in the contact callback when you
detect a collision between two geoms with a nonzero body ID and a zero
body ID, you can simply pass those two IDs to the dJointAttach
function as normal. This will create a contact between the rigid body
and the static environment.

Don't try to get the same effect by setting a very high mass/inertia
on the "motionless" body and then resetting it's position/orientation
on each time step. This can cause unexpected simulation errors."

I guess what I'm doing is much like that, resetting its position every
time step, and I'm not surprised that it causes errors. But what I'd
like, ideally, to do, is, well, make an immovable body that moves. :)
This is what I called "static" in my original email. The above recipe
works fine until you add joints; once that happens, the static
object's velocity can be altered, which isn't what I want.

Maybe the best solution is to make a new kind of joint. I'll look into
this possibility next.

Ethan

Re: [Pyode-user] Not-really-fixed joints

[Hart's A. <bha...@ya...>]

Hi Ethan,

not sure if this will do what you want, but when i want to make an object follow a point i use a
magnet function, it won't be perfect, it will slip a little, try adjusting the value of magnet

target = vec3( x,y,z )
magnet = 100
v1 = vec3( body.getPosition() )
v2 = target-v1
body.addForce( v2.normalize()*magnet )

-brett


--- Ethan Glasser-Camp <gl...@cs...> wrote:

> Hi,
> 
> In a project I'm working on, there are objects which are "static",
> which means they affect objects without objects affecting them back.
> So an object can be joined using a joints to a "static" object, and
> the static object will pull the other object along without changing
> velocity.
> 
> I've been having a hard time figuring out how to simulate those
> objects. Enclosed is my current approach. Body2 is joined, via body1,
> to a static object which isn't actually in the simulation -- let's
> call it "body0". Body0 moves in the negative y direction at 50 units
> per second, so body1's position is forced to match body0 every tick.
> After about 40 ticks, this causes my simulation to freak out and move
> objects to (nan, nan, nan).
> 
> Is there a better approach to simulate this kind of thing? If not, how
> can I work around this behavior? I've tried playing with CFM and ERP
> parameters, both global and of the joints, but haven't found anything
> useful.
> 
> Ethan
> > import ode
> import math
> 
> world = ode.World()
> world.setCFM(1e-8)
> 
> # Create two bodies
> body1 = ode.Body(world)
> body1.setPosition((0,0,0))
> j0 = ode.HingeJoint(world)
> j0.attach(ode.environment, body1)
> j0.setAxis((0, 0, 1))
> j0.setAnchor((0, 0, 0))
> 
> body2 = ode.Body(world)
> body2.setPosition((200, 0, 0))
> M = ode.Mass()
> M.setSphere(2500, 0.05)
> body2.setMass(M)
> 
> j1 = ode.SliderJoint(world)
> j1.attach(body1, body2)
> j1.setAxis((200, 0, 0))
> j1.setParam(ode.ParamLoStop, 0)
> j1.setParam(ode.ParamHiStop, 4)
> 
> # Simulation loop...
> 
> fps = 50
> dt = 1.0/fps
> loops = 0
> 
> while loops < 50:
>     loops += 1
>     print body1.getPosition(), body2.getPosition(), j1.getPosition(), j1.getPositionRate()
> 
>     def down(pos):
>         return pos[0], pos[1]-1, pos[2]
>     move = down
> 
>     body1.setPosition(move(body1.getPosition()))
>     j0.setAnchor(move(j0.getAnchor()))
>     #body2.setLinearVel((1, 0, 0))
> 
>     # Next simulation step
>     world.step(dt)
> 
> print j0.getAnchor(), body1.getPosition(), body2.getPosition(), j1.getAxis()
> > -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642>
_______________________________________________
> Pyode-user mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyode-user
> 



 
____________________________________________________________________________________
Get your email and see which of your friends are online - Right on the New Yahoo.com 
(http://www.yahoo.com/preview) 

[Pyode-user] Not-really-fixed joints

[Ethan Glasser-C. <gl...@cs...>]

Hi,

In a project I'm working on, there are objects which are "static",
which means they affect objects without objects affecting them back.
So an object can be joined using a joints to a "static" object, and
the static object will pull the other object along without changing
velocity.

I've been having a hard time figuring out how to simulate those
objects. Enclosed is my current approach. Body2 is joined, via body1,
to a static object which isn't actually in the simulation -- let's
call it "body0". Body0 moves in the negative y direction at 50 units
per second, so body1's position is forced to match body0 every tick.
After about 40 ticks, this causes my simulation to freak out and move
objects to (nan, nan, nan).

Is there a better approach to simulate this kind of thing? If not, how
can I work around this behavior? I've tried playing with CFM and ERP
parameters, both global and of the joints, but haven't found anything
useful.

Ethan

Re: [Pyode-user] QuadSpace Tree Arguments

[Hart's A. <bha...@ya...>]

Bryan,

center = (0,0,0)
boundry = (30,30,30)
depth = 4
space = ode.QuadTreeSpace( center, boundry, depth )

Try this, set center and boundry to fit your scene.  note if your depth is too high python will
crash.

-brett

--- Bryan Rosander <bdr...@ya...> wrote:

> I was trying to use QuadSpaceTree in a small project, and it said it needed 3 arguments.  I
> couldn't find what arguments to pass it in the documentation however, or any examples.  Could
> someone help me out?
> Bryan
> 
> 
> 
> 
> 
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Pyode-user mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyode-user
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[Pyode-user] QuadSpace Tree Arguments

[Bryan R. <bdr...@ya...>]

I was trying to use QuadSpaceTree in a small project, and it said it needed=
 3 arguments.  I couldn't find what arguments to pass it in the documentati=
on however, or any examples.  Could someone help me out?=0ABryan=0A=0A=0A=
=0A