simspark-devel — Discussion about Spark development

Re: [simspark-devel] ODE Composite bodies

[Joschka B. <jos...@am...>]

Hi Sander,

On Feb 7, 2008, at 7:37 AM, Sander van Dijk wrote:

> I've got it to works now. In the attached archive is a working patch  
> plus a soccerbot that has a composite body torso (with a somewhat  
> skewed mass distribution). It took some time to get translated and  
> rotated geometries in the right place, but that seems fine now. As  
> long as a Collider node uses the new setLocalPosition to set the  
> position relative to its body's center.

Great! Thanks a lot for the patch and the model.

> As you also pointed out, the mass distribution of composite bodies  
> still should be sorted out.

Right.

> Now for the bad news: the 'thigh slapping' LCP erors that I  
> mentioned in my first email still happen.. It seems it weren't the  
> joint stops causing the excessive forces after all. My next bet is  
> that it is caused by the sharp edge of the hand hitting the angled  
> part of the torso's lower part too hard, which I think is only  
> preventable by reducing motor force.

Sorry, I completely forgot *d'oh*! The hands were changed from the 055  
model to the 056 model, too. They also use fixed joints in the 056  
model to glue together the 3 boxes that make up the hand. These are  
most likely what causes the trouble now. Could you please check this?

> PS when I run the simulation with this patch, ball and players don't  
> collide with the goals anymore. This is due to collider.cpp in the  
> simspark cvs where the use of a default collision handler is  
> commented out.

OK, so can we solve this using the RSG files then?

Cheers,
Joschka

Re: [simspark-devel] ODE Composite bodies

[Joschka B. <jos...@am...>]

Hi Sander,

On Feb 6, 2008, at 11:22 PM, Sander van Dijk wrote:

> > I also changed Collider::OnLink to encapsulate colliders that have
> > a transform collider as their parent into it.
>
> I'm not sure if I understand this. Do you mean, you changed the code
> of the Collider class so that it does what Markus described above for
> the code of the Collider class in the simspark repository (associate
> with a TransformCollider instance parent)?
>
> Oops, I didn't look into the SimSpark CVS well enough and missed  
> parts of Markus' code. So now it turns out I mostly duplicated some  
> stuff he already did :-) I will go further with his implementation,  
> mine gives segfaults in ruby at the moment. Still was a good  
> exercise in understanding the simulation server, though.
>

BTW, I didn't mean to criticize, just asked for my understanding ;-)

>
> > The new files and a patch with this code are attached.
> >
>
> Great, thanks a bunch! I really appreciate your work on this :-)
> Seems like we can finally get rid of the hacks used in the Soccerbot
> RSG file and have better robot models (with complex shapes) that
> cause a lot less trouble for the ODE solver :-D I'll have a look into
> the patch as soon as I can (which will probably not be before the
> weekend :-/).
>
> That's no problem, don't have it working yet anyway :-) Regarding  
> the complex shaped robot models, I also looked into the ODE TriMesh  
> geometry, which enables you to use any triangular mesh you'd like.  
> However, this brings more complexity to the simulation, so might be  
> something to consider some other time?

If we really need a very detailed collision model, we should consider  
the TriMesh collider. I remember the guy who did UChilSim used it for  
the lower leg part of his Aibos, back in 2004 and said he was  
surprised how well it performed (even though it was still very  
experimental at that time). Still more complex than a few composed  
boxes I guess.

>
>
> I'm not completely sure whether this is correct. In your example,
> there is one Collider directly below the Body and another one below a
> TransformCollider. If the Body is to be modeled as a composite
> object, I think all of the Colliders will have to be placed below a
> TransformCollider node.
>
> I believe it is not necessary to have a  TransformCollider for each  
> Collider. If I understand the ODE documentation correctly, any  
> geometry (collider) can be placed next to any other one. Only when  
> one geometry needs to be moved or rotated relative to the body's  
> center a transform geometry is needed.

Yes, I think you're right.

Cheers,
Joschka

Re: [simspark-devel] ODE Composite bodies

[Sander v. D. <sgv...@gm...>]

Hi Joschka et al (sorry for the double email Joschka),

On Feb 6, 2008 10:16 AM, Joschka Boedecker <
jos...@am...> wrote:

> Hey Sander,
>
> (I copied the simspark-devel list, I hope you don't mind)
>

Not at all :-)


>
> > I also changed Collider::OnLink to encapsulate colliders that have
> > a transform collider as their parent into it.
>
> I'm not sure if I understand this. Do you mean, you changed the code
> of the Collider class so that it does what Markus described above for
> the code of the Collider class in the simspark repository (associate
> with a TransformCollider instance parent)?


Oops, I didn't look into the SimSpark CVS well enough and missed parts of
Markus' code. So now it turns out I mostly duplicated some stuff he already
did :-) I will go further with his implementation, mine gives segfaults in
ruby at the moment. Still was a good exercise in understanding the
simulation server, though.


> > The new files and a patch with this code are attached.
> >
>
> Great, thanks a bunch! I really appreciate your work on this :-)
> Seems like we can finally get rid of the hacks used in the Soccerbot
> RSG file and have better robot models (with complex shapes) that
> cause a lot less trouble for the ODE solver :-D I'll have a look into
> the patch as soon as I can (which will probably not be before the
> weekend :-/).


That's no problem, don't have it working yet anyway :-) Regarding the
complex shaped robot models, I also looked into the ODE TriMesh geometry,
which enables you to use any triangular mesh you'd like. However, this
brings more complexity to the simulation, so might be something to consider
some other time?


> I'm not completely sure whether this is correct. In your example,
> there is one Collider directly below the Body and another one below a
> TransformCollider. If the Body is to be modeled as a composite
> object, I think all of the Colliders will have to be placed below a
> TransformCollider node.


I believe it is not necessary to have a  TransformCollider for each
Collider. If I understand the ODE documentation correctly, any geometry
(collider) can be placed next to any other one. Only when one geometry needs
to be moved or rotated relative to the body's center a transform geometry is
needed. Most likely though this will be the case for most composite bodies.

Regards,

Sander

Re: [simspark-devel] ODE Composite bodies

[Joschka B. <jos...@am...>]

Hey Sander,

