simspark-devel — Discussion about Spark development

Re: [simspark-devel] GyroRatePerceptor

[Hedayat V. <hed...@ai...>]

Hi,

Thanks for your answer. I've attached my patch against 
collisionperceptor and perceptorhandler.

I didn't send it before because it was just my first experiment with the 
server development and it doesn't
seems to be usable enough. First, it is not flexible enough as the 
collisionperceptor should be attached to
a collider object (e.g. BoxCollider) and (I think!) it is not possible 
to add a collisionperceptor in the agent's rsg file.
More importantly, there is no contact joint information!

I think that the ContactJointHandler (or a subclass of it) should be 
changed to provide enough information to
the touch sensor (if present) including the ID of contact joints. I'll 
go in this direction (creating a new touch
perceptor and modifying the ContactJointHandler class) if you are agree.

Good luck,
Hedayat


/*jbo...@un...*/ wrote on 05/15/2007 08:43:10 AM:
> Hi Hedayat,
>
> Hedayat Vatankhah wrote:
>> Well, I don't know what's going on but it seems that you have not 
>> received my previous emails or they have been missed among many 
>> others! Anyway, to summarize:
>> 1. A simple touch sensor is available already. Instead of deriving a 
>> class from the CollisionPerceptor, I decided to change it because I 
>> found it almost useless! (It adds non-printable objects to 
>> predList!). Currently, it provides a little more than what you've 
>> mentioned: it provides the names of all of the collidees with their 
>> corresponding contact points (which is at most 3 contact points when 
>> to surfaces are completely touching (ODE docs)). So, for example it 
>> says that the left foot is touching the ground at this/these point(s).
>
>
> Does anybody know what/if the CollisionPerceptor was/is used in its 
> current form? I think it's not used, so we might want to extend it in 
> the way Hedayat proposed above.
>
>>
>> 2. Then, I decided to add pressure information to the percept. I 
>> think that I should use joint feedback information of the contact 
>> joints. 
>
>
> Right.
>
>> So, the handler should create contact joints and then get the 
>> feedback information from them. Is it correct?!
>>
>
>
> That sounds correct.
>
>> 3.If needed, my sourceforge login is hedayat!
>>
>
>
> I created a developer  account for you for the sserver CVS a while ago 
> :-)
>
> Could you please send me your sources for the touch perceptor? I'd 
> like to take a look, if you don't mind.
>
> Thanks for your efforts,
> Joschka
>
>
>>
>> /*jbo...@un...*/ wrote on 05/02/2007 01:36:42 AM:
>>> Hi Hedayat,
>>>
>>> Hedayat Vatankhah wrote:
>>>
>>>> First of all, sorry for the long delay.
>>>>
>>>
>>> No problem, I know everybody is busy right now.
>>>
>>>> Anyway, I've written a simple gyro rate sensor. This sensor can be 
>>>> attached to some part of the robot to receive gyro rate information 
>>>> (for example, it can be attached to the agent's torso). I've used 
>>>> the angular velocity of Body which seems to be what is desired. 
>>>> Currently the output is like this: (gyro (<name> <xrate> <yrate> 
>>>> <zrate>))
>>>>
>>>
>>> Thanks a lot for the nice work! I submitted your code to the sserver 
>>> CVS (in the rcssserver3D module) already :-)
>>>
>>> About the touch sensor: I was thinking that this could be (maybe) 
>>> derived from the CollisionPerceptor (just overriding the Percept 
>>> method in a very simple way -- if there are collidees the add a 
>>> percept "1", if there are no collidees in the list, add a "0") and 
>>> then using it together with the PerceptorHandler (might have to 
>>> change a little, but not much I think). This is just a suggestion 
>>> though and there might be better ways (comments?).
>>>
>>> Thanks again for helping!
>>>
>>> Joschka
>

Re: [simspark-devel] GyroRatePerceptor

[Joschka B. <jbo...@un...>]

Hi Hedayat,

Hedayat Vatankhah wrote:
> Well, I don't know what's going on but it seems that you have not 
> received my previous emails or they have been missed among many 
> others! Anyway, to summarize:
> 1. A simple touch sensor is available already. Instead of deriving a 
> class from the CollisionPerceptor, I decided to change it because I 
> found it almost useless! (It adds non-printable objects to predList!). 
> Currently, it provides a little more than what you've mentioned: it 
> provides the names of all of the collidees with their corresponding 
> contact points (which is at most 3 contact points when to surfaces are 
> completely touching (ODE docs)). So, for example it says that the left 
> foot is touching the ground at this/these point(s).


Does anybody know what/if the CollisionPerceptor was/is used in its 
current form? I think it's not used, so we might want to extend it in 
the way Hedayat proposed above.

>
> 2. Then, I decided to add pressure information to the percept. I think 
> that I should use joint feedback information of the contact joints. 


Right.

> So, the handler should create contact joints and then get the feedback 
> information from them. Is it correct?!
>


That sounds correct.

> 3.If needed, my sourceforge login is hedayat!
>


