pyode-user

[Pyode-user] Kinematic state patch

[<al...@ci...>]

Hello,

I have patched PyODE by adding the following functions, which set the kinematic
state of a rigid body:

body.setKinematic()
body.setDynamic()
body.isKinematic()

The functions are described here:
http://opende.sourceforge.net/wiki/index.php/Manual_%28Rigid_Body_Functions
%29#Kinematic_State

I have also attached the same patch to the project tracker a few days ago
(at https://sourceforge.net/tracker/?group_id=73553&atid=538152 ),
but I'm not sure whether anyone noticed it.

Regards,
Alex Dumitrache

Re: [Pyode-user] Kinematic state patch

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

al...@ci... wrote:
> Hello,
> 
> I have patched PyODE by adding the following functions, which set the kinematic
> state of a rigid body:
> 
> body.setKinematic()
> body.setDynamic()
> body.isKinematic()
> 
> The functions are described here:
> http://opende.sourceforge.net/wiki/index.php/Manual_%28Rigid_Body_Functions
> %29#Kinematic_State

This is very cool. I've reviewed the patch. Some suggestions, if I may:

1. Don't send patches with trailing whitespace.
2. Send patches that apply from the root of the project (i.e. do cvs
diff from outside of src).

I'd also suggest changing the API to setKinematic(True/False), or
setDynamism(DEFAULT/DYNAMIC/KINEMATIC), but I guess it is useful to have
similar APIs to ODE.

I've cleaned up the whitespace and rewritten one of the docstrings for
clarity, and committed the resulting patch. Thanks.

> I have also attached the same patch to the project tracker a few days ago
> (at https://sourceforge.net/tracker/?group_id=73553&atid=538152 ),
> but I'm not sure whether anyone noticed it.

As you guessed, I don't check the project tracker and I doubt anyone
else does either :)

Ethan

Re: [Pyode-user] Kinematic state patch

[<al...@ci...>]

Hello Ethan,

Thank you very much for the review and the comments.

Since this is my first patch submitted to an open source project, I expected to
received some critics.
Next time I will try to read the manual more thoroughly.


You are correct with suggesting setKinematic(True/False), it's more intuitive.
To keep the API
similar to ODE, and also take into account your suggestion, I'm thinking at
something like this:

body.setKinematic(kinematic = True)
body.setDynamic()
body.isKinematic() => True/False

Therefore, setKinematic(False) will be identical to setDynamic().

The default dynamic state is "Dynamic", and currently there are only two
possible values: kinematic and dynamic.

P.S. I am glad you switched to git. It would be a good idea to add the git link
to Pyode web site
( http://pyode.sourceforge.net )

Regards,
Alex

> al...@ci... wrote:
>> Hello,
>>
>> I have patched PyODE by adding the following functions, which set the
>> kinematic
>> state of a rigid body:
>>
>> body.setKinematic()
>> body.setDynamic()
>> body.isKinematic()
>>
>> The functions are described here:
>> http://opende.sourceforge.net/wiki/index.php/Manual_%28Rigid_Body_Functions
>> %29#Kinematic_State
>
> This is very cool. I've reviewed the patch. Some suggestions, if I may:
>
> 1. Don't send patches with trailing whitespace.
> 2. Send patches that apply from the root of the project (i.e. do cvs
> diff from outside of src).
>
> I'd also suggest changing the API to setKinematic(True/False), or
> setDynamism(DEFAULT/DYNAMIC/KINEMATIC), but I guess it is useful to have
> similar APIs to ODE.
>
> I've cleaned up the whitespace and rewritten one of the docstrings for
> clarity, and committed the resulting patch. Thanks.
>
>> I have also attached the same patch to the project tracker a few days ago
>> (at https://sourceforge.net/tracker/?group_id=73553&atid=538152 ),
>> but I'm not sure whether anyone noticed it.
>
> As you guessed, I don't check the project tracker and I doubt anyone
> else does either :)
>
> Ethan
>

[Pyode-user] Pyode binary distribution

[<al...@ci...>]

Hello,

I have tried to create a binary Win32 installer for latest PyODE snapshot.
I am sure Kadir and others will find it useful.

Since the distribution is not very small (about 1 MB), I did not attached it;
instead, you may download it from:

http://dl.dropbox.com/u/4124919/pyode-win32.zip

The zip archive contains two files, for Python 2.5 and 2.6:

PyODE-snapshot-2010-03-22.win32-py2.5.exe
PyODE-snapshot-2010-03-22.win32-py2.6.exe

The binary distribution was created from today's snapshot from git repository.

The ODE DLL is compiled from SVN, from March 15 2010. This version worked for me
much better than 0.11.1 (it was more stable and also faster).

ODE was compiled with double precision, release, using mingw.

Since I'm a beginner in creating Python packages, I have two small issues:

1. The installer copies "ode.dll" to c:\python25. Is this a problem?
I believe it should be copied into "site-packages" instead, but I did not know
how to
specify this in setup.py.

2. The examples are copied into c:\python25\pyode-examples. Is there a better
choice?

3. When installing the binary package to a fresh Python directory, tutorials 1
and 3
work fine; the others need pygame and maybe cgkit. Is there a way to specify
these dependencies in the binary installer?

I have added examples and ode.dll as "data_files" in setup.py. I would also like to
see the setup.py which created the releases from pyode.sourceforge.net (1.2.0).

Regards,
Alex

> Does the latest version of PyODE work with Python 2.6?
>
> Thanks.
>
> Kadir
>
> 2010/3/18 <al...@ci...>
>
>> Hello,
>>
>> I have patched PyODE by adding the following functions, which set the
>> kinematic
>> state of a rigid body:
>>
>> body.setKinematic()
>> body.setDynamic()
>> body.isKinematic()
>>
>> The functions are described here:
>> http://opende.sourceforge.net/wiki/index.php/Manual_%28Rigid_Body_Functions
>> %29#Kinematic_State<http://opende.sourceforge.net/wiki/index.php/Manual_%28Rigid_Body_Functions%0A%29#Kinematic_State>
>>
>> I have also attached the same patch to the project tracker a few days ago
>> (at https://sourceforge.net/tracker/?group_id=73553&atid=538152 ),
>> but I'm not sure whether anyone noticed it.
>>
>> Regards,
>> Alex Dumitrache
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Pyode-user mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyode-user
>>
>>
>

Re: [Pyode-user] Pyode binary distribution

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

al...@ci... wrote:
> I have tried to create a binary Win32 installer for latest PyODE snapshot.
> I am sure Kadir and others will find it useful.

This is awesome, thanks!

I have uploaded this, as well as tarballs taken from today's git, to the
files section of the sourceforge project:

https://sourceforge.net/projects/pyode/files/

I've elected to use a snapshot-ymd system, since at present the project
doesn't have "features" that are added in any regular fashion.

I also updated the project website with the git URL and links to the
most current files.

> Since I'm a beginner in creating Python packages, I have two small issues:
> 
> 1. The installer copies "ode.dll" to c:\python25. Is this a problem?
> I believe it should be copied into "site-packages" instead, but I did not know
> how to
> specify this in setup.py.

No idea here, sorry..

> 2. The examples are copied into c:\python25\pyode-examples. Is there a better
> choice?

I wouldn't include them at all, frankly.

> 3. When installing the binary package to a fresh Python directory, tutorials 1
> and 3
> work fine; the others need pygame and maybe cgkit. Is there a way to specify
> these dependencies in the binary installer?

I think it's fine to leave these out -- not all people who use ODE are
going to want to use it with Pygame.

> I have added examples and ode.dll as "data_files" in setup.py. I would also like to
> see the setup.py which created the releases from pyode.sourceforge.net (1.2.0).

I would guess that the setup.py in the source tree is the one they used,
but I have no idea.

Ethan

Re: [Pyode-user] Pyode binary distribution

[Kadir H. <kha...@gm...>]

Hi again,

I have installed Python 2.6.4 and tried to install PyODE on top. I have
downloaded the PyODE-snapshot-2010-03-22.win32-py2.6.exe<http://sourceforge.net/projects/pyode/files/pyode/snapshot-2010-03-22/PyODE-snapshot-2010-03-22.win32-py2.6.exe/download>from
the sourceforge and somehow got it working :))

But now funny things are happening. It looks like the GeomPlane is not
functioning correctly, so that everything falls down forever. My "floor" has
gone. The same exact code works OK in Python25, in 2.6, the rest seems OK
for the moment (At least gravity is there, joints are working, bodies are
working OK), but the floor is gone!?

Is it a collision detection problem, although for the remaining parts it
seems to work ok. Bodies are mostly CappedCylinders (plus some spheres).

>From Idle, I can see ode.GeomPlane is in there, but somehow it is not
working OK.

I will check with some other programs, or simple geometries.

Thnaks for your work and support.

Kadir

2010/3/23 Ethan Glasser-Camp <gl...@cs...>

> al...@ci... wrote:
> > I have tried to create a binary Win32 installer for latest PyODE
> snapshot.
> > I am sure Kadir and others will find it useful.
>
> This is awesome, thanks!
>
> I have uploaded this, as well as tarballs taken from today's git, to the
> files section of the sourceforge project:
>
> https://sourceforge.net/projects/pyode/files/
>
> I've elected to use a snapshot-ymd system, since at present the project
> doesn't have "features" that are added in any regular fashion.
>
> I also updated the project website with the git URL and links to the
> most current files.
>
> > Since I'm a beginner in creating Python packages, I have two small
> issues:
> >
> > 1. The installer copies "ode.dll" to c:\python25. Is this a problem?
> > I believe it should be copied into "site-packages" instead, but I did not
> know
> > how to
> > specify this in setup.py.
>
> No idea here, sorry..
>
> > 2. The examples are copied into c:\python25\pyode-examples. Is there a
> better
> > choice?
>
> I wouldn't include them at all, frankly.
>
> > 3. When installing the binary package to a fresh Python directory,
> tutorials 1
> > and 3
> > work fine; the others need pygame and maybe cgkit. Is there a way to
> specify
> > these dependencies in the binary installer?
>
> I think it's fine to leave these out -- not all people who use ODE are
> going to want to use it with Pygame.
>
> > I have added examples and ode.dll as "data_files" in setup.py. I would
> also like to
> > see the setup.py which created the releases from pyode.sourceforge.net(1.2.0).
>
> I would guess that the setup.py in the source tree is the one they used,
> but I have no idea.
>
> Ethan
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Pyode-user mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyode-user
>

Re: [Pyode-user] Pyode binary distribution

[<al...@ci...>]

Hello,

First thing you should check:
Do the examples from C:\Python26\pyode-examples run correctly?

tutorial3.py has an example with a GeomPlane some falling boxes and spheres.
Does it run correctly?

I have just tested it with a fresh install of Python 2.6, PyOpenGL 3.0.1 and
PyODE-snapshot-2010-03-22.win32-py2.6.exe.
It worked from the first try.

Which version of ODE do you use on Python 2.5? It seems that different ODE
versions behave slightly differently
with the same scene description.

Do you use PyODE directly from your program or do you have some higher level
library, like cgkit?
In the second case, please check that it uses the same stepping method (step or
quickStep) in both Py25 and 26.

Can you send me a small test program, with the floor and one body, which works
in Py25 and not in 26?

I am also using PyODE in a simulation which involves bodies sitting, and
sometimes falling, on the ground.
When the gravity, body mass or vertical speed were too high, they could break
the floor and fall down.
So you may start debugging with reducing the gravity value.

However, the simulation runs exactly the same in Py25 and 26, with exactly the
same code. I do not use
PyODE directly, but all the rendering and simulation is done using cgkit. I'm
using boxes and trimeshes,
and sometimes spheres for debugging.

The program in which I use PyODE is a robot arm simulator, still in early stages
of development, available here:
http://github.com/alexdu/robot-sandbox . For now, it only runs on Windows out of
the box (unzip and run).

> Hi again,
>
> I have installed Python 2.6.4 and tried to install PyODE on top. I have
> downloaded the
> PyODE-snapshot-2010-03-22.win32-py2.6.exe<http://sourceforge.net/projects/pyode/files/pyode/snapshot-2010-03-22/PyODE-snapshot-2010-03-22.win32-py2.6.exe/download>from
> the sourceforge and somehow got it working :))
>
> But now funny things are happening. It looks like the GeomPlane is not
> functioning correctly, so that everything falls down forever. My "floor" has
> gone. The same exact code works OK in Python25, in 2.6, the rest seems OK
> for the moment (At least gravity is there, joints are working, bodies are
> working OK), but the floor is gone!?
>
> Is it a collision detection problem, although for the remaining parts it
> seems to work ok. Bodies are mostly CappedCylinders (plus some spheres).
>
>>From Idle, I can see ode.GeomPlane is in there, but somehow it is not
> working OK.
>
> I will check with some other programs, or simple geometries.
>
> Thnaks for your work and support.
>
> Kadir
>
> 2010/3/23 Ethan Glasser-Camp <gl...@cs...>
>
>> al...@ci... wrote:
>> > I have tried to create a binary Win32 installer for latest PyODE
>> snapshot.
>> > I am sure Kadir and others will find it useful.
>>
>> This is awesome, thanks!
>>
>> I have uploaded this, as well as tarballs taken from today's git, to the
>> files section of the sourceforge project:
>>
>> https://sourceforge.net/projects/pyode/files/
>>
>> I've elected to use a snapshot-ymd system, since at present the project
>> doesn't have "features" that are added in any regular fashion.
>>
>> I also updated the project website with the git URL and links to the
>> most current files.
>>
>> > Since I'm a beginner in creating Python packages, I have two small
>> issues:
>> >
>> > 1. The installer copies "ode.dll" to c:\python25. Is this a problem?
>> > I believe it should be copied into "site-packages" instead, but I did not
>> know
>> > how to
>> > specify this in setup.py.
>>
>> No idea here, sorry..
>>
>> > 2. The examples are copied into c:\python25\pyode-examples. Is there a
>> better
>> > choice?
>>
>> I wouldn't include them at all, frankly.
>>
>> > 3. When installing the binary package to a fresh Python directory,
>> tutorials 1
>> > and 3
>> > work fine; the others need pygame and maybe cgkit. Is there a way to
>> specify
>> > these dependencies in the binary installer?
>>
>> I think it's fine to leave these out -- not all people who use ODE are
>> going to want to use it with Pygame.
>>
>> > I have added examples and ode.dll as "data_files" in setup.py. I would
>> also like to
>> > see the setup.py which created the releases from
>> pyode.sourceforge.net(1.2.0).
>>
>> I would guess that the setup.py in the source tree is the one they used,
>> but I have no idea.
>>
>> Ethan
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Pyode-user mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyode-user
>>
>

