problems with iCub simulator, ODE, and memory leak

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

problems with iCub simulator, ODE, and memory leak

Frank Broz
Hello,

I'm attempting to run the demo for the interaction history architecture application in the simulator, but I'm seeing some odd behavior. Basically, shortly after the demo starts, the forces being applied to the robot by the movement commands to the simulator tear it apart. Soon after that, the simulator fails with the message:

ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in _dNormalize4() [../../include/ode/odemath.h]
Aborted

I thought that something might be going wrong numerically in ODE (version 0.10.1) because I had it compiled to use single precision. When I rebuild the library to use double precision (which should work with the simulator according to the wiki), I got these errors on attempting to start the simulator:

ODE Message 2: inertia must be positive definite in dMassCheck() File mass.cpp Line 53

ODE Message 2: inertia must be positive definite in dMassCheck() File mass.cpp Line 53

ODE INTERNAL ERROR 1: assertion "dMassCheck(mass)" failed in dBodySetMass() [ode.cpp]
Aborted

I also tested the the demo with version 0.9 of ODE compiled with both single and double precision. In both cases the simulator would start normally, but then the robot would be torn apart by the forces applied to it.

Based on these results I have a couple of questions:
-Should I be using the simulator with the single or double precision version of ODE? Does it matter?
-Have any changes been made to the simulator since last summer that would cause commands that used to result in safe movements for the robot to now fall outside allowable limits?
-Has anyone experienced a similar problem with the simulator? I'm assuming that the demo code for IHA should produce correct motions, but I believe that it was last used on the physical robot rather than the simulator. Are there changes that I need to make to translate motion commands to the real iCub into simulator commands?

Also, I'd like to follow up on the message to this list by Baris Akgun on January 27th to say that I'm also experiencing what seems to be a memory leak when using the simulator on the 64-bit version of Ubuntu 8.10.


Thanks,
-Frank









------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: problems with iCub simulator, ODE, and memory leak

Assif Mirza
Hi Frank,

Just a couple of points that may help you:

1 - the IHA was largely tested on the iCub robot itself and only early on on the simulator.  I recall having  similar problems where the simulator self-destructed.  I think this was down to the speeds being set too high. You may be able to use a slowed down version of the sequence files (each of which is a series of position commands with an associated speed),  (I think I actually hacked the simulator to slow everything down, but that should not be necessary!)

2 - if you want to check all the actions one by one, you can run the controller process on its own (without all the supporting processes and action control etc.) and then send commands to the port using a yarp write. The commands are just action numbers.  That way you can test things out in a more controlled way before letting the IHA take over completely.

hope this helps,

best,
Assif

2009/2/23 Frank Broz <[hidden email]>
Hello,

I'm attempting to run the demo for the interaction history architecture application in the simulator, but I'm seeing some odd behavior. Basically, shortly after the demo starts, the forces being applied to the robot by the movement commands to the simulator tear it apart. Soon after that, the simulator fails with the message:

ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in _dNormalize4() [../../include/ode/odemath.h]
Aborted

I thought that something might be going wrong numerically in ODE (version 0.10.1) because I had it compiled to use single precision. When I rebuild the library to use double precision (which should work with the simulator according to the wiki), I got these errors on attempting to start the simulator:

ODE Message 2: inertia must be positive definite in dMassCheck() File mass.cpp Line 53

ODE Message 2: inertia must be positive definite in dMassCheck() File mass.cpp Line 53

ODE INTERNAL ERROR 1: assertion "dMassCheck(mass)" failed in dBodySetMass() [ode.cpp]
Aborted

I also tested the the demo with version 0.9 of ODE compiled with both single and double precision. In both cases the simulator would start normally, but then the robot would be torn apart by the forces applied to it.

Based on these results I have a couple of questions:
-Should I be using the simulator with the single or double precision version of ODE? Does it matter?
-Have any changes been made to the simulator since last summer that would cause commands that used to result in safe movements for the robot to now fall outside allowable limits?
-Has anyone experienced a similar problem with the simulator? I'm assuming that the demo code for IHA should produce correct motions, but I believe that it was last used on the physical robot rather than the simulator. Are there changes that I need to make to translate motion commands to the real iCub into simulator commands?

Also, I'd like to follow up on the message to this list by Baris Akgun on January 27th to say that I'm also experiencing what seems to be a memory leak when using the simulator on the 64-bit version of Ubuntu 8.10.


Thanks,
-Frank









------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: problems with iCub simulator, ODE, and memory leak

paulfitz
Administrator
Hi Frank,

The README for the simulator says that ODE double precision is needed.  
I seem to remember a problem at the summer school last year where 64-bit
folks saw exploding-joint behavior.  Their solution, as I remember it,
was to download the ODE source package and compile it, rather than using
the version packaged by their distribution.  At that point too Vadim was
recommending ODE 9 rather than ODE 10 I think.

There was also a timescale issue where the simulator was out by a factor
of 10 from realtime.  Last time I looked this was fixed, but it could
have broken again.  The trick seems to be to keep the numbers in these
two parts in $ICUB_ROOT/src/iCubSimulation/iCub_Sim.h synchronized:

        ...
        dWorldStep(odeinit.world,0.01); // TIMESTEP
        ...
 
        ...
        // this needs to be kept synchronized with the timestep in
        // dWorldStep, in order to get correct world clock time
        //  --paulfitz
        int delay = 100;
        id = SDL_AddTimer( delay, &Simulation::ODE_process, (void*)1);
        ...

Vadim would have more up-to-date information on all of this than I though.

Cheers,
Paul

Assif Mirza wrote:

> Hi Frank,
>
> Just a couple of points that may help you:
>
> 1 - the IHA was largely tested on the iCub robot itself and only early
> on on the simulator.  I recall having  similar problems where the
> simulator self-destructed.  I think this was down to the speeds being
> set too high. You may be able to use a slowed down version of the
> sequence files (each of which is a series of position commands with an
> associated speed),  (I think I actually hacked the simulator to slow
> everything down, but that should not be necessary!)
>
> 2 - if you want to check all the actions one by one, you can run the
> controller process on its own (without all the supporting processes
> and action control etc.) and then send commands to the port using a
> yarp write. The commands are just action numbers.  That way you can
> test things out in a more controlled way before letting the IHA take
> over completely.
>
> hope this helps,
>
> best,
> Assif
>
> 2009/2/23 Frank Broz <[hidden email] <mailto:[hidden email]>>
>
>     Hello,
>
>     I'm attempting to run the demo for the interaction history
>     architecture application in the simulator, but I'm seeing some odd
>     behavior. Basically, shortly after the demo starts, the forces
>     being applied to the robot by the movement commands to the
>     simulator tear it apart. Soon after that, the simulator fails with
>     the message:
>
>     ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in
>     _dNormalize4() [../../include/ode/odemath.h]
>     Aborted
>
>     I thought that something might be going wrong numerically in ODE
>     (version 0.10.1) because I had it compiled to use single
>     precision. When I rebuild the library to use double precision
>     (which should work with the simulator according to the wiki), I
>     got these errors on attempting to start the simulator:
>
>     ODE Message 2: inertia must be positive definite in dMassCheck()
>     File mass.cpp Line 53
>
>     ODE Message 2: inertia must be positive definite in dMassCheck()
>     File mass.cpp Line 53
>
>     ODE INTERNAL ERROR 1: assertion "dMassCheck(mass)" failed in
>     dBodySetMass() [ode.cpp]
>     Aborted
>
>     I also tested the the demo with version 0.9 of ODE compiled with
>     both single and double precision. In both cases the simulator
>     would start normally, but then the robot would be torn apart by
>     the forces applied to it.
>
>     Based on these results I have a couple of questions:
>     -Should I be using the simulator with the single or double
>     precision version of ODE? Does it matter?
>     -Have any changes been made to the simulator since last summer
>     that would cause commands that used to result in safe movements
>     for the robot to now fall outside allowable limits?
>     -Has anyone experienced a similar problem with the simulator? I'm
>     assuming that the demo code for IHA should produce correct
>     motions, but I believe that it was last used on the physical robot
>     rather than the simulator. Are there changes that I need to make
>     to translate motion commands to the real iCub into simulator commands?
>
>     Also, I'd like to follow up on the message to this list by Baris
>     Akgun on January 27th to say that I'm also experiencing what seems
>     to be a memory leak when using the simulator on the 64-bit version
>     of Ubuntu 8.10.
>
>
>     Thanks,
>     -Frank
>
>
>
>
>
>
>
>
>
>     ------------------------------------------------------------------------------
>     Open Source Business Conference (OSBC), March 24-25, 2009, San
>     Francisco, CA
>     -OSBC tackles the biggest issue in open source: Open Sourcing the
>     Enterprise
>     -Strategies to boost innovation and cut costs with open source
>     participation
>     -Receive a $600 discount off the registration fee with the source
>     code: SFAD
>     http://p.sf.net/sfu/XcvMzF8H
>     _______________________________________________
>     Robotcub-hackers mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ------------------------------------------------------------------------
>
> _______________________________________________
> Robotcub-hackers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
>  


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: problems with iCub simulator, ODE, and memory leak