I created a developer  account for you for the sserver CVS a while ago :-)

Could you please send me your sources for the touch perceptor? I'd like 
to take a look, if you don't mind.

Thanks for your efforts,
Joschka


>
> /*jbo...@un...*/ wrote on 05/02/2007 01:36:42 AM:
>> Hi Hedayat,
>>
>> Hedayat Vatankhah wrote:
>>
>>> First of all, sorry for the long delay.
>>>
>>
>> No problem, I know everybody is busy right now.
>>
>>> Anyway, I've written a simple gyro rate sensor. This sensor can be 
>>> attached to some part of the robot to receive gyro rate information 
>>> (for example, it can be attached to the agent's torso). I've used 
>>> the angular velocity of Body which seems to be what is desired. 
>>> Currently the output is like this: (gyro (<name> <xrate> <yrate> 
>>> <zrate>))
>>>
>>
>> Thanks a lot for the nice work! I submitted your code to the sserver 
>> CVS (in the rcssserver3D module) already :-)
>>
>> About the touch sensor: I was thinking that this could be (maybe) 
>> derived from the CollisionPerceptor (just overriding the Percept 
>> method in a very simple way -- if there are collidees the add a 
>> percept "1", if there are no collidees in the list, add a "0") and 
>> then using it together with the PerceptorHandler (might have to 
>> change a little, but not much I think). This is just a suggestion 
>> though and there might be better ways (comments?).
>>
>> Thanks again for helping!
>>
>> Joschka

Re: [simspark-devel] Timer Test Report

[Oliver O. <Oli...@ne...>]

Hi,

On 01/05/2007, at 8:02 PM, Joschka Boedecker wrote:

> * For submitting the code to the CVS, we need a test to check for  
> the boost_thread-mt library. In some distributions, we need to use  
> "-lboost_thread-mt", in others "-lboost_thread-gcc-mt" for linking.
> @Oliver: do you think you could do the Makefile magic for that? :-)

Finally I've looked into it. The configure script now checks for this  
lib (as boost_thread, boost_thread-mt, and boost_thread-gcc-mt). It's  
somehow interesting that just the boost guys can't come up with one  
standard way of calling the library.

The check creates a Makefile (Meta)variable @BOOST_THREADS_LIB@. If  
you put it in a Makefile.am somewhere, it will be replaced by the  
name of the boost thread library that was found (first) when the  
Makefile gets created.
I haven't done this, because I haven't checked where you want to use  
it. If you need it in, say oxygen, do something like this to the  
corresponding Makefile.am:

change:
liboxygen_debug_la_LIBADD = -lode ${spades_libs}
to
liboxygen_debug_la_LIBADD = -lode ${spades_libs} -l@BOOST_THREADS_LIB@

(you have to do that 2x in the Makefile.am, one time for the debug  
version of the lib, and one time for the normal version).

If you cvs up now, you need to booststrap the configure file again.  
If there are problems (or more different versions of the thread lib),  
let me know.
I have tested the script on one linux machine (@uni-koblenz.de), but  
I haven't checked what happens if there's no boost thread library.  
What should the check do in this case? Stop configuring?

cheers
Oliver

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science

Re: [simspark-devel] Timer Test Report

[Jan M. <mu...@un...>]

|On Thu, 03 May 2007 19:47:46 +0200, Markus Rollmann <rol...@un...> said:

> Jan Murray wrote:
> [...]
>> I tried without success. :-(
>> I get an "undefined reference to `oxygen::ODEObject::GetSpaceID()'" 
>> during make in the "app/*" subdirs.

> There were two errors: The GetSpaceID() declaration in odeobject.h was 
> obsolote but still used from collider.cpp. I changed that.


> Does it at least compile now ? ;)

Almost. ;)  I had to change Collider::OnLink() a little:

I added this at the beginning:

>     weak_ptr<Node> parent = GetParent();
>     if (
>         (mODEGeom == 0) ||
>         (parent.expired())
>         )
>         {
>             return;
>         }

and removed this as it's subsumed by the above test:

>    if (mODEGeom == 0)
>        {
>            return;
>        }


Now it seems to work. Adding the wrapper to the soccerbot.rsg worked
out of the box. :-) Now I have to check if it really gets faster. 


Bye,
 Jan

Re: [simspark-devel] Timer Test Report

[Markus R. <rol...@un...>]

Jan Murray wrote:
[...]
> I tried without success. :-(
> I get an "undefined reference to `oxygen::ODEObject::GetSpaceID()'" 
> during make in the "app/*" subdirs.

There were two errors: The GetSpaceID() declaration in odeobject.h was 
obsolote but still used from collider.cpp. I changed that.

Does it at least compile now ? ;)

> It looks like GetSpaceID() is declared (in odeobject.h), but not defined 
> (The same is true in simspark/spark.)

I'll check that.

> BTW, GetParentSpaceID() always returns 0. Is this correct?