Re: [Pyode-user] Pyode binary distribution

[<al...@ci...>]

Hello,

I found the problem, see the attached file.

Somewhere in the code, there is a line:

# create a list to store any ODE bodies which are not part of the ragdoll (this

# is needed to avoid Python garbage collecting these bodies)

bodies = []


A similar code snippet is needed for geoms, too. That's why I added the following:
geoms = []


And after creating every geom, I have added it to that list. That solved the
problem.

"bodies" and "geoms" are not used anywhere in the code. They just say to
Python's garbage collector: I'm using these objects, do not delete them.

When there are no more references to a body or a geom, PyODE removes those objects
from ODE simulation automatically. That happened into your code: bodies were still
present in simulation (that's why the doll was falling), but all the geoms
(floors and capsules) were deleted.

Is the ragdoll example the one from
http://monsterden.net/software/ragdoll-pyode-tutorial ?
I think it would be nice to include it in the PyODE examples folder.

Alex

> Hello Alex,
>
> Thanks for your note and recommendations. I have answed them one by one,
> next to your questions:
>
> Kadir
>
> 2010/3/27 <al...@ci...>
>
>> Hello,
>>
>> First thing you should check:
>> Do the examples from C:\Python26\pyode-examples run correctly?
>>
>> >>> Tutorial 1 runs OK, with the same numerical output
>>>> Tutorial 2 runs OK with same double pendulum swinging
>>>> Tutorial 3 runs with the same problem I had with new installation of
> PyODE. Boxes falling down, penetrating the floor (plane).
>
>
>> tutorial3.py has an example with a GeomPlane some falling boxes and
>> spheres.
>> Does it run correctly?
>>
>
>>>> Tutorial 3 runs with the same problem I had with new installation of
> PyODE. Boxes falling down, penetrating the floor (plane).
>
>
>> I have just tested it with a fresh install of Python 2.6, PyOpenGL 3.0.1
>> and
>> PyODE-snapshot-2010-03-22.win32-py2.6.exe.
>> It worked from the first try.
>>
>> Which version of ODE do you use on Python 2.5? It seems that different ODE
>> versions behave slightly differently
>> with the same scene description.
>>
>> >>>> I believe PyODE 1.2.0, which was installed using
> PyODE-1.2.0.win32-py2.5.exe.
>
>
>> Do you use PyODE directly from your program or do you have some higher
>> level
>> library, like cgkit?
>> In the second case, please check that it uses the same stepping method
>> (step or
>> quickStep) in both Py25 and 26.
>>
>> >>>> I use it directly. I use Vpython for visualisation.
>
>
>> Can you send me a small test program, with the floor and one body, which
>> works
>> in Py25 and not in 26?
>>
>
>>>>> I am attaching one famous RagDoll I have been using with PyODE. It is
> supposed to fall and lie down on the floor.
> Although I know nothing about robotics, I am trying to get this RagDoll up
> and walking.
>
> I have visited your robot site.  I have downloaded the windows version of
> your robot and ran it on my laptop. I liked it very much. I tried to
> implement a similar kinematic robot arm earlier, I had some coordination
> problems, then I was planning to migrate it to ODE as a dynamic arm. I use
> VPython for visualization, not OpenGL since VPython is very easy to use.
>
>>
>> I am also using PyODE in a simulation which involves bodies sitting, and
>> sometimes falling, on the ground.
>> When the gravity, body mass or vertical speed were too high, they could
>> break
>> the floor and fall down.
>> So you may start debugging with reducing the gravity value.
>>
>> >>> I set g = -0.81, same behaviour, slow-motion.
>
> It looks like a collision detection problem but where? Any double Precision
> / SÝngle Precision issue?
>
>
>> However, the simulation runs exactly the same in Py25 and 26, with exactly
>> the
>> same code. I do not use
>> PyODE directly, but all the rendering and simulation is done using cgkit.
>> I'm
>> using boxes and trimeshes,
>> and sometimes spheres for debugging.
>>
>> The program in which I use PyODE is a robot arm simulator, still in early
>> stages
>> of development, available here:
>> http://github.com/alexdu/robot-sandbox . For now, it only runs on Windows
>> out of
>> the box (unzip and run).
>>
>> > Hi again,
>> >
>> > I have installed Python 2.6.4 and tried to install PyODE on top. I have
>> > downloaded the
>> > PyODE-snapshot-2010-03-22.win32-py2.6.exe<
>> http://sourceforge.net/projects/pyode/files/pyode/snapshot-2010-03-22/PyODE-snapshot-2010-03-22.win32-py2.6.exe/download
>> >from
>> > the sourceforge and somehow got it working :))
>> >
>> > But now funny things are happening. It looks like the GeomPlane is not
>> > functioning correctly, so that everything falls down forever. My "floor"
>> has
>> > gone. The same exact code works OK in Python25, in 2.6, the rest seems OK
>> > for the moment (At least gravity is there, joints are working, bodies are
>> > working OK), but the floor is gone!?
>> >
>> > Is it a collision detection problem, although for the remaining parts it
>> > seems to work ok. Bodies are mostly CappedCylinders (plus some spheres).
>> >
>> >>From Idle, I can see ode.GeomPlane is in there, but somehow it is not
>> > working OK.
>> >
>> > I will check with some other programs, or simple geometries.
>> >
>> > Thnaks for your work and support.
>> >
>> > Kadir
>> >
>> > 2010/3/23 Ethan Glasser-Camp <gl...@cs...>
>> >
>> >> al...@ci... wrote:
>> >> > I have tried to create a binary Win32 installer for latest PyODE
>> >> snapshot.
>> >> > I am sure Kadir and others will find it useful.
>> >>
>> >> This is awesome, thanks!
>> >>
>> >> I have uploaded this, as well as tarballs taken from today's git, to the
>> >> files section of the sourceforge project:
>> >>
>> >> https://sourceforge.net/projects/pyode/files/
>> >>
>> >> I've elected to use a snapshot-ymd system, since at present the project
>> >> doesn't have "features" that are added in any regular fashion.
>> >>
>> >> I also updated the project website with the git URL and links to the
>> >> most current files.
>> >>
>> >> > Since I'm a beginner in creating Python packages, I have two small
>> >> issues:
>> >> >
>> >> > 1. The installer copies "ode.dll" to c:\python25. Is this a problem?
>> >> > I believe it should be copied into "site-packages" instead, but I did
>> not
>> >> know
>> >> > how to
>> >> > specify this in setup.py.
>> >>
>> >> No idea here, sorry..
>> >>
>> >> > 2. The examples are copied into c:\python25\pyode-examples. Is there a
>> >> better
>> >> > choice?
>> >>
>> >> I wouldn't include them at all, frankly.
>> >>
>> >> > 3. When installing the binary package to a fresh Python directory,
>> >> tutorials 1
>> >> > and 3
>> >> > work fine; the others need pygame and maybe cgkit. Is there a way to
>> >> specify
>> >> > these dependencies in the binary installer?
>> >>
>> >> I think it's fine to leave these out -- not all people who use ODE are
>> >> going to want to use it with Pygame.
>> >>
>> >> > I have added examples and ode.dll as "data_files" in setup.py. I would
>> >> also like to
>> >> > see the setup.py which created the releases from
>> >> pyode.sourceforge.net(1.2.0).
>> >>
>> >> I would guess that the setup.py in the source tree is the one they used,
>> >> but I have no idea.
>> >>
>> >> Ethan
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> Download Intel&#174; Parallel Studio Eval
>> >> Try the new software tools for yourself. Speed compiling, find bugs
>> >> proactively, and fine-tune applications for parallel performance.
>> >> See why Intel Parallel Studio got high marks during beta.
>> >> http://p.sf.net/sfu/intel-sw-dev
>> >> _______________________________________________
>> >> Pyode-user mailing list
>> >> Pyo...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/pyode-user
>> >>
>> >
>>
>>
>