(I copied the simspark-devel list, I hope you don't mind)

On Feb 6, 2008, at 1:15 AM, Sander van Dijk wrote:

>
> After reading your mail (forwarded to the rest of the team by Mart)  
> I looked into using composite bodies in ODE. I took the  
> TransformCollider from Markus from the Simspark CVS

You're fast! Sorry, if I had known you'd start to work on that right  
away, I would have given some more information that Markus gave me  
about the TransformColliders back when he first implemented them. But  
of course I'm more than happy that you did start the work :-)

Let me first give you the information I found in an old email from  
Markus. Here's what he wrote:

The class TransformCollider implements the ODE concept of transform  
geoms (necessary for composite objects). A Collider object which is  
linked below an instance of this class in the hierarchy will  
automatically be associated with this TransformCollider. Only one  
Collider is allowed to be associated with one TransformCollider in  
this way.

The TransformCollider changes two things:

- the CollisionHandler must not be linked in below the Collider, but  
below the TransformCollider
- the method "SetPosition" of a Collider will change the  position of  
the collision primitives relative to the TransformCollider

The construction of a composite object is done just like in the  
"normal" case:

- all the nodes are linked into the hierarchy below a common  
Transform node.
- the objects that are visible (rendered on screen) might be placed  
with additional Transform nodes
- after that, as usual, we link in a Body node; the mass and the  
center of mass might have to be adjusted
- now we link in the Colliders; in case we want to offset them for a  
composite object, they are linked in as a child of a TransformCollider

Here is an example for a body composed of a sphere and a box:

(Transform
   (Transform
     (SetLocalPos ...)
     (Box)
   )
   (Transform
     (SetLocalPos ...)
     (Sphere)
   )
   (Body)
   (TransformCollider
     (BoxCollider
       (SetPosition ...)
     )
     (ContactJointHandler ...)
   )
   (TransformCollider
     (SphereCollider
       (SetPosition ...)
     )
     (ContactJointHandler ...)
   )
)

Markus also wrote that he only tested the implementation with simple  
examples and that he wasn't 100% sure it was complete and suitable  
for modeling more complex structures. Unfortunately, I never really  
had time to test the implementation myself. It seems to me that at  
least the automatic adjustment of the masses and center of mass could  
be added as an improvement (see e.g. [1] for the general principle).

> and implemented the missing methods to actually encapsulate a  
> geometry in the transform geometry.

Hmm, I haven't looked at the code yet (sorry, pretty busy at the  
moment), but if I understand Markus' explanations above, the geometry  
should stay with the Collider class (which will be placed below the  
TransformCollider as a child node). I might be wrong though, maybe it  
was still missing ;-)

> I also changed Collider::OnLink to encapsulate colliders that have  
> a transform collider as their parent into it.

I'm not sure if I understand this. Do you mean, you changed the code  
of the Collider class so that it does what Markus described above for  
the code of the Collider class in the simspark repository (associate  
with a TransformCollider instance parent)?

> The new files and a patch with this code are attached.
>

Great, thanks a bunch! I really appreciate your work on this :-)  
Seems like we can finally get rid of the hacks used in the Soccerbot  
RSG file and have better robot models (with complex shapes) that  
cause a lot less trouble for the ODE solver :-D I'll have a look into  
the patch as soon as I can (which will probably not be before the  
weekend :-/).

> If I understand the system correctly, with this it is possible to  
> include something like the following in an RSG file to create a  
> composite body:
>
> -----------------------------------
>   (nd Body
>       ...
>   )
>
>   (nd BoxCollider
>             (setBoxLengths (eval 0.5 * $lenX) (eval 0.5 * $lenY)  
> (eval 0.5 * $lenZ))
>   )
>
>   (nd TransformCollider
>        (nd BoxCollider
>             (setBoxLengths (eval 0.5 * $lenX) (eval 0.5 * $lenY)  
> (eval 0.5 * $lenZ))
>             (setPosition 0 0 (eval 0.75 * $lenZ))
>        )
> -----------------------------------
>

I'm not completely sure whether this is correct. In your example,  
there is one Collider directly below the Body and another one below a  
TransformCollider. If the Body is to be modeled as a composite  
object, I think all of the Colliders will have to be placed below a  
TransformCollider node.

> I am not sure whether the implementation is correct, or pretty (for  
> instance that collider.cpp now includes transformcollider.h and  
> some boost stuff I'm unfamiliar with) :-)

I'll have a look, but don't worry too much about not being pretty for  
now. We can take care of beautification after it works ;-)

> And I haven't really tested yet if it actually works, but wanted to  
> make sure I was on the right way.

I think you are, but please check my comments above.

> I will try to construct a soccerbot with a single composite torso  
> later.

Cool :-P

>
> Referring some other testing:
> - I use ODE 0.9 with double precision myself. I unfortunately don't  
> see much change in simulation speed and amount of LCP errors

OK, I guess it really is a design flaw in our robot.

>
> - I generate LCP errors by making an agent slap his hand against  
> his thigh. This error disapears when I use a single block for it's  
> torso, like the 0.55 bot. So this gives hope for using composite  
> bodies

Yes, very much so :-)

>
> - The error also disapears when reducing the maximum motor force.  
> However, I haven't found a value yest that is low enough to prevent  
> the errors but high enough to give the agent enough strength to get  
> itself up.

The motor strength should be limited, not only for the sake of  
simulation stability, but also for more realism (to prevent excessive  
jumping and somersaults ;-) ).

>
> - I have tried using dWorldQuickStep instead of dWorldStep to  
> advance simulation, however this destabalizes the agent, making it  
> look like a bag of potatoes :-). The ODE manual predicts this for  
> complex robot systems [1].
>

Thanks for trying though.

> I'll let you know when I make more progress.
>

Great! Please keep up the good work!

Cheers,
Joschka

[1] http://opende.sourceforge.net/mediawiki-1.6.10/index.php/ 
HOWTO_composite_objects

P.S.: if you think it'll help, I can send you some code for a "pure"  
ODE version of the HOAP-2 inspired robot I did way back before I  
started to implement it in simspark. It uses compound bodies, so it  
might be helpful as a reference. Let me know.

Re: [simspark-devel] performance

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
<span>Hi Yuan,<br>
OK, it seems that you are not agree with using a single step (equal the
time spent since the last step) in dWorldStep instead of discreet time
steps. Not a problem since both of situations are undesirable. <br>
<br>
About your suggestion,  the parameter could have a second state: "auto"
which could be the default one. In this mode, the server can recognize
the slowness of the running environment and adjusts itself according to
that. Also it can print error messages when it runs slower than real
time so that the user will recognize it. What's your opinion?<br>
<br>
Thanks,<br>
Bye<br>
<br>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;}  blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important}  blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important}  blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important}  blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>"Yuan
Xu" <a class="moz-txt-link-rfc2396E" href="mailto:xuy...@gm...">&lt;xuy...@gm...&gt;</a></b></i> wrote on 01/31/2008 06:35:37 AM:</span><br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:18a...@ma..."   type="cite">
  <pre wrap="">Hi Hedayat,

You are right. It is only like 2D server, but the latter does not need
so much computation.
As I said in my report about the timer, it depends on the server
performance and hardware.
Currently, some powerful PC can handle the 2v2 game, such as the PC in
the China Open 07.( I do not know the specifies, sorry ). But I am
sure it can not run 11v11. What we can do is optimize the server,
otherwise make the computation time (real time) longer than simulation
time.
However, longer computation time will make game time longer ( it is
not desired by organiger ),
and more important, it is not suitable to the machine learning,
because the experiment is even slower than the real robot.