only Collider and Space objects have parent spaces (bodies don't). The 
common base class of both is ODEObject. Therefore the base class returns 
0, collider and space both use the dGeomGetSpace function (they 
implement identical functions).

Maybe we could add a common base class to Space and Collider below 
ODEObject (OdeGeomObject?) to merge common methods between Space and 
Collider classes.

Cheers,
Markus

Re: [simspark-devel] Timer Test Report

[Jan M. <mu...@un...>]

Hi Markus,

Markus Rollmann wrote:

> I commited the changes to the ODE_SUBSPACES branch in the rcssserver3d 
> CVS. They are currently untested (maybe they don't even compile), as I 
> need to install a linux first ;-) So maybe someone of you could test 
> these changes.

I tried without success. :-(
I get an "undefined reference to `oxygen::ODEObject::GetSpaceID()'" 
during make in the "app/*" subdirs.

It looks like GetSpaceID() is declared (in odeobject.h), but not defined 
(The same is true in simspark/spark.)

BTW, GetParentSpaceID() always returns 0. Is this correct?

Bye,
  Jan

Re: [simspark-devel] Timer Test Report

[Markus R. <rol...@un...>]

Hi,

Markus Rollmann wrote:
[...]
> Ok. I'll see what I can do. It think I'll put the 'space' changes first 
> into a separate test branch where in order to allow for some test phase.

I commited the changes to the ODE_SUBSPACES branch in the rcssserver3d 
CVS. They are currently untested (maybe they don't even compile), as I 
need to install a linux first ;-) So maybe someone of you could test 
these changes.

As I said, the setup should work withouth problems, just insert an 
enclosing (node Space ... ) expression as the outermost expression to 
the soccerbot.rsg file and multiple robot instances may work a bit faster...

cheers,
Markus

Re: [simspark-devel] Timer Test Report

[Yuan X. <xuy...@gm...>]

Hi all,

Sorry, I missed the screen shots of monitorspark,
they are placed here:
http://picasaweb.google.com/xuyuan.cn/C75/photo#5059995259975158530

http://picasaweb.google.com/xuyuan.cn/C75/photo#5059995259975158546

2007/5/3, Yuan Xu <xuy...@gm...>:
> Hi Joschka and all,
>
>
> > I have to help out at the JapanOpen 2007 in the next days (until 05/05),
> > but I would be glad if somebody could test the current setup, if
> > possible, also using Yuan's timer (since the rendering can now be done
> > on an external machine).
>
> I have checked out the code from the cvs.
> The server and monitor can be started,
> but I got some problems:
> * monitorspark:
>   First, some times it seems missing the data from the server,
>   the typical screen shots are [] and []. The body are fall apart...
>   Second, I do not know how to load the sparkmonitor.log,
>   I set $recordLogfile to true,
>   and tried run "./momitorspark --logfile sparkmonitor.log", but it
> does not work.
> * agentspark:
>   First, the agentspark does not terminate when the server is closed,
>   and even Ctrl-C can not terminate it. I have to kill it every time.
>   Second, it may abort with output "too long message; aborting",
>   but it does not occur often.
>
>
> > * You noticed that only one CPU is used and the others remain idle even
> > though we use different threads that should be able to execute in
> > parallel without blocking themselves all the time; do you have an idea
> > why this is the case?
> The reason is that the physic thread can not execute parallel with
> other threads.
> There is only one sense in the program,
> when the physic thread running, other thread have to wait.
>
> Hope to get comments soon.
>
> --
> Best wishes!
>
> Xu Yuan
> School of Automation
> Southeast University, Nanjing, China
>
> mail:   xuy...@gm...
>           xy...@ya...
> web:   http://xuyuan.cn.googlepages.com
> --------------------------------------------------
>


-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

Re: [simspark-devel] Timer Test Report

[Yuan X. <xuy...@gm...>]

Hi Joschka and all,


> I have to help out at the JapanOpen 2007 in the next days (until 05/05),
> but I would be glad if somebody could test the current setup, if
> possible, also using Yuan's timer (since the rendering can now be done
> on an external machine).

I have checked out the code from the cvs.
The server and monitor can be started,
but I got some problems:
* monitorspark:
  First, some times it seems missing the data from the server,
  the typical screen shots are [] and []. The body are fall apart...
  Second, I do not know how to load the sparkmonitor.log,
  I set $recordLogfile to true,
  and tried run "./momitorspark --logfile sparkmonitor.log", but it
does not work.
* agentspark:
  First, the agentspark does not terminate when the server is closed,
  and even Ctrl-C can not terminate it. I have to kill it every time.
  Second, it may abort with output "too long message; aborting",
  but it does not occur often.


> * You noticed that only one CPU is used and the others remain idle even
> though we use different threads that should be able to execute in
> parallel without blocking themselves all the time; do you have an idea
> why this is the case?
The reason is that the physic thread can not execute parallel with
other threads.
There is only one sense in the program,
when the physic thread running, other thread have to wait.

Hope to get comments soon.

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

Re: [simspark-devel] Timer Test Report

[Markus R. <rol...@un...>]

Hi,