Re: [Pyode-user] Pyode binary distribution

[<al...@ci...>]

Hello,

It's not enough to add geoms = []. Every time you create a new geom, you do:

geoms.append(geom)

In my Python 2.5, the ragdoll from your original code was falling through the
floor.
I guess the difference was in older versions of PyODE: they might not call
dGeomDestroy()
in the geom destructor, or the body object might have had some references to the
geoms.

Alex

> Thanks Alex.
>
> Yes the code you have sent is working fine. For some strange reason, when I
> added  geoms = [] on my original program, ragdoll continued falling. I will
> check what is going on. And of course my question would be, why and how was
> it working in Python2.5? What is the difference?
>
> Yes, the ragdoll is from monsterden.net. I think the original one is from
> Cornel.edu, bu tI can not remember the exact link now, and I am not sure if
> it is the same guy. Well, it is upto you to add it in the examples. It is an
> interesting one, and a bit more advanced than falling boxes.
>
> Kadir
>
> 2010/3/28 <al...@ci...>
>
>> Hello,
>>
>> I found the problem, see the attached file.
>>
>> Somewhere in the code, there is a line:
>>
>> # create a list to store any ODE bodies which are not part of the ragdoll
>> (this
>>
>> # is needed to avoid Python garbage collecting these bodies)
>>
>> bodies = []
>>
>>
>> A similar code snippet is needed for geoms, too. That's why I added the
>> following:
>> geoms = []
>>
>>
>> And after creating every geom, I have added it to that list. That solved
>> the
>> problem.
>>
>> "bodies" and "geoms" are not used anywhere in the code. They just say to
>> Python's garbage collector: I'm using these objects, do not delete them.
>>
>> When there are no more references to a body or a geom, PyODE removes those
>> objects
>> from ODE simulation automatically. That happened into your code: bodies
>> were still
>> present in simulation (that's why the doll was falling), but all the geoms
>> (floors and capsules) were deleted.
>>
>> Is the ragdoll example the one from
>> http://monsterden.net/software/ragdoll-pyode-tutorial ?
>> I think it would be nice to include it in the PyODE examples folder.
>>
>> Alex
>>
>> > Hello Alex,
>> >
>> > Thanks for your note and recommendations. I have answed them one by one,
>> > next to your questions:
>> >
>> > Kadir
>> >
>> > 2010/3/27 <al...@ci...>
>> >
>> >> Hello,
>> >>
>> >> First thing you should check:
>> >> Do the examples from C:\Python26\pyode-examples run correctly?
>> >>
>> >> >>> Tutorial 1 runs OK, with the same numerical output
>> >>>> Tutorial 2 runs OK with same double pendulum swinging
>> >>>> Tutorial 3 runs with the same problem I had with new installation of
>> > PyODE. Boxes falling down, penetrating the floor (plane).
>> >
>> >
>> >> tutorial3.py has an example with a GeomPlane some falling boxes and
>> >> spheres.
>> >> Does it run correctly?
>> >>
>> >
>> >>>> Tutorial 3 runs with the same problem I had with new installation of
>> > PyODE. Boxes falling down, penetrating the floor (plane).
>> >
>> >
>> >> I have just tested it with a fresh install of Python 2.6, PyOpenGL 3.0.1
>> >> and
>> >> PyODE-snapshot-2010-03-22.win32-py2.6.exe.
>> >> It worked from the first try.
>> >>
>> >> Which version of ODE do you use on Python 2.5? It seems that different
>> ODE
>> >> versions behave slightly differently
>> >> with the same scene description.
>> >>
>> >> >>>> I believe PyODE 1.2.0, which was installed using
>> > PyODE-1.2.0.win32-py2.5.exe.
>> >
>> >
>> >> Do you use PyODE directly from your program or do you have some higher
>> >> level
>> >> library, like cgkit?
>> >> In the second case, please check that it uses the same stepping method
>> >> (step or
>> >> quickStep) in both Py25 and 26.
>> >>
>> >> >>>> I use it directly. I use Vpython for visualisation.
>> >
>> >
>> >> Can you send me a small test program, with the floor and one body, which
>> >> works
>> >> in Py25 and not in 26?
>> >>
>> >
>> >>>>> I am attaching one famous RagDoll I have been using with PyODE. It is
>> > supposed to fall and lie down on the floor.
>> > Although I know nothing about robotics, I am trying to get this RagDoll
>> up
>> > and walking.
>> >
>> > I have visited your robot site.  I have downloaded the windows version of
>> > your robot and ran it on my laptop. I liked it very much. I tried to
>> > implement a similar kinematic robot arm earlier, I had some coordination
>> > problems, then I was planning to migrate it to ODE as a dynamic arm. I
>> use
>> > VPython for visualization, not OpenGL since VPython is very easy to use.
>> >
>> >>
>> >> I am also using PyODE in a simulation which involves bodies sitting, and
>> >> sometimes falling, on the ground.
>> >> When the gravity, body mass or vertical speed were too high, they could
>> >> break
>> >> the floor and fall down.
>> >> So you may start debugging with reducing the gravity value.
>> >>
>> >> >>> I set g = -0.81, same behaviour, slow-motion.
>> >
>> > It looks like a collision detection problem but where? Any double
>> Precision
>> > / SÝngle Precision issue?
>> >
>> >
>> >> However, the simulation runs exactly the same in Py25 and 26, with
>> exactly
>> >> the
>> >> same code. I do not use
>> >> PyODE directly, but all the rendering and simulation is done using
>> cgkit.
>> >> I'm
>> >> using boxes and trimeshes,
>> >> and sometimes spheres for debugging.
>> >>
>> >> The program in which I use PyODE is a robot arm simulator, still in
>> early
>> >> stages
>> >> of development, available here:
>> >> http://github.com/alexdu/robot-sandbox . For now, it only runs on
>> Windows
>> >> out of
>> >> the box (unzip and run).
>> >>
>> >> > Hi again,
>> >> >
>> >> > I have installed Python 2.6.4 and tried to install PyODE on top. I
>> have
>> >> > downloaded the
>> >> > PyODE-snapshot-2010-03-22.win32-py2.6.exe<
>> >>
>> http://sourceforge.net/projects/pyode/files/pyode/snapshot-2010-03-22/PyODE-snapshot-2010-03-22.win32-py2.6.exe/download
>> >> >from
>> >> > the sourceforge and somehow got it working :))
>> >> >
>> >> > But now funny things are happening. It looks like the GeomPlane is not
>> >> > functioning correctly, so that everything falls down forever. My
>> "floor"
>> >> has
>> >> > gone. The same exact code works OK in Python25, in 2.6, the rest seems
>> OK
>> >> > for the moment (At least gravity is there, joints are working, bodies
>> are
>> >> > working OK), but the floor is gone!?
>> >> >
>> >> > Is it a collision detection problem, although for the remaining parts
>> it
>> >> > seems to work ok. Bodies are mostly CappedCylinders (plus some
>> spheres).
>> >> >
>> >> >>From Idle, I can see ode.GeomPlane is in there, but somehow it is not
>> >> > working OK.
>> >> >
>> >> > I will check with some other programs, or simple geometries.
>> >> >
>> >> > Thnaks for your work and support.
>> >> >
>> >> > Kadir
>> >> >
>> >> > 2010/3/23 Ethan Glasser-Camp <gl...@cs...>
>> >> >
>> >> >> al...@ci... wrote:
>> >> >> > I have tried to create a binary Win32 installer for latest PyODE
>> >> >> snapshot.
>> >> >> > I am sure Kadir and others will find it useful.
>> >> >>
>> >> >> This is awesome, thanks!
>> >> >>
>> >> >> I have uploaded this, as well as tarballs taken from today's git, to
>> the
>> >> >> files section of the sourceforge project:
>> >> >>
>> >> >> https://sourceforge.net/projects/pyode/files/
>> >> >>
>> >> >> I've elected to use a snapshot-ymd system, since at present the
>> project
>> >> >> doesn't have "features" that are added in any regular fashion.
>> >> >>
>> >> >> I also updated the project website with the git URL and links to the
>> >> >> most current files.
>> >> >>
>> >> >> > Since I'm a beginner in creating Python packages, I have two small
>> >> >> issues:
>> >> >> >
>> >> >> > 1. The installer copies "ode.dll" to c:\python25. Is this a
>> problem?
>> >> >> > I believe it should be copied into "site-packages" instead, but I
>> did
>> >> not
>> >> >> know
>> >> >> > how to
>> >> >> > specify this in setup.py.
>> >> >>
>> >> >> No idea here, sorry..
>> >> >>
>> >> >> > 2. The examples are copied into c:\python25\pyode-examples. Is
>> there a
>> >> >> better
>> >> >> > choice?
>> >> >>
>> >> >> I wouldn't include them at all, frankly.
>> >> >>
>> >> >> > 3. When installing the binary package to a fresh Python directory,
>> >> >> tutorials 1
>> >> >> > and 3
>> >> >> > work fine; the others need pygame and maybe cgkit. Is there a way
>> to
>> >> >> specify
>> >> >> > these dependencies in the binary installer?
>> >> >>
>> >> >> I think it's fine to leave these out -- not all people who use ODE
>> are
>> >> >> going to want to use it with Pygame.
>> >> >>
>> >> >> > I have added examples and ode.dll as "data_files" in setup.py. I
>> would
>> >> >> also like to
>> >> >> > see the setup.py which created the releases from
>> >> >> pyode.sourceforge.net(1.2.0).
>> >> >>
>> >> >> I would guess that the setup.py in the source tree is the one they
>> used,
>> >> >> but I have no idea.
>> >> >>
>> >> >> Ethan
>> >> >>
>> >> >>
>> >> >>
>> >>
>> ------------------------------------------------------------------------------
>> >> >> Download Intel&#174; Parallel Studio Eval
>> >> >> Try the new software tools for yourself. Speed compiling, find bugs
>> >> >> proactively, and fine-tune applications for parallel performance.
>> >> >> See why Intel Parallel Studio got high marks during beta.
>> >> >> http://p.sf.net/sfu/intel-sw-dev
>> >> >> _______________________________________________
>> >> >> Pyode-user mailing list
>> >> >> Pyo...@li...
>> >> >> https://lists.sourceforge.net/lists/listinfo/pyode-user
>> >> >>
>> >> >
>> >>
>> >>
>> >
>>
>