On the other side, the current server can not run properly in some old computer.
To trade-off, maybe a parameter can imported as `simRate' = simulation
time / real time.
And the user configure it themselves according their hardware. But it
may be hard to newbie.

  </pre>
  <blockquote type="cite">
    <pre wrap=""> Thanks. But there is a problem (I think), it'll be OK if we are
occasionally forced to do more than one step in one cycle, but if it happens
usually which means that the server is unable to finish a single step in the
desired time (which is the current situation I think), the number of
required steps will grow exponentially. So what?! I don't know :(
 Ideally, it shouldn't happen at all or at least in some rare cases, but
when it happens, the server will not be able to catch up with the time.
 Things might be better if we call dWorldStep with the real elapsed time
which will at least prevent accumulation of server delays. (Considering the
current slowness of the server (at least in my system!), this may change
nothing at all, but it might be better when the server is optimized a bit?!)

    </pre>
  </blockquote>
</blockquote>
</body>
</html>

Re: [simspark-devel] performance

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

Hi Hesham,

 Our team binary in China Open 07 has been published in
http://xuyuan.cn.googlepages.com/SEU-RedSun-Final.tar.gz,
and our team binary in RC07 is here:
http://xuyuan.cn.googlepages.com/SEU-RC07-binary.tar.gz

Hope it can help.

2008/1/30, Hesham <hes...@gm...>:
>
> Hi Yuan, Salam Hedayat,
>
> Yuan, you're absolutely right. I need to have kind of stress test as well to
> have a better insight into the server performance. As you know for a such a
> long time I haven't worked on a team for 3D soccer. So I was wondering if
> you can send me a binary that (with normal expected behaviours) makes ODE
> take a long time to simulate. Like a specific collision or whatever. I'm
> using the test agents that stand and just move their arms and send/hear
> messages. I've started optimizing ODE, it's not easy but so far it's
> promising, on the weekend I'll let you know the progress.
>
> Thanks in advances,
> Hesham
>
>
> On 28/01/2008, Yuan Xu <xuy...@gm...> wrote:
> > Hi all,
> >
> > >
> > > Next weekend I'll try to work more on these issues, and probably until
> then
> > > will know the answer of your 4th question.
> > >
> > > 4) What's the reason for stepping in discreet steps in
> SimulationServer::Step()?
> > > Will it change anything with ODE?
> >
> > Yes, dWorldStep(20ms)+dWorldStep(20ms) !=
> dWorldStep(40ms).
> > Because, the collision detection is missing in dWorldStep(40ms).
> >
> >
> > > Yuan, the code of SDL_GetTicks() is simple, it doesn't give any more
> > > precision. I didn't get some parts of what you said.
> >
> > Yes, the precision depends on the OS, then I remind the RTL, and I
> > know it is not suitable.
> >
> > > Maybe a silly question
> > > but, the server is supposed to have sharp 20ms cycles?
> >
> > The cycle duration effects the performance of robot controller.
> > Note that the control cycle is less than 10ms in real robot.
> > The longer cycle the harder for the controller.
> > And the HMDP[Joschka] may solve this, but it will make teams to change
> > their codes a lot.
> >
> > > I thought the
> > > previous timing method (SPADES) was replaced by the new one to get rid
> of
> > > the problems we had with timers, and more rely on time stamps. But you
> > > suggested using RTL to have more precise timers.
> >
> > The SPADES do not count the real time, it counts how many jiffies used
> > by the agent.
> > It can measure the CPU cost of the agent, but if the agent spend a lot
> > of time on other work, such as communication, writing logs, the game
> > will be very slow. Jelle Kok said that some games last less than
> > 10min, but some other games need more than 1 hour!
> >
> > > Sorry maybe I got the whole
> > > thing wrong, I'll go through the code again. But I would appreciate it
> if
> > > you (or others) could please remind me the new idea for timing, maybe by
> > > referring to old emails - I couldn't find them.
> > >
> >
> > The timer was designed just like the 2D server: fixed cycle duration,
> > the agent should sent action in time, otherwise the action will not be
> > executed. The difference between 2D and 3D only are the duration and
> > implementation.
> >
> >
> > Best wishes!
> >
> > Xu Yuan
> >
>
>


-- 
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] performance

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

Hi Hedayat,

You are right. It is only like 2D server, but the latter does not need
so much computation.
As I said in my report about the timer, it depends on the server
performance and hardware.
Currently, some powerful PC can handle the 2v2 game, such as the PC in
the China Open 07.( I do not know the specifies, sorry ). But I am
sure it can not run 11v11. What we can do is optimize the server,
otherwise make the computation time (real time) longer than simulation
time.
However, longer computation time will make game time longer ( it is
not desired by organiger ),
and more important, it is not suitable to the machine learning,
because the experiment is even slower than the real robot.

On the other side, the current server can not run properly in some old computer.
To trade-off, maybe a parameter can imported as `simRate' = simulation
time / real time.
And the user configure it themselves according their hardware. But it
may be hard to newbie.

>  Thanks. But there is a problem (I think), it'll be OK if we are
> occasionally forced to do more than one step in one cycle, but if it happens
> usually which means that the server is unable to finish a single step in the
> desired time (which is the current situation I think), the number of
> required steps will grow exponentially. So what?! I don't know :(
>  Ideally, it shouldn't happen at all or at least in some rare cases, but
> when it happens, the server will not be able to catch up with the time.
>  Things might be better if we call dWorldStep with the real elapsed time
> which will at least prevent accumulation of server delays. (Considering the
> current slowness of the server (at least in my system!), this may change
> nothing at all, but it might be better when the server is optimized a bit?!)
>

[simspark-devel] Intel's book examples

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
<p dir="ltr" style="margin-bottom: 0cm; margin-top: 0pt;" align="left">Hi
Hesham,</p>
<p dir="ltr" style="margin-bottom: 0cm; margin-top: 0pt;">I found this
link: <a class="moz-txt-link-freetext"   href="http://softwarecommunity.intel.com/isn/downloads/examples.zip">http://softwarecommunity.intel.com/isn/downloads/examples.zip</a></p>
<p dir="ltr" style="margin-bottom: 0cm; margin-top: 0pt;">But there are
two problems:</p>
<p dir="ltr" style="margin-bottom: 0cm; margin-top: 0pt;">1. The
license (which might not be a problem though!)</p>
<p dir="ltr" style="margin-bottom: 0cm; margin-top: 0pt;">2. They have
changed the dWorldStepFast1() method to be multi-threaded. According to
ODE documentation, this function is superseded with the
dWorldQuickStep() method, which was not useful (in my experiments at
least). (However, some tweaking in the robot model and/or other
parameters may solve the problems).</p>
<p dir="ltr" style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p dir="ltr" style="margin-bottom: 0cm; margin-top: 0pt;">Anyways, some
testing might be useful. <br>
</p>
<p dir="ltr" style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p dir="ltr" style="margin-bottom: 0cm; margin-top: 0pt;">Good luck,</p>
<p dir="ltr" style="margin-bottom: 0cm; margin-top: 0pt;">Bye</p>
<p dir="ltr" style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
</body>
</html>