Joschka Boedecker wrote:
>> Markus Rollmann wrote:

>> I'm not sure if it's necessary to copy this whole machinery to the 
>> rcsssrver3d CVS, maybe some special handling for agent disconnect will 
>> suffice?
>>   
> 
> Yes, maybe you're right and we can handle this in an easy way somehow 
> for the agent disconnects. I'll take a look after I'm back from 
> JapanOpen, but if anybody else wants to have a look in the meantime -- 
> feel free ;-)

Ok. I'll see what I can do. It think I'll put the 'space' changes first 
into a separate test branch where in order to allow for some test phase.

About the deconstruction problem we'll see after that...

Cheers,
Markus

Re: [simspark-devel] Timer Test Report

[Oliver O. <fr...@ro...>]

Hi,

On 01/05/2007, at 8:02 PM, Joschka Boedecker wrote:

> * For submitting the code to the CVS, we need a test to check for the
> boost_thread-mt library. In some distributions, we need to use
> "-lboost_thread-mt", in others "-lboost_thread-gcc-mt" for linking.
> @Oliver: do you think you could do the Makefile magic for that? :-)

yep, I'll go for it.

cheers
Oliver

-- 
Oliver Obst          ES208   form follows function (Louis Sullivan).
Fon: +61 2 492 16175                          http://oliver.obst.eu/
Uni Newcastle  School of Electrical Engineering and Computer Science

Re: [simspark-devel] GyroRatePerceptor

[Hedayat V. <hed...@ai...>]

Hi,
Thanks!

> About the touch sensor: I was thinking that this could be (maybe) 
> derived from the CollisionPerceptor (just overriding the Percept 
> method in a very simple way -- if there are collidees the add a 
> percept "1", if there are no collidees in the list, add a "0") and 
> then using it together with the PerceptorHandler (might have to change 
> a little, but not much I think). This is just a suggestion though and 
> there might be better ways (comments?). 
Well, I don't know what's going on but it seems that you have not 
received my previous emails or they have been missed among many others! 
Anyway, to summarize:
1. A simple touch sensor is available already. Instead of deriving a 
class from the CollisionPerceptor, I decided to change it because I 
found it almost useless! (It adds non-printable objects to predList!). 
Currently, it provides a little more than what you've mentioned: it 
provides the names of all of the collidees with their corresponding 
contact points (which is at most 3 contact points when to surfaces are 
completely touching (ODE docs)). So, for example it says that the left 
foot is touching the ground at this/these point(s).

2. Then, I decided to add pressure information to the percept. I think 
that I should use joint feedback information of the contact joints. So, 
the handler should create contact joints and then get the feedback 
information from them. Is it correct?!

3.If needed, my sourceforge login is hedayat!

Thanks,
Bye


/*jbo...@un...*/ wrote on 05/02/2007 01:36:42 AM:
> Hi Hedayat,
>
> Hedayat Vatankhah wrote:
>
>> First of all, sorry for the long delay.
>>
>
> No problem, I know everybody is busy right now.
>
>> Anyway, I've written a simple gyro rate sensor. This sensor can be 
>> attached to some part of the robot to receive gyro rate information 
>> (for example, it can be attached to the agent's torso). I've used the 
>> angular velocity of Body which seems to be what is desired. Currently 
>> the output is like this: (gyro (<name> <xrate> <yrate> <zrate>))
>>
>
> Thanks a lot for the nice work! I submitted your code to the sserver 
> CVS (in the rcssserver3D module) already :-)
>
> About the touch sensor: I was thinking that this could be (maybe) 
> derived from the CollisionPerceptor (just overriding the Percept 
> method in a very simple way -- if there are collidees the add a 
> percept "1", if there are no collidees in the list, add a "0") and 
> then using it together with the PerceptorHandler (might have to change 
> a little, but not much I think). This is just a suggestion though and 
> there might be better ways (comments?).
>
> Thanks again for helping!
>
> Joschka

Re: [simspark-devel] rcssserver3d - BeamEffector patch

[Joschka B. <jbo...@un...>]

Hi Amin,

please excuse me for not writing for a long time :-( I have some 
comments below.

Amin Habibi Shahri wrote:
> Hi Joschka,
>  
> I have a patch for beameffector, but I'm not sure that this method is 
> good enough! By beam command I will move all bodies under the agent 
> aspect, and I works fine.
> I have attached the patch files. Please take a look at them and inform me.

It is great for now! For later, a more generic solution should be found, 
but your code helps a lot. Thank you :-)