Vadim Tikhanoff
In reply to this post by Frank Broz
Hi Frank,

Sorry for replying a bit late. Paul is right in saying that the exploding problem was resolved by downloading the source package and compile it, rather than using the version packaged by their distribution. The ODE version does not matter anymore as the CMake dependencies were fixed. The most updated information is on the iCub wiki http://eris.liralab.it/wiki/ODE and http://eris.liralab.it/wiki/ODE or http://eris.liralab.it/wiki/Simulator_README as mentioned in the local README file. (which should be updated)
The timescale issue on the simulator has been fixed as Paul mentioned but I now acquired a 64Bit linux and will run some intensive tests in order to find out more.
The ODE library can be built in double or single mode depending on your setup. Single precision is much faster and uses less memory but you might encounter more numerical errors as in your case. The double precision was suggested as you would have more accuracy and stability, the downside is that it works a bit slower. This is all explained on the ODE website.
I will do the tests and get back to you.
Cheers,

Vadim

On Mon, Feb 23, 2009 at 7:23 PM, <[hidden email]> wrote:
Send Robotcub-hackers mailing list submissions to
       [hidden email]

To subscribe or unsubscribe via the World Wide Web, visit
       https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
or, via email, send a message with subject or body 'help' to
       [hidden email]

You can reach the person managing the list at
       [hidden email]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Robotcub-hackers digest..."


Today's Topics:

  1. Re: new yarpview ([hidden email])
  2. problems with iCub simulator, ODE, and memory leak (Frank Broz)
  3. Re: problems with iCub simulator, ODE, and memory leak
     (Assif Mirza)
  4. Re: problems with iCub simulator, ODE, and memory leak
     (Paul Fitzpatrick)


----------------------------------------------------------------------

Message: 1
Date: Thu, 19 Feb 2009 11:08:43 +0100 (CET)
From: [hidden email]
Subject: Re: [rc-hackers] new yarpview
To: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain;charset=iso-8859-1

>Hi,
>I have written an improved version of the yarpview. The new features are:
>
>- can synchronize with data from the port (i.e. plot each received frame)
>- compute and show port/display framerate
>- fix aspect ratio
>
>The code is in CVS, but the old yarpview is still compiled by default.
>To test the new code you have to enable the COMPILE_NEW_YARPVIEW flag in
>cmake (disabled by default).
>
>I would appreciate if someone could test the new code before we make it
>the default.
>
>Cheers,
>Lorenzo

Hi Lorenzo,

I just tested the new yarpview and it work fine here. I had the same
issues Frank F?rster had initially (gcc complaining about stray
characters) but that was fixed today after updating from cvs. This is
under Gentoo GNU/Linux x86 (32 bits). Let me tell you this is a welcome
improvement, thanks for your work!
Last thing, when yarpview is started from the command line, I get three
Gtk-related warnings:

(/yarpview:1487): Gtk-WARNING **: GtkSpinButton: setting an adjustment
with non-zero page size is deprecated

(/yarpview:1487): Gtk-WARNING **: Theme directory scalable/stock of theme
Rodent has no size field

(/yarpview:1487): Gtk-WARNING **: Theme directory 48x48/stock of theme
Rodent has no size field

I think only the first one might be interesting to you, as the other ones
are probably related to my linux distribution. In any case, yarpview works
well.

Jorge Scandaliaris

---
IRI
Institut de Rob?tica i Inform?tica Industrial (UPC-CSIC)
LLorens i Artigas 4-6 2nd Floor
Technology Park of Barcelona
08028 Barcelona
Phone: (+34) 93 401 58 05
Fax:   (+34) 93 401 57 50



------------------------------

Message: 2
Date: Mon, 23 Feb 2009 15:53:05 +0000
From: Frank Broz <[hidden email]>
Subject: [rc-hackers] problems with iCub simulator, ODE, and memory
       leak
To: [hidden email]
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

Hello,

I'm attempting to run the demo for the interaction history architecture
application in the simulator, but I'm seeing some odd behavior. Basically,
shortly after the demo starts, the forces being applied to the robot by the
movement commands to the simulator tear it apart. Soon after that, the
simulator fails with the message:

ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in
_dNormalize4() [../../include/ode/odemath.h]
Aborted

I thought that something might be going wrong numerically in ODE (version
0.10.1) because I had it compiled to use single precision. When I rebuild
the library to use double precision (which should work with the simulator
according to the wiki), I got these errors on attempting to start the
simulator:

ODE Message 2: inertia must be positive definite in dMassCheck() File
mass.cpp Line 53

ODE Message 2: inertia must be positive definite in dMassCheck() File
mass.cpp Line 53

ODE INTERNAL ERROR 1: assertion "dMassCheck(mass)" failed in dBodySetMass()
[ode.cpp]
Aborted

I also tested the the demo with version 0.9 of ODE compiled with both single
and double precision. In both cases the simulator would start normally, but
then the robot would be torn apart by the forces applied to it.

Based on these results I have a couple of questions:
-Should I be using the simulator with the single or double precision version
of ODE? Does it matter?
-Have any changes been made to the simulator since last summer that would
cause commands that used to result in safe movements for the robot to now
fall outside allowable limits?
-Has anyone experienced a similar problem with the simulator? I'm assuming
that the demo code for IHA should produce correct motions, but I believe
that it was last used on the physical robot rather than the simulator. Are
there changes that I need to make to translate motion commands to the real
iCub into simulator commands?

Also, I'd like to follow up on the message to this list by Baris Akgun on
January 27th to say that I'm also experiencing what seems to be a memory
leak when using the simulator on the 64-bit version of Ubuntu 8.10.


Thanks,
-Frank
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 3
Date: Mon, 23 Feb 2009 17:56:29 +0000
From: Assif Mirza <[hidden email]>
Subject: Re: [rc-hackers] problems with iCub simulator, ODE, and
       memory leak
To: Frank Broz <[hidden email]>
Cc: [hidden email]
Message-ID:
       <[hidden email]>
Content-Type: text/plain; charset="iso-8859-1"

Hi Frank,

Just a couple of points that may help you:

1 - the IHA was largely tested on the iCub robot itself and only early on on
the simulator.  I recall having  similar problems where the simulator
self-destructed.  I think this was down to the speeds being set too high.
You may be able to use a slowed down version of the sequence files (each of
which is a series of position commands with an associated speed),  (I think
I actually hacked the simulator to slow everything down, but that should not
be necessary!)

2 - if you want to check all the actions one by one, you can run the
controller process on its own (without all the supporting processes and
action control etc.) and then send commands to the port using a yarp write.
The commands are just action numbers.  That way you can test things out in a
more controlled way before letting the IHA take over completely.