Re: [simspark-devel] performance

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
Hi Hesham,<br>
Thanks for your answer. I'm agree with you about experimenting with a
multi-threaded ODE. In fact, I searched for a multi-threaded ode and I
found a paper but no code (but it was not what you mentioned). I will
search more and I hope that we can find it.<br>
I'll try to download the pdf and will notify you if I can't get it.
Thanks.<br>
Also, I'll try the google profiler too. <br>
<br>
Have a nice time,<br>
Hedayat<br>
<span><br>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;}  blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important}  blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important}  blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important}  blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>Hesham
<a class="moz-txt-link-rfc2396E" href="mailto:hes...@gm...">&lt;hes...@gm...&gt;</a></b></i> wrote on 01/28/2008 01:08:32
AM:</span><br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:1d7...@ma..."   type="cite"><br>
Hi Hedayat and Yuan,<br>
  <br>
Hedayat, sorry I didn't find time to reply your email earlier.
Regarding that interface for the physics engines, it sounds a good idea
to either use it directly or write something like that for the server.
But apparently it's a good idea to first test the server with
multi-threaded ODE. I was reading Intel Threading Building Blocks book,
you can find the first chapter at: <a moz-do-not-send="true"   href="http://softwarecommunity.intel.com/isn/downloads/intel_tbb_ch01_for_promo.pdf"   target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">http://softwarecommunity.intel.com/isn/downloads/intel_tbb_ch01_for_promo.pdf</a><br>
In chapter 11 they explain two methods and mention the complete code is
on the website, I tried to find it but so far no luck. (If you don't
have access to the book, let me know I can send you that section.)<br>
  <br>
I'm using the Google profiler(/sampler), it's pretty straightforwards.
I tried to write about it on the wiki but it asked me to login, and
using my sorceforge ID/password it failed. Anyway I'll write it within
this week and email it to you, so we can use the same method. And to me
it makes sense that we get different results(/hot spots), because of
different systems (HW&amp;SW) we use. As far as I know a good example
is ATLAS (<a moz-do-not-send="true" href="http://math-atlas.sf.net">math-atlas.sf.net</a>),
using scripts generates the optimized code for different systems.<br>
  <br>
Next weekend I'll try to work more on these issues, and probably until
then will know the answer of your 4th question.<br>
  <br>
Yuan, the code of <span>SDL_GetTicks() is simple, it doesn't give any
more precision. I didn't get some parts of what you said. Maybe a silly
question but, the server is supposed to have sharp 20ms cycles? I
thought the previous timing method (SPADES) was replaced by the new one
to get rid of the problems we had with timers, and more rely on time
stamps. But you suggested using RTL to have more precise timers. Sorry
maybe I got the whole thing wrong, I'll go through the code again. But
I would appreciate it if you (or others) could please remind me the new
idea for timing, maybe by referring to old emails - I couldn't find
them.<br>
  <br>
Thanks,<br>
Hesham<br>
  </span><br>
  <div><span class="gmail_quote">On 27/01/2008, <b   class="gmail_sendername">Hedayat Vatankhah</b> &lt;<a   moz-do-not-send="true" href="mailto:hed...@ai..." target="_blank"   onclick="return top.js.OpenExtLink(window,event,this)">hed...@ai...</a>&gt;
wrote:</span>
  <blockquote class="gmail_quote"   style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
    <div style="direction: ltr;" bgcolor="#ffffff" text="#000000"><span>Hi,<br>
First, I think that the loop isn't a problem too. And I wonder if
SDL_GetTicks()  creates any major problem now.<br>
But the multi-threaded ODE might be really helpful. <br>
    <br>
Second, would you please how do you profile the server? Each of us gets
different results and I wonder why is so. Also, for the profiling
results I provided in my previous mail I used valgrind's tools. As it
is really slow, I used just one robot in those tests. Please tell me
about the ways you use for profiling the server.<br>
    <br>
Finally, It would be really nice if you tell me your opinions or the
mistakes in the patch I sent with my email recently(in the email with
subject: "some experiments with the server"). Also, I'm really
interested to know about the answer of the 4th question.<br>
    <br>
Thanks anyway,<br>
Hedayat<br>
    <br>
    <i><b>"Yuan
Xu" <a moz-do-not-send="true" href="mailto:xuy...@gm..."   target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">&lt;xuy...@gm...&gt;</a></b></i>
wrote on 01/27/2008 06:01:45 PM:</span>
    <div><span><br>
    <blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   type="cite">
      <pre>Hi Hesham and all,


  </pre>
      <blockquote type="cite">
        <pre>After profiling the server I saw SDL_GetTicks() is taking around 25% of the
time (in the tests I used 7 robots and with the single thread mode). To make
long short, I saw this loop (while) in simulationserver.cpp:


        ....
Since SimulationServer::Step() takes care of this case
(int(mSumDeltaTime*100) &lt; int(mSimStep*100)) I thought that while in Run()
is not necessary. So after commenting it out, SDL_GetTicks() takes less than


10% of the time:
    </pre>
      </blockquote>
      <pre>The phenomenon is reasonable.
Since the time queries are needed for timing in single thread,
the percentage of queries means that your machine are light underload(
not too busy ),
I guess your robots did not do anything. You will notice that the


percentage of queries will lower if robots are collides...
But if you remove the codes, the timer is noneffective. Then if the
robots collides, the server will very very slow, otherwise the
simulation time elapse very quickly.


You may ask why use query to get time, ok, I do not think it is a good idea.
The server cycle is 20ms, but the time precision of Linux is only 10ms,
some function such as "sleep" also can not help on it.


In fact, SDL_GetTicks() is used to get "preciser"(seemly).
And it is possibly that SDL causes the Input problem in multi-threads.

I have some idea to this:
 1. to get precise time, use RealTime-Linux as platform [It will


narrow OS platform]
 2. use a new thread to time, The timing is in InputControl thread in
current multi-thread implementation, but query is also used(It can be
improved little). [It may make the timing-thread busy, and can not


guarantee precision.]
 3. use other timer instead SDLTimer, such as boost::xtime. [It need
more investigation.]

  </pre>
      <blockquote type="cite">
        <pre>BTW, the other day I came across the multi-threaded version of ODE by Intel.
    </pre>
      </blockquote>
      <pre>Sounds interesting.

  </pre>
    </blockquote>
    <br>
    </span></div>
    </div>
  </blockquote>
  </div>
  <br>
</blockquote>
</body>
</html>

Re: [simspark-devel] performance

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
<span>Hi Yuan,<br>
<br>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;}  blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important}  blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important}  blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important}  blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>"Yuan
Xu" <a class="moz-txt-link-rfc2396E" href="mailto:xuy...@gm...">&lt;xuy...@gm...&gt;</a></b></i> wrote on 01/28/2008 07:53:01 AM:</span><br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:18a...@ma..."   type="cite">
  <pre wrap="">Hi all,
  </pre>
  <blockquote type="cite">
    <pre wrap="">Next weekend I'll try to work more on these issues, and probably until then