>  
> >One idea would be now to model the agents in a hierarchical >structure.
> >Currently, the hierarchy is only achieved through the joints, but >not
> >through the SceneGraph structure.
>
> >I already started to make some tests with this, but I realized that
> >there are some strange problems with the rendering when agents >are
> >modeled as hierarchical structure. Some of the bodies seem to >be in the
> >right position with their physical (ODE) bodies, but they are >rendered
> >at the origin (0,0,0) :-(

>  Whould you please send me your code? I want to know more about your 
> hierarchical structure.

I attached a very simple test that puts three boxes on top of each 
other. Initially, this should work fine since the boxes are setup 
"manually" without any ODE body. If you use the (commented out) import 
command, it will create three boxes with colliders and ODE bodies and 
then you'll see the strange effects that all but the last of the meshes 
in the hierarchy will be stuck in the origin.

It would be great if you could help us with this problem.

Thanks a lot again,
Joschka

Re: [simspark-devel] Timer Test Report

[Joschka B. <jbo...@un...>]

Hi Markus,
> Hi,
>
> Markus Rollmann wrote:
>   
>> Joschka Boedecker wrote:
>>     
>>> * It seems evident that we have to optimize the physics somehow. We 
>>> should at least get to the point where 3 vs. 3 robots can be reliably 
>>> simulated, I think. Without having done any profiling at all, my 
>>> suggestion would be to take a look at possibilities to optimize the 
>>> collision detection in the ODE part. One possibility is to use separate 
>>> collision spaces for each robot. From the ODE Wiki [1]:
>>>       
>> [...]
>>     
>
> [...]
>   
>> I think there are only very few changes necessary:
>>
>> - It is already possible to create the additional 'Space' nodes in the 
>> .rsg files. So putting each robot into it's own collision space would be 
>> a matter of enclosing the current soccerbot.rsg into an additional (node 
>> space ) expression or using an external wrapper .rsg that imports the 
>> soccerbot.
>>
>> - The problem is registering the ODE geoms to the proper space. This is 
>> done in the OnLink() method of the collider class. It calls GetSpaceId() 
>> wich in turn calls OdeObject::GetSpace(). Currently the global Space 
>> object below the SceneServer is returned.
>>
>> This behavior could be changed to walk the parent chain of the ODEObject 
>> in order to find the closest Space parent. If this fails we revert to 
>> the current behavior and return the default space. Therefore existing 
>> .rsg files will still work as expected.
>>
>> - The actual collision logic needs very little change. The wiki entry 
>> [1], that Joschka linked to provides a code snipped that we could nearly 
>> copy 1:1 into our code base.
>>
>> I'll try to implement these changes in the simspark CVS.
>>     
>
> The changes are now part of the simspark CVS trunk. 

Wow, you are fast! Thanks a lot :-D

> I did test the 
> changes with rsgedit and the jointtest.rsg demo, where I placed each 
> hinge2thing.rsg, sliderthing.rsg and universalthing.rsg in a separate 
> space each- and it worked fine ;)
>
>   

Nice :-)

> The problem was not in the setup of the different collision spaces but 
> in the deconstruction of them.
>
> The problem is that all ODE objects should be deconstructed in the 
> proper order. [...]
>
> I'm not sure if it's necessary to copy this whole machinery to the 
> rcsssrver3d CVS, maybe some special handling for agent disconnect will 
> suffice?
>   

Yes, maybe you're right and we can handle this in an easy way somehow 
for the agent disconnects. I'll take a look after I'm back from 
JapanOpen, but if anybody else wants to have a look in the meantime -- 
feel free ;-)

Cheers,
Joschka

Re: [simspark-devel] GyroRatePerceptor

[Joschka B. <jbo...@un...>]

Hi Hedayat,

Hedayat Vatankhah wrote:

> First of all, sorry for the long delay.
>

No problem, I know everybody is busy right now.

> Anyway, I've written a simple gyro rate sensor. This sensor can be 
> attached to some part of the robot to receive gyro rate information 
> (for example, it can be attached to the agent's torso). I've used the 
> angular velocity of Body which seems to be what is desired. Currently 
> the output is like this: (gyro (<name> <xrate> <yrate> <zrate>))
>

Thanks a lot for the nice work! I submitted your code to the sserver CVS 
(in the rcssserver3D module) already :-)

About the touch sensor: I was thinking that this could be (maybe) 
derived from the CollisionPerceptor (just overriding the Percept method 
in a very simple way -- if there are collidees the add a percept "1", if 
there are no collidees in the list, add a "0") and then using it 
together with the PerceptorHandler (might have to change a little, but 
not much I think). This is just a suggestion though and there might be 
better ways (comments?).

Thanks again for helping!

Joschka

[simspark-devel] [Fwd: GyroRatePerceptor]

[Hedayat V. <hed...@ai...>]

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body dir="ltr" bgcolor="#ffffff" text="#000000">
<p style="margin-bottom: 0cm; margin-top: 0pt;">Hi,</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">I'm not sure that this
email is relevant here or not! At first I thought that this could not
be a part of simspark, but I'm not sure now!<br>
</p>
<br>
-------- Original Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"   cellspacing="0">
  <tbody>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Subject: </th>
      <td>GyroRatePerceptor</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">Date: </th>
      <td>Fri, 27 Apr 2007 15:57:52 +0330</td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">From: </th>
      <td>Hedayat Vatankhah <a class="moz-txt-link-rfc2396E" href="mailto:hed...@ai...">&lt;hed...@ai...&gt;</a></td>
    </tr>
    <tr>
      <th align="right" nowrap="nowrap" valign="baseline">To: </th>
      <td>Joschka Boedecker <a class="moz-txt-link-rfc2396E" href="mailto:jbo...@un...">&lt;jbo...@un...&gt;</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><small><font size="+1"><small>Hi,</small></font></small></p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">First of all, sorry for