hope this helps,

best,
Assif

2009/2/23 Frank Broz <[hidden email]>

> Hello,
>
> I'm attempting to run the demo for the interaction history architecture
> application in the simulator, but I'm seeing some odd behavior. Basically,
> shortly after the demo starts, the forces being applied to the robot by the
> movement commands to the simulator tear it apart. Soon after that, the
> simulator fails with the message:
>
> ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in
> _dNormalize4() [../../include/ode/odemath.h]
> Aborted
>
> I thought that something might be going wrong numerically in ODE (version
> 0.10.1) because I had it compiled to use single precision. When I rebuild
> the library to use double precision (which should work with the simulator
> according to the wiki), I got these errors on attempting to start the
> simulator:
>
> ODE Message 2: inertia must be positive definite in dMassCheck() File
> mass.cpp Line 53
>
> ODE Message 2: inertia must be positive definite in dMassCheck() File
> mass.cpp Line 53
>
> ODE INTERNAL ERROR 1: assertion "dMassCheck(mass)" failed in dBodySetMass()
> [ode.cpp]
> Aborted
>
> I also tested the the demo with version 0.9 of ODE compiled with both
> single and double precision. In both cases the simulator would start
> normally, but then the robot would be torn apart by the forces applied to
> it.
>
> Based on these results I have a couple of questions:
> -Should I be using the simulator with the single or double precision
> version of ODE? Does it matter?
> -Have any changes been made to the simulator since last summer that would
> cause commands that used to result in safe movements for the robot to now
> fall outside allowable limits?
> -Has anyone experienced a similar problem with the simulator? I'm assuming
> that the demo code for IHA should produce correct motions, but I believe
> that it was last used on the physical robot rather than the simulator. Are
> there changes that I need to make to translate motion commands to the real
> iCub into simulator commands?
>
> Also, I'd like to follow up on the message to this list by Baris Akgun on
> January 27th to say that I'm also experiencing what seems to be a memory
> leak when using the simulator on the 64-bit version of Ubuntu 8.10.
>
>
> Thanks,
> -Frank
>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Robotcub-hackers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...

------------------------------

Message: 4
Date: Mon, 23 Feb 2009 13:23:45 -0500
From: Paul Fitzpatrick <[hidden email]>
Subject: Re: [rc-hackers] problems with iCub simulator, ODE, and
       memory leak
To: Assif Mirza <[hidden email]>
Cc: [hidden email]
Message-ID: <[hidden email]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Frank,

The README for the simulator says that ODE double precision is needed.
I seem to remember a problem at the summer school last year where 64-bit
folks saw exploding-joint behavior.  Their solution, as I remember it,
was to download the ODE source package and compile it, rather than using
the version packaged by their distribution.  At that point too Vadim was
recommending ODE 9 rather than ODE 10 I think.

There was also a timescale issue where the simulator was out by a factor
of 10 from realtime.  Last time I looked this was fixed, but it could
have broken again.  The trick seems to be to keep the numbers in these
two parts in $ICUB_ROOT/src/iCubSimulation/iCub_Sim.h synchronized:

       ...
       dWorldStep(odeinit.world,0.01); // TIMESTEP
       ...

       ...
       // this needs to be kept synchronized with the timestep in
       // dWorldStep, in order to get correct world clock time
       //  --paulfitz
       int delay = 100;
       id = SDL_AddTimer( delay, &Simulation::ODE_process, (void*)1);
       ...

Vadim would have more up-to-date information on all of this than I though.

Cheers,
Paul

Assif Mirza wrote:
> Hi Frank,
>
> Just a couple of points that may help you:
>
> 1 - the IHA was largely tested on the iCub robot itself and only early
> on on the simulator.  I recall having  similar problems where the
> simulator self-destructed.  I think this was down to the speeds being
> set too high. You may be able to use a slowed down version of the
> sequence files (each of which is a series of position commands with an
> associated speed),  (I think I actually hacked the simulator to slow
> everything down, but that should not be necessary!)
>
> 2 - if you want to check all the actions one by one, you can run the
> controller process on its own (without all the supporting processes
> and action control etc.) and then send commands to the port using a
> yarp write. The commands are just action numbers.  That way you can
> test things out in a more controlled way before letting the IHA take
> over completely.
>
> hope this helps,
>
> best,
> Assif
>
> 2009/2/23 Frank Broz <[hidden email] <mailto:[hidden email]>>
>
>     Hello,
>
>     I'm attempting to run the demo for the interaction history
>     architecture application in the simulator, but I'm seeing some odd
>     behavior. Basically, shortly after the demo starts, the forces
>     being applied to the robot by the movement commands to the
>     simulator tear it apart. Soon after that, the simulator fails with
>     the message:
>
>     ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in
>     _dNormalize4() [../../include/ode/odemath.h]
>     Aborted
>
>     I thought that something might be going wrong numerically in ODE
>     (version 0.10.1) because I had it compiled to use single
>     precision. When I rebuild the library to use double precision
>     (which should work with the simulator according to the wiki), I
>     got these errors on attempting to start the simulator:
>
>     ODE Message 2: inertia must be positive definite in dMassCheck()
>     File mass.cpp Line 53
>
>     ODE Message 2: inertia must be positive definite in dMassCheck()
>     File mass.cpp Line 53
>
>     ODE INTERNAL ERROR 1: assertion "dMassCheck(mass)" failed in
>     dBodySetMass() [ode.cpp]
>     Aborted
>
>     I also tested the the demo with version 0.9 of ODE compiled with
>     both single and double precision. In both cases the simulator
>     would start normally, but then the robot would be torn apart by
>     the forces applied to it.
>
>     Based on these results I have a couple of questions:
>     -Should I be using the simulator with the single or double
>     precision version of ODE? Does it matter?
>     -Have any changes been made to the simulator since last summer
>     that would cause commands that used to result in safe movements
>     for the robot to now fall outside allowable limits?
>     -Has anyone experienced a similar problem with the simulator? I'm
>     assuming that the demo code for IHA should produce correct
>     motions, but I believe that it was last used on the physical robot
>     rather than the simulator. Are there changes that I need to make
>     to translate motion commands to the real iCub into simulator commands?
>
>     Also, I'd like to follow up on the message to this list by Baris
>     Akgun on January 27th to say that I'm also experiencing what seems
>     to be a memory leak when using the simulator on the 64-bit version
>     of Ubuntu 8.10.
>
>
>     Thanks,
>     -Frank
>
>
>
>
>
>
>
>
>
>     ------------------------------------------------------------------------------
>     Open Source Business Conference (OSBC), March 24-25, 2009, San
>     Francisco, CA
>     -OSBC tackles the biggest issue in open source: Open Sourcing the
>     Enterprise
>     -Strategies to boost innovation and cut costs with open source
>     participation
>     -Receive a $600 discount off the registration fee with the source
>     code: SFAD
>     http://p.sf.net/sfu/XcvMzF8H
>     _______________________________________________
>     Robotcub-hackers mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ------------------------------------------------------------------------
>
> _______________________________________________
> Robotcub-hackers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
>




------------------------------

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

------------------------------

_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers


End of Robotcub-hackers Digest, Vol 24, Issue 9
***********************************************


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: problems with iCub simulator, ODE, and memory leak

Frank Broz
In reply to this post by paulfitz
Paul,

Thanks for the clarification on ODE versions. I couldn't get ODE 10.1 with double precision to work with the simulator even when compiling from the source. ODE 9 seems to work, however. So changing ODE versions fixed the exploding joint problems that people had on 64-bit machines? Because that hasn't been the case for me.

Also, the timescales in the version of iCub_Sim.h I'm using match up, so that doesn't seem to be the problem. If I figure out its source I'll post that information to the list in case it is useful for others.

-Frank