will know the answer of your 4th question.

4) What's the reason for stepping in discreet steps in SimulationServer::Step()?
Will it change anything with ODE?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yes, dWorldStep(20ms)+dWorldStep(20ms) != dWorldStep(40ms).
Because, the collision detection is missing in dWorldStep(40ms).
  </pre>
</blockquote>
Thanks. But there is a problem (I think), it'll be OK if we are
occasionally forced to do more than one step in one cycle, but if it
happens usually which means that the server is unable to finish a
single step in the desired time (which is the current situation I
think), the number of required steps will grow exponentially. So what?!
I don't know :( <br>
Ideally, it shouldn't happen at all or at least in some rare cases, but
when it happens, the server will not be able to catch up with the time.
<br>
Things might be better if we call dWorldStep with the real elapsed time
which will at least prevent accumulation of server delays. (Considering
the current slowness of the server (at least in my system!), this may
change nothing at all, but it might be better when the server is
optimized a bit?!)<br>
<br>
Thanks a lot,<br>
Hedayat<br>
<br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:18a...@ma..."   type="cite">
  <pre wrap="">.....
Best wishes!

Xu Yuan

  </pre>
</blockquote>
</body>
</html>

Re: [simspark-devel] performance

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

Hi all,

>
> Next weekend I'll try to work more on these issues, and probably until then
> will know the answer of your 4th question.
>
> 4) What's the reason for stepping in discreet steps in SimulationServer::Step()?
> Will it change anything with ODE?

Yes, dWorldStep(20ms)+dWorldStep(20ms) != dWorldStep(40ms).
Because, the collision detection is missing in dWorldStep(40ms).


> Yuan, the code of SDL_GetTicks() is simple, it doesn't give any more
> precision. I didn't get some parts of what you said.

Yes, the precision depends on the OS, then I remind the RTL, and I
know it is not suitable.

> Maybe a silly question
> but, the server is supposed to have sharp 20ms cycles?

The cycle duration effects the performance of robot controller.
Note that the control cycle is less than 10ms in real robot.
The longer cycle the harder for the controller.
And the HMDP[Joschka] may solve this, but it will make teams to change
their codes a lot.

> I thought the
> previous timing method (SPADES) was replaced by the new one to get rid of
> the problems we had with timers, and more rely on time stamps. But you
> suggested using RTL to have more precise timers.

The SPADES do not count the real time, it counts how many jiffies used
by the agent.
It can measure the CPU cost of the agent, but if the agent spend a lot
of time on other work, such as communication, writing logs, the game
will be very slow. Jelle Kok said that some games last less than
10min, but some other games need more than 1 hour!

> Sorry maybe I got the whole
> thing wrong, I'll go through the code again. But I would appreciate it if
> you (or others) could please remind me the new idea for timing, maybe by
> referring to old emails - I couldn't find them.
>

The timer was designed just like the 2D server: fixed cycle duration,
the agent should sent action in time, otherwise the action will not be
executed. The difference between 2D and 3D only are the duration and
implementation.


Best wishes!

Xu Yuan

Re: [simspark-devel] performance

[Hesham <hes...@gm...>]

Hi Hedayat and Yuan,

Hedayat, sorry I didn't find time to reply your email earlier. Regarding
that interface for the physics engines, it sounds a good idea to either use
it directly or write something like that for the server. But apparently it's
a good idea to first test the server with multi-threaded ODE. I was reading
Intel Threading Building Blocks book, you can find the first chapter at:
http://softwarecommunity.intel.com/isn/downloads/intel_tbb_ch01_for_promo.pdf
In chapter 11 they explain two methods and mention the complete code is on
the website, I tried to find it but so far no luck. (If you don't have
access to the book, let me know I can send you that section.)

I'm using the Google profiler(/sampler), it's pretty straightforwards. I
tried to write about it on the wiki but it asked me to login, and using my
sorceforge ID/password it failed. Anyway I'll write it within this week and
email it to you, so we can use the same method. And to me it makes sense
that we get different results(/hot spots), because of different systems
(HW&SW) we use. As far as I know a good example is ATLAS (math-atlas.sf.net),
using scripts generates the optimized code for different systems.

Next weekend I'll try to work more on these issues, and probably until then
will know the answer of your 4th question.

Yuan, the code of SDL_GetTicks() is simple, it doesn't give any more
precision. I didn't get some parts of what you said. Maybe a silly question
but, the server is supposed to have sharp 20ms cycles? I thought the
previous timing method (SPADES) was replaced by the new one to get rid of
the problems we had with timers, and more rely on time stamps. But you
suggested using RTL to have more precise timers. Sorry maybe I got the whole
thing wrong, I'll go through the code again. But I would appreciate it if
you (or others) could please remind me the new idea for timing, maybe by
referring to old emails - I couldn't find them.

Thanks,
Hesham

On 27/01/2008, Hedayat Vatankhah <hed...@ai...> wrote:
>
>  Hi,
> First, I think that the loop isn't a problem too. And I wonder if
> SDL_GetTicks()  creates any major problem now.
> But the multi-threaded ODE might be really helpful.
>
> Second, would you please how do you profile the server? Each of us gets
> different results and I wonder why is so. Also, for the profiling results I
> provided in my previous mail I used valgrind's tools. As it is really slow,
> I used just one robot in those tests. Please tell me about the ways you use
> for profiling the server.
>
> Finally, It would be really nice if you tell me your opinions or the
> mistakes in the patch I sent with my email recently(in the email with
> subject: "some experiments with the server"). Also, I'm really interested to
> know about the answer of the 4th question.
>
> Thanks anyway,
> Hedayat
>
> *"Yuan Xu" <xuy...@gm...> <xuy...@gm...>* wrote on
> 01/27/2008 06:01:45 PM:
>
> Hi Hesham and all,
>
>
>    After profiling the server I saw SDL_GetTicks() is taking around 25% of the
> time (in the tests I used 7 robots and with the single thread mode). To make
> long short, I saw this loop (while) in simulationserver.cpp:
>
>         ....
> Since SimulationServer::Step() takes care of this case
> (int(mSumDeltaTime*100) < int(mSimStep*100)) I thought that while in Run()
> is not necessary. So after commenting it out, SDL_GetTicks() takes less than
>
> 10% of the time:
>
>  The phenomenon is reasonable.
> Since the time queries are needed for timing in single thread,
> the percentage of queries means that your machine are light underload(
> not too busy ),
> I guess your robots did not do anything. You will notice that the
>
> percentage of queries will lower if robots are collides...
> But if you remove the codes, the timer is noneffective. Then if the
> robots collides, the server will very very slow, otherwise the
> simulation time elapse very quickly.
>
> You may ask why use query to get time, ok, I do not think it is a good idea.
> The server cycle is 20ms, but the time precision of Linux is only 10ms,
> some function such as "sleep" also can not help on it.
>
> In fact, SDL_GetTicks() is used to get "preciser"(seemly).
> And it is possibly that SDL causes the Input problem in multi-threads.
>
> I have some idea to this:
>  1. to get precise time, use RealTime-Linux as platform [It will
>
> narrow OS platform]
>  2. use a new thread to time, The timing is in InputControl thread in
> current multi-thread implementation, but query is also used(It can be
> improved little). [It may make the timing-thread busy, and can not
>
> guarantee precision.]
>  3. use other timer instead SDLTimer, such as boost::xtime. [It need
> more investigation.]
>
>    BTW, the other day I came across the multi-threaded version of ODE by Intel.
>
>  Sounds interesting.
>
>
>