the long delay. Anyway, I've written a simple gyro rate sensor. This
sensor can be attached to some part of the robot to receive gyro rate
information (for example, it can be attached to the agent's torso).
I've used the angular velocity of Body which seems to be what is
desired. Currently the output is like this: (gyro (&lt;name&gt;
&lt;xrate&gt; &lt;yrate&gt; &lt;zrate&gt;))</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">I've put it under the
plugins folder of my rcssserver3d source folder. </p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Also, I've fixed some
Makefile.am files which are necessary to build the server in a custom
directory rather than the main source directory (personally I prefer to
separate source and build directories). (It mostly needs only the
proper usage of top_srcdir &amp; top_builddir variables). I could send
a patch for you if you like.</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Bye,</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Hedayat</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">(Finally, if aim fails,
please CC your messages (if any) to <a class="moz-txt-link-abbreviated"   href="mailto:hed...@gm...">hed...@gm...</a>)</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
</body>
</html>

Re: [simspark-devel] Timer Test Report

[Markus R. <rol...@un...>]

Hi,

Markus Rollmann wrote:
> Joschka Boedecker wrote:
>> * It seems evident that we have to optimize the physics somehow. We 
>> should at least get to the point where 3 vs. 3 robots can be reliably 
>> simulated, I think. Without having done any profiling at all, my 
>> suggestion would be to take a look at possibilities to optimize the 
>> collision detection in the ODE part. One possibility is to use separate 
>> collision spaces for each robot. From the ODE Wiki [1]:
> [...]

[...]
> I think there are only very few changes necessary:
> 
> - It is already possible to create the additional 'Space' nodes in the 
> .rsg files. So putting each robot into it's own collision space would be 
> a matter of enclosing the current soccerbot.rsg into an additional (node 
> space ) expression or using an external wrapper .rsg that imports the 
> soccerbot.
> 
> - The problem is registering the ODE geoms to the proper space. This is 
> done in the OnLink() method of the collider class. It calls GetSpaceId() 
> wich in turn calls OdeObject::GetSpace(). Currently the global Space 
> object below the SceneServer is returned.
> 
> This behavior could be changed to walk the parent chain of the ODEObject 
> in order to find the closest Space parent. If this fails we revert to 
> the current behavior and return the default space. Therefore existing 
> .rsg files will still work as expected.
> 
> - The actual collision logic needs very little change. The wiki entry 
> [1], that Joschka linked to provides a code snipped that we could nearly 
> copy 1:1 into our code base.
> 
> I'll try to implement these changes in the simspark CVS.

The changes are now part of the simspark CVS trunk. I did test the 
changes with rsgedit and the jointtest.rsg demo, where I placed each 
hinge2thing.rsg, sliderthing.rsg and universalthing.rsg in a separate 
space each- and it worked fine ;)

The problem was not in the setup of the different collision spaces but 
in the deconstruction of them.

The problem is that all ODE objects should be deconstructed in the 
proper order. This means that joints should be removed before the 
attached bodies are destroyed, and geoms before the spaces they are 
contained in etc. If they are destroyed in the order in which they are 
traversed in the scene graph these conditions do not hold, which may 
lead to ODE segfaults.

The problem will occcur whenever an agent disconnects from the server. 
In this case it's personal ODE sub spaces have to be destroyed and 
removed from the global space.

In the simspark CVS I'm facing this problem when the user reloads the 
entire scene from rsgedit. For this case I added a virtual 
DestroyODEObject() dtor to each ODEObject that is called from World 
nodes OnUnlink() method.

I'm not sure if it's necessary to copy this whole machinery to the 
rcsssrver3d CVS, maybe some special handling for agent disconnect will 
suffice?

regards,
Markus

Re: [simspark-devel] Timer Test Report

[Markus R. <rol...@un...>]

Hi all,

Joschka Boedecker wrote:
> * It seems evident that we have to optimize the physics somehow. We 
> should at least get to the point where 3 vs. 3 robots can be reliably 
> simulated, I think. Without having done any profiling at all, my 
> suggestion would be to take a look at possibilities to optimize the 
> collision detection in the ODE part. One possibility is to use separate 
> collision spaces for each robot. From the ODE Wiki [1]:
[...]

> Anybody know any volunteers (we might ask on the server-three-d ML)?

I've been thinking about the collision issue lately and I think I'll 
volunteer ;)

I think there are only very few changes necessary:

- It is already possible to create the additional 'Space' nodes in the 
.rsg files. So putting each robot into it's own collision space would be 
a matter of enclosing the current soccerbot.rsg into an additional (node 
space ) expression or using an external wrapper .rsg that imports the 
soccerbot.