On Mon, Feb 23, 2009 at 6:23 PM, Paul Fitzpatrick <[hidden email]> wrote:
Hi Frank,

The README for the simulator says that ODE double precision is needed.  I seem to remember a problem at the summer school last year where 64-bit folks saw exploding-joint behavior.  Their solution, as I remember it, was to download the ODE source package and compile it, rather than using the version packaged by their distribution.  At that point too Vadim was recommending ODE 9 rather than ODE 10 I think.

There was also a timescale issue where the simulator was out by a factor of 10 from realtime.  Last time I looked this was fixed, but it could have broken again.  The trick seems to be to keep the numbers in these two parts in $ICUB_ROOT/src/iCubSimulation/iCub_Sim.h synchronized:

      ...
      dWorldStep(odeinit.world,0.01); // TIMESTEP
      ...
        ...
      // this needs to be kept synchronized with the timestep in
      // dWorldStep, in order to get correct world clock time
      //  --paulfitz
      int delay = 100;
      id = SDL_AddTimer( delay, &Simulation::ODE_process, (void*)1);
      ...

Vadim would have more up-to-date information on all of this than I though.

Cheers,
Paul

Assif Mirza wrote:
Hi Frank,

Just a couple of points that may help you:

1 - the IHA was largely tested on the iCub robot itself and only early on on the simulator.  I recall having  similar problems where the simulator self-destructed.  I think this was down to the speeds being set too high. You may be able to use a slowed down version of the sequence files (each of which is a series of position commands with an associated speed),  (I think I actually hacked the simulator to slow everything down, but that should not be necessary!)

2 - if you want to check all the actions one by one, you can run the controller process on its own (without all the supporting processes and action control etc.) and then send commands to the port using a yarp write. The commands are just action numbers.  That way you can test things out in a more controlled way before letting the IHA take over completely.

hope this helps,

best,
Assif

2009/2/23 Frank Broz <[hidden email] <mailto:[hidden email]>>


   Hello,

   I'm attempting to run the demo for the interaction history
   architecture application in the simulator, but I'm seeing some odd
   behavior. Basically, shortly after the demo starts, the forces
   being applied to the robot by the movement commands to the
   simulator tear it apart. Soon after that, the simulator fails with
   the message:

   ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in
   _dNormalize4() [../../include/ode/odemath.h]
   Aborted

   I thought that something might be going wrong numerically in ODE
   (version 0.10.1) because I had it compiled to use single
   precision. When I rebuild the library to use double precision
   (which should work with the simulator according to the wiki), I
   got these errors on attempting to start the simulator:

   ODE Message 2: inertia must be positive definite in dMassCheck()
   File mass.cpp Line 53

   ODE Message 2: inertia must be positive definite in dMassCheck()
   File mass.cpp Line 53

   ODE INTERNAL ERROR 1: assertion "dMassCheck(mass)" failed in
   dBodySetMass() [ode.cpp]
   Aborted

   I also tested the the demo with version 0.9 of ODE compiled with
   both single and double precision. In both cases the simulator
   would start normally, but then the robot would be torn apart by
   the forces applied to it.

   Based on these results I have a couple of questions:
   -Should I be using the simulator with the single or double
   precision version of ODE? Does it matter?
   -Have any changes been made to the simulator since last summer
   that would cause commands that used to result in safe movements
   for the robot to now fall outside allowable limits?
   -Has anyone experienced a similar problem with the simulator? I'm
   assuming that the demo code for IHA should produce correct
   motions, but I believe that it was last used on the physical robot
   rather than the simulator. Are there changes that I need to make
   to translate motion commands to the real iCub into simulator commands?

   Also, I'd like to follow up on the message to this list by Baris
   Akgun on January 27th to say that I'm also experiencing what seems
   to be a memory leak when using the simulator on the 64-bit version
   of Ubuntu 8.10.


   Thanks,
   -Frank









   ------------------------------------------------------------------------------
   Open Source Business Conference (OSBC), March 24-25, 2009, San
   Francisco, CA
   -OSBC tackles the biggest issue in open source: Open Sourcing the
   Enterprise
   -Strategies to boost innovation and cut costs with open source
   participation
   -Receive a $600 discount off the registration fee with the source
   code: SFAD
   http://p.sf.net/sfu/XcvMzF8H
   _______________________________________________
   Robotcub-hackers mailing list
   [hidden email]
   <mailto:[hidden email]> ------------------------------------------------------------------------


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
------------------------------------------------------------------------

_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
 



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: problems with iCub simulator, ODE, and memory leak

Frank Broz
In reply to this post by Frank Broz
Baris,

Thanks for the information. Just to clarify, you're saying that you eliminated the exploding joint problem you were having on a 64-bit machine by using ODE 0.9 with single precision? I'm currently still having this problem with ODE 0.9 while using either single or double precision.

If you'd be willing to check out what modifications were made to your lab's version of the simulator to eliminate the memory leak and let me know what they were, I'd really appreciate it.

Thanks,
-Frank

On Mon, Feb 23, 2009 at 8:17 PM, Baris Akgun <[hidden email]> wrote:
Hello Frank,

I didn't receive any answer regarding to the memory leak issue. I am
using a modified version (by our lab) of the simulator which doesn't
have a memory leak. I didn't check what is different. If it comes to
that I will try to compare them. I am really surprised that no one else
has this issue.

As to exploding joints, we had similar issues while we were using the
hands. I think that is related to ODE, probably version 0.10. We are now
using 0.9 and it seems to be gone. Similarly I was only able to run the
simulator on a 64 bit machine with single precision. I get the same
errors when I try to use double precision.

I do not know much about ODE but maybe creating everything 10 times
bigger and heavier may solve the issues about exploding joints. They
seem to be happening because of floating point residuals and using
single precision might be amplifying the effect.

Is there anybody who uses the simulator with ubuntu 8.04 64bit and has
none of these problems? Maybe there is a problem with 8.10.

Cheers,
Baris

On Mon, 2009-02-23 at 15:53 +0000, Frank Broz wrote:
> Hello,
>
> I'm attempting to run the demo for the interaction history
> architecture application in the simulator, but I'm seeing some odd
> behavior. Basically, shortly after the demo starts, the forces being
> applied to the robot by the movement commands to the simulator tear it
> apart. Soon after that, the simulator fails with the message:
>
> ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in
> _dNormalize4() [../../include/ode/odemath.h]
> Aborted
>
> I thought that something might be going wrong numerically in ODE
> (version 0.10.1) because I had it compiled to use single precision.
> When I rebuild the library to use double precision (which should work
> with the simulator according to the wiki), I got these errors on
> attempting to start the simulator:
>
> ODE Message 2: inertia must be positive definite in dMassCheck() File
> mass.cpp Line 53
>
> ODE Message 2: inertia must be positive definite in dMassCheck() File
> mass.cpp Line 53
>
> ODE INTERNAL ERROR 1: assertion "dMassCheck(mass)" failed in
> dBodySetMass() [ode.cpp]
> Aborted
>
> I also tested the the demo with version 0.9 of ODE compiled with both
> single and double precision. In both cases the simulator would start
> normally, but then the robot would be torn apart by the forces applied
> to it.
>
> Based on these results I have a couple of questions:
> -Should I be using the simulator with the single or double precision
> version of ODE? Does it matter?
> -Have any changes been made to the simulator since last summer that
> would cause commands that used to result in safe movements for the
> robot to now fall outside allowable limits?
> -Has anyone experienced a similar problem with the simulator? I'm
> assuming that the demo code for IHA should produce correct motions,
> but I believe that it was last used on the physical robot rather than
> the simulator. Are there changes that I need to make to translate
> motion commands to the real iCub into simulator commands?
>
> Also, I'd like to follow up on the message to this list by Baris Akgun
> on January 27th to say that I'm also experiencing what seems to be a
> memory leak when using the simulator on the 64-bit version of Ubuntu
> 8.10.
>
>
> Thanks,
> -Frank
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________ Robotcub-hackers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/robotcub-hackers



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Matlab-based applications