Re: [Pyode-user] Lots of missing functions added to PyODE

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

al...@ci... wrote:
> A summary of changes:
> 
> * World: damping functions, QuickStep over-relaxation tuning
> * Body: damping, auto-disable, setMovedCallback
> * Joints:
>   - enable/disable joints
>   - JointType... constants
>   - 3 new joint classes: Piston, PR and PU.

Hmm.. why did you move the enable/disable functions for bodies to the
bottom of the file, instead of adding the autodisable stuff where the
enable stuff was?

I think _bodyMovedCallbacks should be a weakdict, shouldn't it? Also,
would it make more sense to add a _body_c2py_lut lookup table like for
geoms in ode.py? In that case you'd only need to store the callbacks in
_bodyMovedCallbacks. Of course, if it's a weakdict, you'd need to handle
the case where the body goes out of scope.. presumably the moved
callback won't be called if the body ceases to exist, but I'm not sure ;)

Maybe Body.getData() and Body.setData() should raise NotImplementedError?

You add a lot of blank lines between sections of code! I find this
distracting. Also, you have lots and lots of trailing whitespace, which
I really hate.

Also, it seems a little silly for code this simple, but you could send
smaller patches, especially if you're rearranging method declarations.

> Many declarations were generated automatically with a small script: auto.py (it
> is attached).