- The problem is registering the ODE geoms to the proper space. This is 
done in the OnLink() method of the collider class. It calls GetSpaceId() 
wich in turn calls OdeObject::GetSpace(). Currently the global Space 
object below the SceneServer is returned.

This behavior could be changed to walk the parent chain of the ODEObject 
in order to find the closest Space parent. If this fails we revert to 
the current behavior and return the default space. Therefore existing 
.rsg files will still work as expected.

- The actual collision logic needs very little change. The wiki entry 
[1], that Joschka linked to provides a code snipped that we could nearly 
copy 1:1 into our code base.

I'll try to implement these changes in the simspark CVS.

cheers,
Markus

[1]
http://opende.sourceforge.net/wiki/index.php/Manual_(Collision_Detection)

Re: [simspark-devel] Timer Test Report

[Joschka B. <jbo...@un...>]

Hi Yuan,

Yuan Xu wrote:
> After several experiments, we got the conclusions below:
> * If the load of server is light, the timer works well.
> * The rendering influences the timer greatly.
> * The 10 humanoid robots physics simulation is too complex,
>  the simulation time is longer than the real time,
>  so that the timer can not work properly.
>
> The full report is at http://xuyuan.cn.googlepages.com/test-timer-rc1.pdf
>

first of all, thank you very much for the detailed experiments and the 
report! I'm sorry I couldn't reply earlier :-(

I couldn't really test the timer myself properly yet because of problems 
in the external monitor. I recently worked on that and submitted some 
updates to the server and the external monitor (monitorspark) to the 
CVS. The rendering is now by default disabled in the simspark (I added 
the TimerSDL in the initialization of the InputServer). The external 
monitor now gets an update every cycle, otherwise I got very strange 
rendering errors.

I have to help out at the JapanOpen 2007 in the next days (until 05/05), 
but I would be glad if somebody could test the current setup, if 
possible, also using Yuan's timer (since the rendering can now be done 
on an external machine).

Concerning the timer itself:

* For submitting the code to the CVS, we need a test to check for the 
boost_thread-mt library. In some distributions, we need to use 
"-lboost_thread-mt", in others "-lboost_thread-gcc-mt" for linking.
@Oliver: do you think you could do the Makefile magic for that? :-)

* You noticed that only one CPU is used and the others remain idle even 
though we use different threads that should be able to execute in 
parallel without blocking themselves all the time; do you have an idea 
why this is the case?

* It seems evident that we have to optimize the physics somehow. We 
should at least get to the point where 3 vs. 3 robots can be reliably 
simulated, I think. Without having done any profiling at all, my 
suggestion would be to take a look at possibilities to optimize the 
collision detection in the ODE part. One possibility is to use separate 
collision spaces for each robot. From the ODE Wiki [1]:

"Spaces may contain other spaces. These sub-spaces will typically 
represent a collection of geoms (or other spaces) that are located near 
each other. This is useful for gaining extra collision performance by 
dividing the collision world into hierarchies. Here is an example of 
where this is useful:

Suppose you have two cars driving over some terrain. Each car is made up 
of many geoms. If all these geoms were inserted into the same space, the 
collision computation time between the two cars would always be 
proportional to the total number of geoms (or even to the square of this 
number, depending on which space type is used).

To speed up collision a separate space is created to represent each car. 
The car geoms are inserted into the car-spaces, and the car-spaces are 
inserted into the top level space. At each time step dSpaceCollide is 
called for the top level space. This will do a single intersection test 
between the car-spaces (actually between their bounding boxes) and call 
the callback if they touch. The callback can then test the geoms in the 
car-spaces against each other using dSpaceCollide2. If the cars are not 
near each other then the callback is not called and no time is wasted 
performing unnecessary tests."

Anybody know any volunteers (we might ask on the server-three-d ML)?

Cheers,
Joschka

[1] 
http://opende.sourceforge.net/wiki/index.php/Manual_(Collision_Detection)

[simspark-devel] Timer Test Report

[Yuan X. <xuy...@gm...>]

Hi all,

After several experiments, we got the conclusions below:
* If the load of server is light, the timer works well.
* The rendering influences the timer greatly.
* The 10 humanoid robots physics simulation is too complex,
  the simulation time is longer than the real time,
  so that the timer can not work properly.

The full report is at http://xuyuan.cn.googlepages.com/test-timer-rc1.pdf

In the report, the experiment configurations are described firstly,
then the experiment results are given,
followed by the conclusion.

Any comment is welcome!

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

[simspark-devel] RsgEdit Updated

[Markus R. <rol...@un...>]

Hi all,

i just uploaded a new version of rsgedit (my SimSpark GUI project). 
Fixes and new features in this version:

- RsgEdit now properly terminates agent processes that are still running 
when the application window is closed

- The mouse is captured when the camera angle is adjusted and does not 
block at the OpenGL window boundary

- The base plane collider of the demo arena is fixed and the demo robot 
no longer stands half way in the ground.

- Some lights were added to the demo arena that enable basic shading of 
the arena and the robot