Yan Wu-3
In reply to this post by Vadim Tikhanoff
Hi,

  I find that most of the MatLab-based applications are more adapted to
Windows, causing some slight errors under Linux. Using iKinArmView as an
example:
  1. CMakeLists.txt include Windows version of Matlab libraries only
(i.e. *.lib, not *.so).
  2. In function "void chageMLToCurDir(Engine *ep)":
          ACE_OS::system("cd > curDir.txt");    // This pipes the user's
home directory into curDir.txt in Linux, whereas the current directory
in Windows.
  3. In function "bool runViewer(Engine *ep, const string &armType)":
         string s(ret_string);   // If the programme runs smoothly,
MatLab will return "ok\n" in Windows, but ">>  ok\n" in Linux, causing
the if statement to return false perpetually.

  Pertaining to iKinArmView itself, when the programme is run and before
the first target position is applied, the variable 'xd' is not defined
at the 'base' workspace . This makes Matlab to keep prompting that the
variable xd is not valid in the terminal. I suggest to add the
assignment line (assignin('base','xd',xd');) at line 58 of iKinArmView.m
to remove this problem.


Cheers,
Yan

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: Matlab-based applications

pattacini

Hi Yan,

 

I wrote the MATLAB-based viewers just for Windows platform originally exploiting the COM approach; I’ve never tested them under Linux so far. Anyway thanks for your feedback: it is good to know that they seem almost runnable under Linux, with the exception of the issues you’ve reported; I will try to fix them up.

 

Ciao,

Ugo Pattacini

 

 


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: problems with iCub simulator, ODE, and memory leak

Lorenzo Natale-2
In reply to this post by Vadim Tikhanoff
Hello Vadim,
the documentation reports the version of ODE that is needed, but it does
not mention problems with the Debian/Ubuntu packages (on Debian etch I
think it does not even compile). Maybe we should change the
documentation so that it is more clear in this respect.

Cheers,
Lorenzo

Vadim Tikhanoff wrote:

> Hi Frank,
>
> Sorry for replying a bit late. Paul is right in saying that the
> exploding problem was resolved by downloading the source package and
> compile it, rather than using the version packaged by their
> distribution. The ODE version does not matter anymore as the CMake
> dependencies were fixed. The most updated information is on the iCub
> wiki http://eris.liralab.it/wiki/ODE and http://eris.liralab.it/wiki/ODE 
> or http://eris.liralab.it/wiki/Simulator_README as mentioned in the
> local README file. (which should be updated)
> The timescale issue on the simulator has been fixed as Paul mentioned
> but I now acquired a 64Bit linux and will run some intensive tests in
> order to find out more.
> The ODE library can be built in double or single mode depending on your
> setup. Single precision is much faster and uses less memory but you
> might encounter more numerical errors as in your case. The double
> precision was suggested as you would have more accuracy and stability,
> the downside is that it works a bit slower. This is all explained on the
> ODE website.
> I will do the tests and get back to you.
> Cheers,
>
> Vadim
>
> On Mon, Feb 23, 2009 at 7:23 PM,
> <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Send Robotcub-hackers mailing list submissions to
>            [hidden email]
>     <mailto:[hidden email]>
>
>     To subscribe or unsubscribe via the World Wide Web, visit
>            https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
>     or, via email, send a message with subject or body 'help' to
>            [hidden email]
>     <mailto:[hidden email]>
>
>     You can reach the person managing the list at
>            [hidden email]
>     <mailto:[hidden email]>
>
>     When replying, please edit your Subject line so it is more specific
>     than "Re: Contents of Robotcub-hackers digest..."
>
>
>     Today's Topics:
>
>       1. Re: new yarpview ([hidden email]
>     <mailto:[hidden email]>)
>       2. problems with iCub simulator, ODE, and memory leak (Frank Broz)
>       3. Re: problems with iCub simulator, ODE, and memory leak
>          (Assif Mirza)
>       4. Re: problems with iCub simulator, ODE, and memory leak
>          (Paul Fitzpatrick)
>
>
>     ----------------------------------------------------------------------
>
>     Message: 1
>     Date: Thu, 19 Feb 2009 11:08:43 +0100 (CET)
>     From: [hidden email] <mailto:[hidden email]>
>     Subject: Re: [rc-hackers] new yarpview
>     To: [hidden email]
>     <mailto:[hidden email]>
>     Message-ID: <[hidden email]
>     <mailto:[hidden email]>>
>     Content-Type: text/plain;charset=iso-8859-1
>
>      >Hi,
>      >I have written an improved version of the yarpview. The new
>     features are:
>      >
>      >- can synchronize with data from the port (i.e. plot each received
>     frame)
>      >- compute and show port/display framerate
>      >- fix aspect ratio
>      >
>      >The code is in CVS, but the old yarpview is still compiled by default.
>      >To test the new code you have to enable the COMPILE_NEW_YARPVIEW
>     flag in
>      >cmake (disabled by default).
>      >
>      >I would appreciate if someone could test the new code before we
>     make it
>      >the default.
>      >
>      >Cheers,
>      >Lorenzo
>
>     Hi Lorenzo,
>
>     I just tested the new yarpview and it work fine here. I had the same
>     issues Frank F?rster had initially (gcc complaining about stray
>     characters) but that was fixed today after updating from cvs. This is
>     under Gentoo GNU/Linux x86 (32 bits). Let me tell you this is a welcome
>     improvement, thanks for your work!
>     Last thing, when yarpview is started from the command line, I get three
>     Gtk-related warnings:
>
>     (/yarpview:1487): Gtk-WARNING **: GtkSpinButton: setting an adjustment
>     with non-zero page size is deprecated
>
>     (/yarpview:1487): Gtk-WARNING **: Theme directory scalable/stock of
>     theme
>     Rodent has no size field
>
>     (/yarpview:1487): Gtk-WARNING **: Theme directory 48x48/stock of theme
>     Rodent has no size field
>
>     I think only the first one might be interesting to you, as the other
>     ones
>     are probably related to my linux distribution. In any case, yarpview
>     works
>     well.
>
>     Jorge Scandaliaris
>
>     ---
>     IRI
>     Institut de Rob?tica i Inform?tica Industrial (UPC-CSIC)
>     LLorens i Artigas 4-6 2nd Floor
>     Technology Park of Barcelona
>     08028 Barcelona
>     Phone: (+34) 93 401 58 05
>     Fax:   (+34) 93 401 57 50
>
>
>
>     ------------------------------
>
>     Message: 2
>     Date: Mon, 23 Feb 2009 15:53:05 +0000
>     From: Frank Broz <[hidden email] <mailto:[hidden email]>>
>     Subject: [rc-hackers] problems with iCub simulator, ODE, and memory
>            leak
>     To: [hidden email]
>     <mailto:[hidden email]>
>     Message-ID:
>            <[hidden email]
>     <mailto:[hidden email]>>
>     Content-Type: text/plain; charset="iso-8859-1"
>
>     Hello,
>
>     I'm attempting to run the demo for the interaction history architecture
>     application in the simulator, but I'm seeing some odd behavior.
>     Basically,
>     shortly after the demo starts, the forces being applied to the robot
>     by the
>     movement commands to the simulator tear it apart. Soon after that, the
>     simulator fails with the message:
>
>     ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in
>     _dNormalize4() [../../include/ode/odemath.h]
>     Aborted
>
>     I thought that something might be going wrong numerically in ODE
>     (version
>     0.10.1) because I had it compiled to use single precision. When I
>     rebuild
>     the library to use double precision (which should work with the
>     simulator
>     according to the wiki), I got these errors on attempting to start the
>     simulator:
>
>     ODE Message 2: inertia must be positive definite in dMassCheck() File
>     mass.cpp Line 53
>
>     ODE Message 2: inertia must be positive definite in dMassCheck() File
>     mass.cpp Line 53
>
>     ODE INTERNAL ERROR 1: assertion "dMassCheck(mass)" failed in
>     dBodySetMass()
>     [ode.cpp]
>     Aborted
>
>     I also tested the the demo with version 0.9 of ODE compiled with
>     both single
>     and double precision. In both cases the simulator would start
>     normally, but
>     then the robot would be torn apart by the forces applied to it.
>
>     Based on these results I have a couple of questions:
>     -Should I be using the simulator with the single or double precision
>     version
>     of ODE? Does it matter?
>     -Have any changes been made to the simulator since last summer that
>     would
>     cause commands that used to result in safe movements for the robot
>     to now
>     fall outside allowable limits?
>     -Has anyone experienced a similar problem with the simulator? I'm
>     assuming
>     that the demo code for IHA should produce correct motions, but I believe
>     that it was last used on the physical robot rather than the
>     simulator. Are
>     there changes that I need to make to translate motion commands to
>     the real
>     iCub into simulator commands?
>
>     Also, I'd like to follow up on the message to this list by Baris
>     Akgun on
>     January 27th to say that I'm also experiencing what seems to be a memory
>     leak when using the simulator on the 64-bit version of Ubuntu 8.10.
>
>
>     Thanks,
>     -Frank
>     -------------- next part --------------
>     An HTML attachment was scrubbed...
>
>     ------------------------------
>
>     Message: 3
>     Date: Mon, 23 Feb 2009 17:56:29 +0000
>     From: Assif Mirza <[hidden email] <mailto:[hidden email]>>
>     Subject: Re: [rc-hackers] problems with iCub simulator, ODE, and
>            memory leak
>     To: Frank Broz <[hidden email] <mailto:[hidden email]>>
>     Cc: [hidden email]
>     <mailto:[hidden email]>
>     Message-ID:
>            <[hidden email]
>     <mailto:[hidden email]>>
>     Content-Type: text/plain; charset="iso-8859-1"
>
>     Hi Frank,
>
>     Just a couple of points that may help you:
>
>     1 - the IHA was largely tested on the iCub robot itself and only
>     early on on
>     the simulator.  I recall having  similar problems where the simulator
>     self-destructed.  I think this was down to the speeds being set too
>     high.
>     You may be able to use a slowed down version of the sequence files
>     (each of
>     which is a series of position commands with an associated speed),
>      (I think
>     I actually hacked the simulator to slow everything down, but that
>     should not
>     be necessary!)
>
>     2 - if you want to check all the actions one by one, you can run the
>     controller process on its own (without all the supporting processes and
>     action control etc.) and then send commands to the port using a yarp
>     write.
>     The commands are just action numbers.  That way you can test things
>     out in a
>     more controlled way before letting the IHA take over completely.
>
>     hope this helps,
>
>     best,
>     Assif
>
>     2009/2/23 Frank Broz <[hidden email] <mailto:[hidden email]>>
>
>      > Hello,
>      >
>      > I'm attempting to run the demo for the interaction history
>     architecture
>      > application in the simulator, but I'm seeing some odd behavior.
>     Basically,
>      > shortly after the demo starts, the forces being applied to the
>     robot by the
>      > movement commands to the simulator tear it apart. Soon after
>     that, the
>      > simulator fails with the message:
>      >
>      > ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in
>      > _dNormalize4() [../../include/ode/odemath.h]
>      > Aborted
>      >
>      > I thought that something might be going wrong numerically in ODE
>     (version
>      > 0.10.1) because I had it compiled to use single precision. When I
>     rebuild
>      > the library to use double precision (which should work with the
>     simulator
>      > according to the wiki), I got these errors on attempting to start the
>      > simulator:
>      >
>      > ODE Message 2: inertia must be positive definite in dMassCheck() File
>      > mass.cpp Line 53
>      >
>      > ODE Message 2: inertia must be positive definite in dMassCheck() File
>      > mass.cpp Line 53
>      >
>      > ODE INTERNAL ERROR 1: assertion "dMassCheck(mass)" failed in
>     dBodySetMass()
>      > [ode.cpp]
>      > Aborted
>      >
>      > I also tested the the demo with version 0.9 of ODE compiled with both
>      > single and double precision. In both cases the simulator would start
>      > normally, but then the robot would be torn apart by the forces
>     applied to
>      > it.
>      >
>      > Based on these results I have a couple of questions:
>      > -Should I be using the simulator with the single or double precision
>      > version of ODE? Does it matter?
>      > -Have any changes been made to the simulator since last summer
>     that would
>      > cause commands that used to result in safe movements for the
>     robot to now
>      > fall outside allowable limits?
>      > -Has anyone experienced a similar problem with the simulator? I'm
>     assuming
>      > that the demo code for IHA should produce correct motions, but I
>     believe
>      > that it was last used on the physical robot rather than the
>     simulator. Are
>      > there changes that I need to make to translate motion commands to
>     the real
>      > iCub into simulator commands?
>      >
>      > Also, I'd like to follow up on the message to this list by Baris
>     Akgun on
>      > January 27th to say that I'm also experiencing what seems to be a
>     memory
>      > leak when using the simulator on the 64-bit version of Ubuntu 8.10.
>      >
>      >
>      > Thanks,
>      > -Frank
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>     ------------------------------------------------------------------------------
>      > Open Source Business Conference (OSBC), March 24-25, 2009, San
>     Francisco,
>      > CA
>      > -OSBC tackles the biggest issue in open source: Open Sourcing the
>      > Enterprise
>      > -Strategies to boost innovation and cut costs with open source
>      > participation
>      > -Receive a $600 discount off the registration fee with the source
>     code:
>      > SFAD
>      > http://p.sf.net/sfu/XcvMzF8H
>      > _______________________________________________
>      > Robotcub-hackers mailing list
>      > [hidden email]
>     <mailto:[hidden email]>
>      > https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
>      >
>      >
>     -------------- next part --------------
>     An HTML attachment was scrubbed...
>
>     ------------------------------
>
>     Message: 4
>     Date: Mon, 23 Feb 2009 13:23:45 -0500
>     From: Paul Fitzpatrick <[hidden email]
>     <mailto:[hidden email]>>
>     Subject: Re: [rc-hackers] problems with iCub simulator, ODE, and
>            memory leak
>     To: Assif Mirza <[hidden email] <mailto:[hidden email]>>
>     Cc: [hidden email]
>     <mailto:[hidden email]>
>     Message-ID: <[hidden email]
>     <mailto:[hidden email]>>
>     Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>     Hi Frank,
>
>     The README for the simulator says that ODE double precision is needed.
>     I seem to remember a problem at the summer school last year where 64-bit
>     folks saw exploding-joint behavior.  Their solution, as I remember it,
>     was to download the ODE source package and compile it, rather than using
>     the version packaged by their distribution.  At that point too Vadim was
>     recommending ODE 9 rather than ODE 10 I think.
>
>     There was also a timescale issue where the simulator was out by a factor
>     of 10 from realtime.  Last time I looked this was fixed, but it could
>     have broken again.  The trick seems to be to keep the numbers in these
>     two parts in $ICUB_ROOT/src/iCubSimulation/iCub_Sim.h synchronized:
>
>            ...
>            dWorldStep(odeinit.world,0.01); // TIMESTEP
>            ...
>
>            ...
>            // this needs to be kept synchronized with the timestep in
>            // dWorldStep, in order to get correct world clock time
>            //  --paulfitz
>            int delay = 100;
>            id = SDL_AddTimer( delay, &Simulation::ODE_process, (void*)1);
>            ...
>
>     Vadim would have more up-to-date information on all of this than I
>     though.
>
>     Cheers,
>     Paul
>
>     Assif Mirza wrote:
>      > Hi Frank,
>      >
>      > Just a couple of points that may help you:
>      >
>      > 1 - the IHA was largely tested on the iCub robot itself and only
>     early
>      > on on the simulator.  I recall having  similar problems where the
>      > simulator self-destructed.  I think this was down to the speeds being
>      > set too high. You may be able to use a slowed down version of the
>      > sequence files (each of which is a series of position commands
>     with an
>      > associated speed),  (I think I actually hacked the simulator to slow
>      > everything down, but that should not be necessary!)
>      >
>      > 2 - if you want to check all the actions one by one, you can run the
>      > controller process on its own (without all the supporting processes
>      > and action control etc.) and then send commands to the port using a
>      > yarp write. The commands are just action numbers.  That way you can
>      > test things out in a more controlled way before letting the IHA take
>      > over completely.
>      >
>      > hope this helps,
>      >
>      > best,
>      > Assif
>      >
>      > 2009/2/23 Frank Broz <[hidden email]
>     <mailto:[hidden email]> <mailto:[hidden email]
>     <mailto:[hidden email]>>>
>      >
>      >     Hello,
>      >
>      >     I'm attempting to run the demo for the interaction history
>      >     architecture application in the simulator, but I'm seeing
>     some odd
>      >     behavior. Basically, shortly after the demo starts, the forces
>      >     being applied to the robot by the movement commands to the
>      >     simulator tear it apart. Soon after that, the simulator fails
>     with
>      >     the message:
>      >
>      >     ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in
>      >     _dNormalize4() [../../include/ode/odemath.h]
>      >     Aborted
>      >
>      >     I thought that something might be going wrong numerically in ODE
>      >     (version 0.10.1) because I had it compiled to use single
>      >     precision. When I rebuild the library to use double precision
>      >     (which should work with the simulator according to the wiki), I
>      >     got these errors on attempting to start the simulator:
>      >
>      >     ODE Message 2: inertia must be positive definite in dMassCheck()
>      >     File mass.cpp Line 53
>      >
>      >     ODE Message 2: inertia must be positive definite in dMassCheck()
>      >     File mass.cpp Line 53
>      >
>      >     ODE INTERNAL ERROR 1: assertion "dMassCheck(mass)" failed in
>      >     dBodySetMass() [ode.cpp]
>      >     Aborted
>      >
>      >     I also tested the the demo with version 0.9 of ODE compiled with
>      >     both single and double precision. In both cases the simulator
>      >     would start normally, but then the robot would be torn apart by
>      >     the forces applied to it.
>      >
>      >     Based on these results I have a couple of questions:
>      >     -Should I be using the simulator with the single or double
>      >     precision version of ODE? Does it matter?
>      >     -Have any changes been made to the simulator since last summer
>      >     that would cause commands that used to result in safe movements
>      >     for the robot to now fall outside allowable limits?
>      >     -Has anyone experienced a similar problem with the simulator? I'm
>      >     assuming that the demo code for IHA should produce correct
>      >     motions, but I believe that it was last used on the physical
>     robot
>      >     rather than the simulator. Are there changes that I need to make
>      >     to translate motion commands to the real iCub into simulator
>     commands?
>      >
>      >     Also, I'd like to follow up on the message to this list by Baris
>      >     Akgun on January 27th to say that I'm also experiencing what
>     seems
>      >     to be a memory leak when using the simulator on the 64-bit
>     version
>      >     of Ubuntu 8.10.
>      >
>      >
>      >     Thanks,
>      >     -Frank
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >
>      >    
>     ------------------------------------------------------------------------------
>      >     Open Source Business Conference (OSBC), March 24-25, 2009, San
>      >     Francisco, CA
>      >     -OSBC tackles the biggest issue in open source: Open Sourcing the
>      >     Enterprise
>      >     -Strategies to boost innovation and cut costs with open source
>      >     participation
>      >     -Receive a $600 discount off the registration fee with the source
>      >     code: SFAD
>      >     http://p.sf.net/sfu/XcvMzF8H
>      >     _______________________________________________
>      >     Robotcub-hackers mailing list
>      >     [hidden email]
>     <mailto:[hidden email]>
>      >     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>      >     https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
>      >
>      >
>      >
>     ------------------------------------------------------------------------
>      >
>      >
>     ------------------------------------------------------------------------------
>      > Open Source Business Conference (OSBC), March 24-25, 2009, San
>     Francisco, CA
>      > -OSBC tackles the biggest issue in open source: Open Sourcing the
>     Enterprise
>      > -Strategies to boost innovation and cut costs with open source
>     participation
>      > -Receive a $600 discount off the registration fee with the source
>     code: SFAD
>      > http://p.sf.net/sfu/XcvMzF8H
>      >
>     ------------------------------------------------------------------------
>      >
>      > _______________________________________________
>      > Robotcub-hackers mailing list
>      > [hidden email]
>     <mailto:[hidden email]>
>      > https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
>      >
>
>
>
>
>     ------------------------------
>
>     ------------------------------------------------------------------------------
>     Open Source Business Conference (OSBC), March 24-25, 2009, San
>     Francisco, CA
>     -OSBC tackles the biggest issue in open source: Open Sourcing the
>     Enterprise
>     -Strategies to boost innovation and cut costs with open source
>     participation
>     -Receive a $600 discount off the registration fee with the source
>     code: SFAD
>     http://p.sf.net/sfu/XcvMzF8H
>
>     ------------------------------
>
>     _______________________________________________
>     Robotcub-hackers mailing list
>     [hidden email]
>     <mailto:[hidden email]>
>     https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
>
>
>     End of Robotcub-hackers Digest, Vol 24, Issue 9
>     ***********************************************
>
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Robotcub-hackers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/robotcub-hackers


--
Istituto Italiano di Tecnologia
Lorenzo Natale, PhD
[hidden email]
via Morego, 30 16163 Genova
Ph: +39 010 71781400
Fax: +39 010 7170817
www.iit.it


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: problems with iCub simulator, ODE, and memory leak

Baris Akgun
In reply to this post by Frank Broz
Frank,

The exploding problem dissappeared after I changed to 0.9, however
around the same time, we made some modifications to behaviors. That
might be the real reason (coincidense?).

About the memory leak: As to what is different; in rendering.cpp there
is a function call "gluNewQuadric". However There is no following
"gluDeleteQuadric". I am not very sure if this is really the reason. I
am not able to try at the moment. (Broken harddisk... just setting up a
new one)

I will post the result as soon as I try it out.

Baris

On Tue, 2009-02-24 at 13:26 +0000, Frank Broz wrote:

> Baris,
>
> Thanks for the information. Just to clarify, you're saying that you
> eliminated the exploding joint problem you were having on a 64-bit
> machine by using ODE 0.9 with single precision? I'm currently still
> having this problem with ODE 0.9 while using either single or double
> precision.
>
> If you'd be willing to check out what modifications were made to your
> lab's version of the simulator to eliminate the memory leak and let me
> know what they were, I'd really appreciate it.
>
> Thanks,
> -Frank
>
> On Mon, Feb 23, 2009 at 8:17 PM, Baris Akgun <[hidden email]>
> wrote:
>         Hello Frank,
>        
>         I didn't receive any answer regarding to the memory leak
>         issue. I am
>         using a modified version (by our lab) of the simulator which
>         doesn't
>         have a memory leak. I didn't check what is different. If it
>         comes to
>         that I will try to compare them. I am really surprised that no
>         one else
>         has this issue.
>        
>         As to exploding joints, we had similar issues while we were
>         using the
>         hands. I think that is related to ODE, probably version 0.10.
>         We are now
>         using 0.9 and it seems to be gone. Similarly I was only able
>         to run the
>         simulator on a 64 bit machine with single precision. I get the
>         same
>         errors when I try to use double precision.
>        
>         I do not know much about ODE but maybe creating everything 10
>         times
>         bigger and heavier may solve the issues about exploding
>         joints. They
>         seem to be happening because of floating point residuals and
>         using
>         single precision might be amplifying the effect.
>        
>         Is there anybody who uses the simulator with ubuntu 8.04 64bit
>         and has
>         none of these problems? Maybe there is a problem with 8.10.
>        
>         Cheers,
>         Baris
>        
>        
>         On Mon, 2009-02-23 at 15:53 +0000, Frank Broz wrote:
>         > Hello,
>         >
>         > I'm attempting to run the demo for the interaction history
>         > architecture application in the simulator, but I'm seeing
>         some odd
>         > behavior. Basically, shortly after the demo starts, the
>         forces being
>         > applied to the robot by the movement commands to the
>         simulator tear it
>         > apart. Soon after that, the simulator fails with the
>         message:
>         >
>         > ODE INTERNAL ERROR 1: assertion "bNormalizationResult"
>         failed in
>         > _dNormalize4() [../../include/ode/odemath.h]
>         > Aborted
>         >
>         > I thought that something might be going wrong numerically in
>         ODE
>         > (version 0.10.1) because I had it compiled to use single
>         precision.
>         > When I rebuild the library to use double precision (which
>         should work
>         > with the simulator according to the wiki), I got these
>         errors on
>         > attempting to start the simulator:
>         >
>         > ODE Message 2: inertia must be positive definite in
>         dMassCheck() File
>         > mass.cpp Line 53
>         >
>         > ODE Message 2: inertia must be positive definite in
>         dMassCheck() File
>         > mass.cpp Line 53
>         >
>         > ODE INTERNAL ERROR 1: assertion "dMassCheck(mass)" failed in
>         > dBodySetMass() [ode.cpp]
>         > Aborted
>         >
>         > I also tested the the demo with version 0.9 of ODE compiled
>         with both
>         > single and double precision. In both cases the simulator
>         would start
>         > normally, but then the robot would be torn apart by the
>         forces applied
>         > to it.
>         >
>         > Based on these results I have a couple of questions:
>         > -Should I be using the simulator with the single or double
>         precision
>         > version of ODE? Does it matter?
>         > -Have any changes been made to the simulator since last
>         summer that
>         > would cause commands that used to result in safe movements
>         for the
>         > robot to now fall outside allowable limits?
>         > -Has anyone experienced a similar problem with the
>         simulator? I'm
>         > assuming that the demo code for IHA should produce correct
>         motions,
>         > but I believe that it was last used on the physical robot
>         rather than
>         > the simulator. Are there changes that I need to make to
>         translate
>         > motion commands to the real iCub into simulator commands?
>         >
>         > Also, I'd like to follow up on the message to this list by
>         Baris Akgun
>         > on January 27th to say that I'm also experiencing what seems
>         to be a
>         > memory leak when using the simulator on the 64-bit version
>         of Ubuntu
>         > 8.10.
>         >
>         >
>         > Thanks,
>         > -Frank
>         >
>         >
>         >
>         >
>         >
>         >
>         >
>         >
>        
>        
>         >
>         ------------------------------------------------------------------------------
>         > Open Source Business Conference (OSBC), March 24-25, 2009,
>         San Francisco, CA
>         > -OSBC tackles the biggest issue in open source: Open
>         Sourcing the Enterprise
>         > -Strategies to boost innovation and cut costs with open
>         source participation
>         > -Receive a $600 discount off the registration fee with the
>         source code: SFAD
>         > http://p.sf.net/sfu/XcvMzF8H
>         > _______________________________________________
>         Robotcub-hackers mailing list
>         [hidden email]
>         https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
>        
>        
>


------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers
Reply | Threaded
Open this post in threaded view
|

Re: problems with iCub simulator, ODE, and memory leak

Tahir Bilal
In reply to this post by Frank Broz
Hi,
I don't have information about the exploding joint problem issue, but i may illuminate the causes of memory leak in the simulator.
In 'rendering.cpp'  there are DrawSphere and DrawCylinder functions which have calls to gluNewQuadric. Each time these functions are called a memory portion for a quadric object is allocated but is never given back.
There are two solutions. If these calls are moved to the setup_opengl function which is called only once the problem is resolved. Alternatively the space allocated can be given back by gluDeleteQuadric function by calling it at the end of both DrawSphere and DrawCylinder functions with the objects at issue as parameters.

Best,
Tahir

2009/2/24 Frank Broz <[hidden email]>
Baris,

Thanks for the information. Just to clarify, you're saying that you eliminated the exploding joint problem you were having on a 64-bit machine by using ODE 0.9 with single precision? I'm currently still having this problem with ODE 0.9 while using either single or double precision.

If you'd be willing to check out what modifications were made to your lab's version of the simulator to eliminate the memory leak and let me know what they were, I'd really appreciate it.

Thanks,
-Frank

On Mon, Feb 23, 2009 at 8:17 PM, Baris Akgun <[hidden email]> wrote:
Hello Frank,

I didn't receive any answer regarding to the memory leak issue. I am
using a modified version (by our lab) of the simulator which doesn't
have a memory leak. I didn't check what is different. If it comes to
that I will try to compare them. I am really surprised that no one else
has this issue.

As to exploding joints, we had similar issues while we were using the
hands. I think that is related to ODE, probably version 0.10. We are now
using 0.9 and it seems to be gone. Similarly I was only able to run the
simulator on a 64 bit machine with single precision. I get the same
errors when I try to use double precision.

I do not know much about ODE but maybe creating everything 10 times
bigger and heavier may solve the issues about exploding joints. They
seem to be happening because of floating point residuals and using
single precision might be amplifying the effect.

Is there anybody who uses the simulator with ubuntu 8.04 64bit and has
none of these problems? Maybe there is a problem with 8.10.

Cheers,
Baris

On Mon, 2009-02-23 at 15:53 +0000, Frank Broz wrote:
> Hello,
>
> I'm attempting to run the demo for the interaction history
> architecture application in the simulator, but I'm seeing some odd
> behavior. Basically, shortly after the demo starts, the forces being
> applied to the robot by the movement commands to the simulator tear it
> apart. Soon after that, the simulator fails with the message:
>
> ODE INTERNAL ERROR 1: assertion "bNormalizationResult" failed in
> _dNormalize4() [../../include/ode/odemath.h]
> Aborted
>
> I thought that something might be going wrong numerically in ODE
> (version 0.10.1) because I had it compiled to use single precision.
> When I rebuild the library to use double precision (which should work
> with the simulator according to the wiki), I got these errors on
> attempting to start the simulator:
>
> ODE Message 2: inertia must be positive definite in dMassCheck() File
> mass.cpp Line 53
>
> ODE Message 2: inertia must be positive definite in dMassCheck() File
> mass.cpp Line 53
>
> ODE INTERNAL ERROR 1: assertion "dMassCheck(mass)" failed in
> dBodySetMass() [ode.cpp]
> Aborted
>
> I also tested the the demo with version 0.9 of ODE compiled with both
> single and double precision. In both cases the simulator would start
> normally, but then the robot would be torn apart by the forces applied
> to it.
>
> Based on these results I have a couple of questions:
> -Should I be using the simulator with the single or double precision
> version of ODE? Does it matter?
> -Have any changes been made to the simulator since last summer that
> would cause commands that used to result in safe movements for the
> robot to now fall outside allowable limits?
> -Has anyone experienced a similar problem with the simulator? I'm
> assuming that the demo code for IHA should produce correct motions,
> but I believe that it was last used on the physical robot rather than
> the simulator. Are there changes that I need to make to translate
> motion commands to the real iCub into simulator commands?
>
> Also, I'd like to follow up on the message to this list by Baris Akgun
> on January 27th to say that I'm also experiencing what seems to be a
> memory leak when using the simulator on the 64-bit version of Ubuntu
> 8.10.
>
>
> Thanks,
> -Frank
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________ Robotcub-hackers mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/robotcub-hackers



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Robotcub-hackers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/robotcub-hackers