I added this, it's pretty neat. Thanks.

> The following functions are still not implemented (I need some help here):
> 
> dJointID dBodyGetJoint (dBodyID, int index);  (should return a Joint instance)

I would add a _joint_c2py_lut, like with geoms. Ignore the comment, that
was before I fully understood why tutorial3 used to break :)

> dGeomID dBodyGetFirstGeom (dBodyID);
> dGeomID dBodyGetNextGeom (dGeomID);           (these two should be wrapped into
> an iterable or a geom list)

Hmm, if nobody gets to this before the weekend I'll see if I can add
something.

> Regards,
> Alex

How would you like to be credited it the changelog? Just your email address?

Ethan

Re: [Pyode-user] Lots of missing functions added to PyODE

[<al...@ci...>]

> al...@ci... wrote:
>> A summary of changes:
>>
>> * World: damping functions, QuickStep over-relaxation tuning
>> * Body: damping, auto-disable, setMovedCallback
>> * Joints:
>>   - enable/disable joints
>>   - JointType... constants
>>   - 3 new joint classes: Piston, PR and PU.
>
> Hmm.. why did you move the enable/disable functions for bodies to the
> bottom of the file, instead of adding the autodisable stuff where the
> enable stuff was?

Well... at first I wanted to keep (more or less) the same order as ODE wiki.