Re: [simspark-devel] performance

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
<span>Hi,<br>
First, I think that the loop isn't a problem too. And I wonder if
SDL_GetTicks()  creates any major problem now.<br>
But the multi-threaded ODE might be really helpful. <br>
<br>
Second, would you please how do you profile the server? Each of us gets
different results and I wonder why is so. Also, for the profiling
results I provided in my previous mail I used valgrind's tools. As it
is really slow, I used just one robot in those tests. Please tell me
about the ways you use for profiling the server.<br>
<br>
Finally, It would be really nice if you tell me your opinions or the
mistakes in the patch I sent with my email recently(in the email with
subject: "some experiments with the server"). Also, I'm really
interested to know about the answer of the 4th question.<br>
<br>
Thanks anyway,<br>
Hedayat<br>
<br>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;}  blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important}  blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important}  blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important}  blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>"Yuan
Xu" <a class="moz-txt-link-rfc2396E" href="mailto:xuy...@gm...">&lt;xuy...@gm...&gt;</a></b></i> wrote on 01/27/2008 06:01:45 PM:</span><br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:18a...@ma..."   type="cite">
  <pre wrap="">Hi Hesham and all,


  </pre>
  <blockquote type="cite">
    <pre wrap="">After profiling the server I saw SDL_GetTicks() is taking around 25% of the
time (in the tests I used 7 robots and with the single thread mode). To make
long short, I saw this loop (while) in simulationserver.cpp:
        ....
Since SimulationServer::Step() takes care of this case
(int(mSumDeltaTime*100) &lt; int(mSimStep*100)) I thought that while in Run()
is not necessary. So after commenting it out, SDL_GetTicks() takes less than
10% of the time:
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The phenomenon is reasonable.
Since the time queries are needed for timing in single thread,
the percentage of queries means that your machine are light underload(
not too busy ),
I guess your robots did not do anything. You will notice that the
percentage of queries will lower if robots are collides...
But if you remove the codes, the timer is noneffective. Then if the
robots collides, the server will very very slow, otherwise the
simulation time elapse very quickly.
You may ask why use query to get time, ok, I do not think it is a good idea.
The server cycle is 20ms, but the time precision of Linux is only 10ms,
some function such as "sleep" also can not help on it.
In fact, SDL_GetTicks() is used to get "preciser"(seemly).
And it is possibly that SDL causes the Input problem in multi-threads.

I have some idea to this:
 1. to get precise time, use RealTime-Linux as platform [It will
narrow OS platform]
 2. use a new thread to time, The timing is in InputControl thread in
current multi-thread implementation, but query is also used(It can be
improved little). [It may make the timing-thread busy, and can not
guarantee precision.]
 3. use other timer instead SDLTimer, such as boost::xtime. [It need
more investigation.]

  </pre>
  <blockquote type="cite">
    <pre wrap="">BTW, the other day I came across the multi-threaded version of ODE by Intel.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Sounds interesting.

  </pre>
</blockquote>
<br>
</body>
</html>

Re: [simspark-devel] performance

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

Hi Hesham and all,


> After profiling the server I saw SDL_GetTicks() is taking around 25% of the
> time (in the tests I used 7 robots and with the single thread mode). To make
> long short, I saw this loop (while) in simulationserver.cpp:
>         ....
> Since SimulationServer::Step() takes care of this case
> (int(mSumDeltaTime*100) < int(mSimStep*100)) I thought that while in Run()
> is not necessary. So after commenting it out, SDL_GetTicks() takes less than
> 10% of the time:

The phenomenon is reasonable.
Since the time queries are needed for timing in single thread,
the percentage of queries means that your machine are light underload(
not too busy ),
I guess your robots did not do anything. You will notice that the
percentage of queries will lower if robots are collides...
But if you remove the codes, the timer is noneffective. Then if the
robots collides, the server will very very slow, otherwise the
simulation time elapse very quickly.
You may ask why use query to get time, ok, I do not think it is a good idea.
The server cycle is 20ms, but the time precision of Linux is only 10ms,
some function such as "sleep" also can not help on it.
In fact, SDL_GetTicks() is used to get "preciser"(seemly).
And it is possibly that SDL causes the Input problem in multi-threads.

I have some idea to this:
 1. to get precise time, use RealTime-Linux as platform [It will
narrow OS platform]
 2. use a new thread to time, The timing is in InputControl thread in
current multi-thread implementation, but query is also used(It can be
improved little). [It may make the timing-thread busy, and can not
guarantee precision.]
 3. use other timer instead SDLTimer, such as boost::xtime. [It need
more investigation.]

> BTW, the other day I came across the multi-threaded version of ODE by Intel.

Sounds interesting.

> I think it's worth a try if Yuan has time to help :-) There is something
> wrong with the multi-threaded mode of the server on my system. So first I
> need to find out what's the problem.

I am free recently. Give some hints of your problem.


-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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

[simspark-devel] performance

[Hesham <hes...@gm...>]

Hi all,