- Camera movement is now possible, when the simulation is paused

- The simulation state, i.e. 'paused' or 'running' and the passed 
simulation time is shown in the toolbar

- RsgEdit now supports object picking with the mouse. After a double 
click in the OpenGL window or the scene tree on the left side the 
corresponding object is highlighted, i.e. drawn in a purple color. The 
extents of invisible objects (e.g. Body or Collider objects) are drawn 
with three axis aligned lines.

Please find the binary at the usual place [1], along with the necessary 
Microsoft VC runtime [2]. You can find a short howto for rsgedit in my 
last eMail [3]

regards,
Markus

[1]
http://www.uni-koblenz.de/~rollmark/setup.exe

[2]
http://www.uni-koblenz.de/~rollmark/vcredist_x86.exe

[3] 
http://sourceforge.net/mailarchive/message.php?msg_id=45E1ECCA.3020209%40uni-koblenz.de

[simspark-devel] timer rc1

[Yuan X. <xuy...@gm...>]

Hi all,

At last, I finished the first version of timer. The main work I did are:
 * Spread the Run() function to different threads (One thread per
SimControlNode)
 * Schedule the threads by interval time of  SimControlNodes
Please see http://xuyuan.cn.googlepages.com/timer-rc1.pdf.tar.gz
for more information .

My work are based on rcssserver3d-0.5.3.
The patch I attached is suited to rcssserver3d-0.5.3.
And you can get the whole package from
http://xuyuan.cn.googlepages.com/rcssserver3d-0.5.3-timer-rc1.tar.gz

Although I have tested the code in 4 differnet computers, but I am not
sure it is bug-free.
And it can not works in old version Mesa.
If you have any problem while using the timer, please tell me. And any
comment is welcome.


I also list TODO below:

* In order to link the boost-thread library, I added -lboost_thread-mt
to LDADD in Makefile.am.
This is not a good solution, it can not find the library when the
library named -lboost_thread-gcc-mt,
and there are some warning while running configure. but I do not know
how to solve it.

* I am not sure the OpenGL library is thread safe.
Because it can not work with Mesa-6.4.1, it can work with Mesa-6.5.21
and ATI fglrx 8.31.5 .
I checked the ChanegeLog of Mesa, there are some bug-fixes of thread
safe in Mesa-6.5

* Is the XThreadInit() needed? Note that the all OpenGL function are
called in one thread.

* I write some ugly code to make the AgentControl loop in the main
thread, hwo can the Ruby be called in new thread?

* I think we should implement the sense and act latency in the next step, right?



-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

[simspark-devel] timer rc1

[Yuan X. <xuy...@gm...>]

Hi all,

At last, I finished the first version of timer. The main work I did are:
 * Spread the Run() function to different threads (One thread per
SimControlNode)
 * Schedule the threads by interval time of  SimControlNodes
More information see the pdf I attached, please.

My work are based on rcssserver3d-0.5.3.
The patch I attached is suited to rcssserver3d-0.5.3.
And you can get the whole package from
http://xuyuan.cn.googlepages.com/rcssserver3d-0.5.3-timer-rc1.tar.gz

Although I have tested the code in 4 differnet computers, but I am not
sure it is bug-free.
And it can not works in old version Mesa.
If you have any problem while using the timer, please tell me. And any
comment is welcome.


I also list TODO below:

* In order to link the boost-thread library, I added -lboost_thread-mt
to LDADD in Makefile.am.
This is not a good solution, it can not find the library when the
library named -lboost_thread-gcc-mt,
and there are some warning while running configure. but I do not know
how to solve it.

* I am not sure the OpenGL library is thread safe.
Because it can not work with Mesa-6.4.1, it can work with Mesa-6.5.21
and ATI fglrx 8.31.5 .
I checked the ChanegeLog of Mesa, there are some bug-fixes of thread
safe in Mesa-6.5

* Is the XThreadInit() needed? Note that the all OpenGL function are
called in one thread.

* I write some ugly code to make the AgentControl loop in the main
thread, hwo can the Ruby be called in new thread?

* I think we should implement the sense and act latency in the next step, right?


-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

Re: [simspark-devel] discussion

[Yuan X. <xuy...@gm...>]

Hi,

> You could use a recursive mutex to avoid this. This kind of mutex allows
>   the owning thread to lock it repeatedly without deadlocking. The boost
> library contains a boost/thread/recursive_mutex.hpp file for this purpose.

I have tried the recursive mutex,
but the ruby still can not be called in the new thread ;-(
I'll do more try.



-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------

Re: [simspark-devel] discussion

[Markus R. <rol...@un...>]

Hi,

Yuan Xu wrote:
> Firstly, I create a global mutex that all ruby functions should call 
> before doing anything. But it will cause dead lock, because there are
> recursive calls between Ruby and C++.
[...]

You could use a recursive mutex to avoid this. This kind of mutex allows 
  the owning thread to lock it repeatedly without deadlocking. The boost 
library contains a boost/thread/recursive_mutex.hpp file for this purpose.

regards.
Markus