> I think _bodyMovedCallbacks should be a weakdict, shouldn't it? Also,
> would it make more sense to add a _body_c2py_lut lookup table like for
> geoms in ode.py? In that case you'd only need to store the callbacks in
> _bodyMovedCallbacks. Of course, if it's a weakdict, you'd need to handle
> the case where the body goes out of scope.. presumably the moved
> callback won't be called if the body ceases to exist, but I'm not sure ;)

You are right. I will learn how to use weakdicts :)

> Maybe Body.getData() and Body.setData() should raise NotImplementedError?

Yes, this is also a good idea.

> You add a lot of blank lines between sections of code! I find this
> distracting. Also, you have lots and lots of trailing whitespace, which
> I really hate.

Well.. my coding style includes lots of whitespace :)
Okay, now I found Document->Strip Trailing Spaces in Geany. I did not notice them.

> Also, it seems a little silly for code this simple, but you could send
> smaller patches, especially if you're rearranging method declarations.
>
>> Many declarations were generated automatically with a small script: auto.py
>> (it
>> is attached).
>
> I added this, it's pretty neat. Thanks.
>
>> The following functions are still not implemented (I need some help here):
>>
>> dJointID dBodyGetJoint (dBodyID, int index);  (should return a Joint instance)
>
> I would add a _joint_c2py_lut, like with geoms. Ignore the comment, that
> was before I fully understood why tutorial3 used to break :)
>
>> dGeomID dBodyGetFirstGeom (dBodyID);
>> dGeomID dBodyGetNextGeom (dGeomID);           (these two should be wrapped
>> into
>> an iterable or a geom list)
>
> Hmm, if nobody gets to this before the weekend I'll see if I can add
> something.
>
>> Regards,
>> Alex
>
> How would you like to be credited it the changelog? Just your email address?
>
> Ethan
>