After profiling the server I saw SDL_GetTicks() is taking around 25% of the
time (in the tests I used 7 robots and with the single thread mode). To make
long short, I saw this loop (while) in simulationserver.cpp:
void SimulationServer::Run(int argc, char** argv)
{       ....
        if (mAutoTime)
        {
            AdvanceTime(mSimStep); cout<<"AutoTime"<<endl;
        }
        else
        {
            while (int(mSumDeltaTime*100) < int(mSimStep*100))
            {
                inputCtr->StartCycle();// advance the time
            }
        }
        ....
Since SimulationServer::Step() takes care of this case
(int(mSumDeltaTime*100) < int(mSimStep*100)) I thought that while in Run()
is not necessary. So after commenting it out, SDL_GetTicks() takes less than
10% of the time:
void SimulationServer::Run(int argc, char** argv)
{       ....
        if (mAutoTime)
        {
            AdvanceTime(mSimStep); cout<<"AutoTime"<<endl;
        }
        else
        {
        inputCtr->StartCycle();// advance the time
        }
        ....
BTW, the other day I came across the multi-threaded version of ODE by Intel.
I think it's worth a try if Yuan has time to help :-) There is something
wrong with the multi-threaded mode of the server on my system. So first I
need to find out what's the problem.

Bests,
Hesham

[simspark-devel] PAL

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
<p style="margin-bottom: 0cm; margin-top: 0pt;">Hi,</p>
Today, I was searching a little about physics engines, and I found
something interesting: PAL
(<a class="moz-txt-link-freetext"   href="http://www.adrianboeing.com/pal/index.html">http://www.adrianboeing.com/pal/index.html</a>).
It is exactly what I
talked about in discussions about using IDBS.<br>
This library supports ODE, BULLET and have an experimental support for
IDBS (and many more, such as PhysX).<br>
It also supports COLLADA.<br>
What do you think about it?<br>
<br>
Have a nice time,<br>
Hedayat<br>
<br>
</body>
</html>

[simspark-devel] Some experiments with the server

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
<p style="margin-bottom: 0cm; margin-top: 0pt;">Hi all,</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Today, I have played
with the server a bit, and these are the results (might be useful!);</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">1) I did a test with
dWorldQuickStep() instead of dWorldStep(). With the default iterations,
players would explode. I tried with 100 and 1000 iterations, the robots
didn't explode but they did some strange behaviors. I think that it is
not useful, at least with the current parameters. </p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">2) I did what Joschka
said about the Space creation. It seems reasonable so it is included in
the patch I've attached to this mail. However, I didn't notice any
improvements. (Not an accurate comparison, just some observations.)</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">3) I was unable to run
the server in the multi-threaded mode (it crashed), and I decided to
have a look at code. I decided to rewrite some parts of it and I used a
barrier object instead of using condition variables. I think the code
is a little simpler now and might be a little faster too. The code is
attached to this mail. It seems that the EndCycle functions are not
thread safe and also, when the EndCycle function of the RenderControl
is called outside the main thread it crashed on the first gl function
call (at least in my system). I implemented this (treating
RenderControl as an exception) and it didn't crashed like before, but
after some time it crashed in the middle of one of EndCycle functions
which shows that the EndCycle functions are not thread safe. For now, I
removed that exception and I simply call EndCycle functions in the main
thread.  It might be possible to improve things a little by moving some
of the functionality of EndCycle function into the surprisingly unused
SenseAgent/ActAgent functions!</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Finally, I'm still
unable to use an external monitor in multi-threaded mode. So currently
I run the external monitor in single threaded mode. I didn't
investigate it.<br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">4) What's the reason
for stepping in discreet steps in  SimulationServer::Step()? I think
that it wouldn't change anything for  GameControlServer, but what about
the scene server?! Will it change anything with ODE?</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">5) As reported in
sserver mailing list, simulation is more stable with ODE 9.0, but much
performance improvement is needed. On my system (AMD 3000+) with 6
agents, each simulation step (using non-discreet steps) needs around
0.04s.</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">6) I ran a profiling
test of the server right now, and it seems that (well, it was my first
experience with callgrind!) dWorldStep is really a bottleneck. It might
be related to the current robot model...<br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Good luck,</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Hedayat<br>
</p>
</body>
</html>

Re: [simspark-devel] replacing ode

[Hesham <hes...@gm...>]

SGkgSGVkYXlhdCwKCk9uIDIzLzA5LzIwMDcsIEhlZGF5YXQgVmF0YW5raGFoIDxoZWRheWF0dmtA
YWltLmNvbT4gd3JvdGU6Cj4KPiAgSGkgSGVzaGFtLAo+IFVuZm9ydHVuYXRlbHksIEkgZG9uJ3Qg
aGF2ZSBhbnkgdGltZSB1bnRpbCBGZWJydWFyeSBvciBKYW51YXJ5IHRvIHNwZW5kIG9uCj4gaXQ6
KCAuSSByZWFsbHkgbGlrZWQgdG8gaGVscC4KPgoKVGhhdCdzIE9LLCBhbnl3YXkgdGhhbmtzLiBB
bmQgSSB0aGluayBmcm9tIGFyb3VuZCBKYW51YXJ5IHRoZSBkZXZlbG9wbWVudCBvZgp0aGUgc2Vy
dmVyIHdpbGwgYmUgbW9yZSBzZXJpb3VzLgoKQ3VycmVudGx5LCBJIGRvbid0IGtub3cgYW55dGhp
bmcgYWJvdXQgSURCUywgYnV0IGl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvCj4gY3JlYXRlIGFic3Ry
YWN0IHR5cGVzIGZvciBwaHlzaWNzIGVuZ2luZXMuIFRoZW4sIGl0J2xsIGJlIGV2ZW50IHBvc3Np
YmxlIHRvCj4gc2VsZWN0IHRoZSBkZXNpcmVkIGVuZ2luZSBhdCBydW50aW1lLgo+CgpHcmVhdCBp
ZGVhLCAgSSB3aWxsIHRyeSB0byBpbXBsZW1lbnQgdGhlIGZpcnN0IHZlcnNpb24gaW4gdGhpcyB3
ZWVrZW5kLgoKQmVzdHMsCkhlc2hhbQoKR29vZCBsdWNrLAo+IEhlZGF5YXQKPgo+ICpIZXNoYW0g
PGhlc2hhbWVicmFoaW1pQGdtYWlsLmNvbT4gPGhlc2hhbWVicmFoaW1pQGdtYWlsLmNvbT4qIHdy
b3RlIG9uCj4g27Dbty/bsNu5L9uy27MgMDU6MzU6NTE6Cj4KPgo+IEhpIGFsbCwKPgo+IFRoZSBv
dGhlciB3ZWVrLCBJIGNhbWUgYWNyb3NzIElEQlMgbGlicmFyeSwgaHR0cDovL3d3dy5pbXB1bHNl
LWJhc2VkLmRlLy4KPiBJJ3ZlIHJlYWQgdGhlIGRvY3VtZW50YXRpb24gYW5kIHRoZSBjb2RlLCBh
cyB5b3UgbWF5IGFscmVhZHkga25vdyBhcHBhcmVudGx5Cj4gd2UgY2FuIHJlcGxhY2UgT0RFIHdp
dGggdGhpcyBsaWJyYXJ5IGVhc2lseSBhbmQgd2Ugd2lsbCBwcm9iYWJseSBnZXQgcmlkIG9mCj4g
dGhlIGN1cnJlbnQgcHJvYmxlbXMgd2l0aCBPREUuIEkgd2FzIHdvbmRlcmluZyBob3cgd2UgY2Fu
IGtlZXAgT0RFIGFuZCBhZGQKPiBJREJTLCBhbmQgYXQgY29tcGlsZSB0aW1lIHNwZWNpZnkgd2hp
Y2ggb25lIHNob3VsZCBiZSB1c2VkLiBJIHRob3VnaHQgb2YKPiBtb2RpZnlpbmcgdGhlIGZ1bmN0
aW9ucyBvZiBveHlnZW4vcGh5c2ljc3NlcnZlciBhbmQgdXNpbmcgYSBtYWNyby4gQnV0IEkKPiBz
dXBwb3NlIGl0IHdpbGwgYmUgYSBtZXNzLiBXaGF0IGRvIHlvdSBzdWdnZXN0Pwo+Cj4gSSdtIGJ1
c3kgd2l0aCBteSB0aGVzaXMgdW50aWwgMTIgT2N0b2Jlciwgc28gdW50aWwgdGhlbiBJIHdvcmsg
b24gdGhpcwo+IG9ubHkgaW4gd2Vla2VuZHMuIFNvIGFueWJvZHkgY2FuIGhlbHA/IE1heWJlIGJ5
IHRoZSBlbmQgb2YgT2N0b2Jlciwgd2UgY2FuCj4gaGF2ZSBJREJTIGluIHRoZSBzZXJ2ZXIuCj4K
PiBCZXN0cywKPiBIZXNoYW0KPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj4g
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQo+IFRoaXMgU0YubmV0IGVtYWlsIGlzIHNwb25zb3JlZCBieTogTWlj
cm9zb2Z0Cj4gRGVmeSBhbGwgY2hhbGxlbmdlcy4gTWljcm9zb2Z0KFIpIFZpc3VhbCBTdHVkaW8g
MjAwNS4KPiBodHRwOi8vY2xrLmF0ZG10LmNvbS9NUlQvZ28vdnNlMDEyMDAwMDA3MG1ydC9kaXJl
Y3QvMDEvCj4KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KPgo+IF9fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gU2ltc3BhcmsgR2VuZXJpYyBQ
aHlzaWNhbCBNQVMgU2ltdWxhdG9yCj4gc2ltc3BhcmstZGV2ZWwgbWFpbGluZyBsaXN0Cj4gc2lt
c3BhcmstZGV2ZWxAbGlzdHMuc291cmNlZm9yZ2UubmV0Cj4gaHR0cHM6Ly9saXN0cy5zb3VyY2Vm
b3JnZS5uZXQvbGlzdHMvbGlzdGluZm8vc2ltc3BhcmstZGV2ZWwKPgo+Cg==

Re: [simspark-devel] replacing ode

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
Hi Hesham,<br>
Unfortunately, I don't have any time until February or January to spend
on it:( .I really liked to help.<br>
<br>
Currently, I don't know anything about IDBS, but it might be possible
to create abstract types for physics engines. Then, it'll be event
possible to select the desired engine at runtime. <br>
<br>
Good luck,<br>
Hedayat<br>
<span><br>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;}  blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important}  blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important}  blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important}  blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>Hesham
<a class="moz-txt-link-rfc2396E" href="mailto:hes...@gm...">&lt;hes...@gm...&gt;</a></b></i> wrote on ۰۷/۰۹/۲۳ 05:35:51:</span><br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:1d7...@ma..."   type="cite"><br>
Hi all,<br>
  <br>