You may credit me like this:

Alex Dumitrache <al...@ci...>


In ode.pyx there is a comment:

## This causes some kind of weird bug! Need to fix this.

import weakref

_geom_c2py_lut = weakref.WeakValueDictionary()


In my programs, sometimes the lut is not able to find the geom ID,
and Space.collide_callback() fails with a KeyError. When this happens,
some boxes pass through the floor and fall down to -infinity.
Using a normal dictionary seems to solve the problem.

Is this the weird bug?


I also tried to implement Set* and Get* methods as properties, they are more
elegant.

    body.mass = 1           instead of body.setMass(1)
    print body.position     instead of print body.getPosition()

However, in Body class (and maybe others), they conflict with __setattr__.

At first, I have tried to override __setattr__, but I wasn't able to call the
default implementation (that's because Body is a "cdef class").

Then, I tried to remove __getattr__ and __setattr__ and instead use
something like this:

a) Add custom data as properties to a dedicated field ("data"):


    # Set custom data

    body.data.mycounter = 5

    body.data.mystring = "test"



    # Access custom data

    print body.data.mystring, body.data.mycounter



b) Supply a custom data object:



   # Set custom data

   body.data = myCustomData


   # Access custom data

   print body.data



Therefore, we have two possibilities to solve the conflict:

A) Overriding __setattr__:

   Pros: - compatible with existing code

   Cons: - may be slow (overriding __getattr__ and __setattr__ slows down the
access to class items)
         - you are not warned at all if you misspell the name of a property
          (e.g. you use body.pos = (1,2,3) but the correct name is
'body.position'; however, python will not complain at all)

B) Custom data field:
   Pros: - more lightweight
         - works fine, with no conflicts
         - if you misspell the name of a property, you will receive an error

   Cons: - breaks existing code which uses custom data

Which one should we choose? I prefer B) since it already works on my computer.

I have also implemented a mechanism for accessing joint parameters as properties.
It works like this:

j = ode.HingeJoint(world)
j.param.lo_stop = 0
j.param.cfm = 1e-5
j.param.vel = 0.1

For complex joints:
joint.param[1].fmax = 1
joint.param[2].fmax = 2
joint.param[3].fmax = 3

And for Plane2D:
joint.paramX.cfm = 1e-5
joint.paramY.cfm = 1e-10
joint.paramAngle.cfm = 1e-10

Or:
joint.param['X'].cfm = 1e-5
joint.param['Y'].cfm = 1e-10
joint.param['Angle'].cfm = 1e-5

And of course, the joint parameters are visible at TAB completion.

The old method, with setParam and getParam, still works as before.

The implementation uses descriptors, and all the functions are in the Joint base
class.
I will do some profiling to see if this does not slowdown the creation of
contact joints
in collision handler (because right now, they are a bottleneck in my robot
simulation).

I'm not sending the patch right now, since the code needs a bit of cleanup.

Alex

Re: [Pyode-user] Lots of missing functions added to PyODE

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

al...@ci... wrote:
> In ode.pyx there is a comment:
> 
> ## This causes some kind of weird bug! Need to fix this.
> 
> import weakref
> 
> _geom_c2py_lut = weakref.WeakValueDictionary()
> 
> In my programs, sometimes the lut is not able to find the geom ID,
> and Space.collide_callback() fails with a KeyError. When this happens,
> some boxes pass through the floor and fall down to -infinity.
> Using a normal dictionary seems to solve the problem.
> 
> Is this the weird bug?

It sounds related but this isn't exactly the bug I was confused about
when I wrote that comment. The bug is that if you create Geoms but don't
save references to them, (like the "geoms" list in tutorial 3) then the
geoms get garbage collected and they therefore don't have any collisions.

Your bug sounds related, because it seems like geoms are getting garbage
collected, but if that's true, then they should be getting destroyed
with dGeomDestroy() and so not causing collisions.

> Therefore, we have two possibilities to solve the conflict:
> 
> A) Overriding __setattr__:
> 
>    Pros: - compatible with existing code
> 
>    Cons: - may be slow (overriding __getattr__ and __setattr__ slows down the
> access to class items)
>          - you are not warned at all if you misspell the name of a property
>           (e.g. you use body.pos = (1,2,3) but the correct name is
> 'body.position'; however, python will not complain at all)
> 
> B) Custom data field:
>    Pros: - more lightweight
>          - works fine, with no conflicts
>          - if you misspell the name of a property, you will receive an error
> 
>    Cons: - breaks existing code which uses custom data

I like B better. It would be really great if we could offer a setting
that would enable backwards-compatible behavior, though :)

> Which one should we choose? I prefer B) since it already works on my computer.
> 
> I have also implemented a mechanism for accessing joint parameters as properties.
> It works like this:
> 
> j = ode.HingeJoint(world)
> j.param.lo_stop = 0
> j.param.cfm = 1e-5
> j.param.vel = 0.1
> 
> For complex joints:
> joint.param[1].fmax = 1
> joint.param[2].fmax = 2
> joint.param[3].fmax = 3
> 
> And for Plane2D:
> joint.paramX.cfm = 1e-5
> joint.paramY.cfm = 1e-10
> joint.paramAngle.cfm = 1e-10
> 
> Or:
> joint.param['X'].cfm = 1e-5
> joint.param['Y'].cfm = 1e-10
> joint.param['Angle'].cfm = 1e-5
> 
> And of course, the joint parameters are visible at TAB completion.

Sounds like a good idea to me.

Ethan

Re: [Pyode-user] PyODE joint properties accessible as parameters

[<al...@ci...>]

Since the patch file is too large, I have compressed it in order to reach the
mailing list.

> Hello,
>
> Here is the patch for accessing joint parameters as properties.
>
> Examples:
>
> j = ode.HingeJoint(world)
> j.param.lo_stop = 0
> j.param.cfm = 1e-5
> j.param.vel = 0.1
>
> For complex joints:
> joint.param[1].fmax = 1
> joint.param[2].fmax = 2
> joint.param[3].fmax = 3
>
> And for Plane2D:
> joint.paramX.cfm = 1e-5
> joint.paramY.cfm = 1e-10
> joint.paramAngle.cfm = 1e-10
>
> Or:
> joint.param['X'].cfm = 1e-5
> joint.param['Y'].cfm = 1e-10
> joint.param['Angle'].cfm = 1e-5
>
>
> The patch also contains PUJoint, PRJoint, PistonJoint and Joint.enable/disable,
> so it can be applied
> against latest git revision.
>
>
> I have tried to use 'Strip trailing spaces' in the editor, but now I have
> another problem.
> There are a lot of lines in the patch which do not change anything.
> e.g. (instead of dots, there are spaces):
> -....
> -      BallJoint(world, jointgroup=None)....
> +
> +      BallJoint(world, jointgroup=None)
>
> How should I get rid of these? Manually editing the patch? Git Gui does not help
> me
> (i.e. 'Stage/Unstage hunk from commit' does not work properly, and messes the
> entire patch)
>
> Alex
>
>> al...@ci... wrote:
>>> In ode.pyx there is a comment:
>>>
>>> ## This causes some kind of weird bug! Need to fix this.
>>>
>>> import weakref
>>>
>>> _geom_c2py_lut = weakref.WeakValueDictionary()
>>>
>>> In my programs, sometimes the lut is not able to find the geom ID,
>>> and Space.collide_callback() fails with a KeyError. When this happens,
>>> some boxes pass through the floor and fall down to -infinity.
>>> Using a normal dictionary seems to solve the problem.
>>>
>>> Is this the weird bug?
>>
>> It sounds related but this isn't exactly the bug I was confused about
>> when I wrote that comment. The bug is that if you create Geoms but don't
>> save references to them, (like the "geoms" list in tutorial 3) then the
>> geoms get garbage collected and they therefore don't have any collisions.
>>
>> Your bug sounds related, because it seems like geoms are getting garbage
>> collected, but if that's true, then they should be getting destroyed
>> with dGeomDestroy() and so not causing collisions.
>>
>>> Therefore, we have two possibilities to solve the conflict:
>>>
>>> A) Overriding __setattr__:
>>>
>>>    Pros: - compatible with existing code
>>>
>>>    Cons: - may be slow (overriding __getattr__ and __setattr__ slows down the
>>> access to class items)
>>>          - you are not warned at all if you misspell the name of a property
>>>           (e.g. you use body.pos = (1,2,3) but the correct name is
>>> 'body.position'; however, python will not complain at all)
>>>
>>> B) Custom data field:
>>>    Pros: - more lightweight
>>>          - works fine, with no conflicts
>>>          - if you misspell the name of a property, you will receive an error
>>>
>>>    Cons: - breaks existing code which uses custom data
>>
>> I like B better. It would be really great if we could offer a setting
>> that would enable backwards-compatible behavior, though :)
>>
>>> Which one should we choose? I prefer B) since it already works on my
>>> computer.
>>>
>>> I have also implemented a mechanism for accessing joint parameters as
>>> properties.
>>> It works like this:
>>>
>>> j = ode.HingeJoint(world)
>>> j.param.lo_stop = 0
>>> j.param.cfm = 1e-5
>>> j.param.vel = 0.1
>>>
>>> For complex joints:
>>> joint.param[1].fmax = 1
>>> joint.param[2].fmax = 2
>>> joint.param[3].fmax = 3
>>>
>>> And for Plane2D:
>>> joint.paramX.cfm = 1e-5
>>> joint.paramY.cfm = 1e-10
>>> joint.paramAngle.cfm = 1e-10
>>>
>>> Or:
>>> joint.param['X'].cfm = 1e-5
>>> joint.param['Y'].cfm = 1e-10
>>> joint.param['Angle'].cfm = 1e-5
>>>
>>> And of course, the joint parameters are visible at TAB completion.
>>
>> Sounds like a good idea to me.
>>
>> Ethan
>>
>

Re: [Pyode-user] PyODE joint properties accessible as parameters

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

al...@ci... wrote:
> Hello,
> 
> Here is the patch for accessing joint parameters as properties.

Sorry for the long delay. I have reviewed and applied this patch. A few
notes:

1. The old mechanism for setting parameters may have been faster because
the reference to the ODE function (dJointGetBallParam,
dJointSetBallParam) gets compiled away. But then again, it may be as
fast to just use function pointers, the way you do. Plus, your code is
cleaner.

2. Why set setJointParam and getJointParam per-instance rather than
making a class variable?

3. This is a big patch -- I would have been happier reviewing and
committing each change separately. For instance, moving to
setJointParam/getJointParam as one commit, then introducing the
parameters-as-properties thing, then introducing new joint types..

> I have tried to use 'Strip trailing spaces' in the editor, but now I have
> another problem.
> There are a lot of lines in the patch which do not change anything.
> e.g. (instead of dots, there are spaces):
> -....
> -      BallJoint(world, jointgroup=None)....
> +
> +      BallJoint(world, jointgroup=None)
> 

> How should I get rid of these? Manually editing the patch? Git Gui does not help me
> (i.e. 'Stage/Unstage hunk from commit' does not work properly, and messes the
> entire patch)

Normally I would commit a whitespace cleanup commit first, but it's
often hard to remember.. I have separated out the parts of your patch
that are whitespace fixes and applied these secondly. (I use magit,
which lets you stage/unstage individual lines.)

Ethan

Re: [Pyode-user] PyODE joint properties accessible as parameters

[Niels <nie...@gm...>]

Thnx, but a short Question: How do i install the patch? -__-'

I would like to use the Pistion joint but is does not work in my current 
installation.