The other week, I came across IDBS library, <a moz-do-not-send="true"   href="http://www.impulse-based.de/" target="_blank"   onclick="return top.js.OpenExtLink(window,event,this)">http://www.impulse-based.de/</a>.
I've read the documentation and the code, as you may already know
apparently we can replace ODE with this library easily and we will
probably get rid of the current problems with ODE. I was wondering how
we can keep ODE and add IDBS, and at compile time specify which one
should be used. I thought of modifying the functions of
oxygen/physicsserver and using a macro. But I suppose it will be a
mess. What do you suggest?
  <br>
  <br>
I'm busy with my thesis until 12 October, so until then I work on this
only in weekends. So anybody can help? Maybe by the end of October, we
can have IDBS in the server.<br>
  <br>
Bests,<br>
Hesham<br>
  <br>
  <pre wrap="">
<hr size="4" width="90%">
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
<a class="moz-txt-link-freetext" href="http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/">http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/</a>
  </pre>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Simspark Generic Physical MAS Simulator
simspark-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sim...@li...">sim...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/simspark-devel">https://lists.sourceforge.net/lists/listinfo/simspark-devel</a>
  </pre>
</blockquote>
</body>
</html>

[simspark-devel] replacing ode

[Hesham <hes...@gm...>]

Hi all,

The other week, I came across IDBS library, http://www.impulse-based.de/.
I've read the documentation and the code, as you may already know apparently
we can replace ODE with this library easily and we will probably get rid of
the current problems with ODE. I was wondering how we can keep ODE and add
IDBS, and at compile time specify which one should be used. I thought of
modifying the functions of oxygen/physicsserver and using a macro. But I
suppose it will be a mess. What do you suggest?

I'm busy with my thesis until 12 October, so until then I work on this only
in weekends. So anybody can help? Maybe by the end of October, we can have
IDBS in the server.

Bests,
Hesham

[simspark-devel] ClearPlayers problem reminder!

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

Hi again,

I just want to remind the ClearPlayers problem: it might move an agent 
to a position where another player is standing, which will cause the 
simulation to be stopped almost completely! Unfortunately, I don't have 
enough time to work on this currently.


Good Luck,

Hedayat

[simspark-devel] Fwd: new problem of new server

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

Hi,


> Nonetheless, it looks like your changes about effectors not moving
> joints at the angle limits and restricting the velocity will be
> accepted. Therefore, could you please commit your changes so that I can
> include them in the final release today?
>

I have just committed my changes.
But I think there still a small bug in the soccerbot.rsg line 139
(def $Lae2Min 1)
==>
(def $Lae2Min -1)

In the current setting, the 0 degree (initial angle) is not in the
allowed range.


--
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] contrast of flag_left*.rsg and flag_right*.rsg

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

Hi Jan,

Thanks a lot!
I spend too much time in the localization today...

>
> You're right, this was not intended. ;-)
>
> The intention was to move just the visualization, because if a team gets
> a corner kick, the ball was placed inside the flag pole.
>
> For the agents the flags should still mark the corners of the field.
>


-- 
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] contrast of flag_left*.rsg and flag_right*.rsg

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

Hi Yuan,

Yuan Xu wrote:
> Hi Joschka,
> 
> While using the cvs server, I was confused by the flag position ;-(
> 
> In the vision perception position of left flags are the same as visualization,
> but the right flags are still at the corner of the field.
> That is because the files are different:
> In flag_left*.rsg the ObjectState node is the grandchild of the flag,
> in flag_right*.rsg the ObjectState node is the child of the flag.
> 
> I think it is not the intended, so what is expectation ?

You're right, this was not intended. ;-)

The intention was to move just the visualization, because if a team gets 
a corner kick, the ball was placed inside the flag pole.

For the agents the flags should still mark the corners of the field.


Jan

[simspark-devel] contrast of flag_left*.rsg and flag_right*.rsg

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

Hi Joschka,

While using the cvs server, I was confused by the flag position ;-(

In the vision perception position of left flags are the same as visualization,
but the right flags are still at the corner of the field.
That is because the files are different:
In flag_left*.rsg the ObjectState node is the grandchild of the flag,
in flag_right*.rsg the ObjectState node is the child of the flag.

I think it is not the intended, so what is expectation ?

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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