simspark-devel Mailing List for Spark - A generic physical simulator (Page 28)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi all,

I prepared the preview of rcssserver3d-0.5.7,
could you download it from
http://xuyuan.cn.googlepages.com/rcssserver3d-0.5.7-preview.tar.gz
and test it?

Thanks!
Xu Yuan

Hi,

/*Markus Rollmann <rol...@un...>*/ wrote on 03/20/2008 
09:22:33 PM:
> Hi,
>
> Hedayat Vatankhah wrote:
> [...]
>> gettingstarted.tex: in Fedora, all of the simspark requirements are 
>> available in the official Fedora repository. ...
>
> yes, that would be nice. I'll include this into the 'getting started' 
> guide.
OK! But before that: Freeglut is no longer a requirement. It was used 
for the old rcssmonitor3d-lite and it is optional now (in the latest CVS 
version). So I don't include it here:

The command to install all of the requirements is:
yum install gcc-c++ ruby ruby-devel boost-devel SDL-devel freetype-devel 
libtool tetex-latex cvs libtiff-devel slang-devel ode-devel DevIL-devel

Notice that most of the above packages are available in the Fedora 
installation DVD. The only exceptions which will be downloaded from the 
internet are:
ruby-devel
ode-devel
DevIL-devel

In the above lists, I've excluded the packages which will be installed 
as requirements automatically by yum. If anybody wants to install the 
packages manually (for example if he had no internet connection in 
Linux), he should get the following RPM packages from an official Fedora 
repository (assuming that he'll install other packages from the 
installation DVD):
ruby-devel
ode
ode-devel
DevIL
DevIL-devel

To build and run rsgedit, the following command should be used:
yum install wxGTK-gl

(The packages which should be downloaded in case of manual installation 
without yum: wxGTK, wxGTK-devel, wxGTK-gl)

Finally, notice that the official ode packages do not use double 
precision. If double precision is required (I'm still using the official 
packages!), ode should be installed from source tar balls or by 
rebuilding ode rpms from it's SRPM with the required flags. (I'll create 
ODE RPM packages with double precision enabled for the coming server 
release)

>> ...
>
> that's a good question. The TouchPerceptor for example does send 'val 0'
> while no collision is detected. So this perceptor does send data when no
> collision is detected.
>
> We should decide for one behavior for all sensors. I'd say where
> possible keep silence (saving bandwith...)
Yes, it seems that it is good. Except if it can be problematic for teams 
(?!!). Specially, with more perceptors in future, the omitted portions 
could be significant. So, I won't change FRP now. Any other opinions?

> [...]
>> And for joint effectors, the unit of passed parameter is the desired
>> speed of the motor in Rads/sec (but it seems that it should be
>> changed to degrees/sec like the perceptors. right
>
> I agree that using degrees/sec might be more convenient. But changing 
> this causes trouble for existing agent implementations as they still 
> expect rads/sec, so their agent implementation fails silently (i.e. 
> without an obvious error).
>
> To change this we must also change the message format of the effector 
> to make it clear that degrees/sec are expected and still support the 
> current message format. I don't know if this is worth the trouble 
> though...
I have not any special preference here, just to make the units 
consistent with the joint perceptors.

Thanks,
Hedayat

>
> cheers,
> Markus
>

Hi,

Hedayat Vatankhah wrote:
[...]
> gettingstarted.tex: in Fedora, all of the simspark requirements are 
> available in the official Fedora repository. So, they can be
> installed with a "yum install" command in a default Fedora
> installation with internet access. I can provide the exact command if
> there is any interest about it.

yes, that would be nice. I'll include this into the 'getting started' guide.

[...]
> (A question: currently, the FRP perceptor doesn't generate anything
> when there is no contact. Should it send zero force and center
> vectors in these situations?!)

that's a good question. The TouchPerceptor for example does send 'val 0'
while no collision is detected. So this perceptor does send data when no
collision is detected.

We should decide for one behavior for all sensors. I'd say where
possible keep silence (saving bandwith...)

[...]
> And for joint effectors, the unit of passed parameter is the desired
> speed of the motor in Rads/sec (but it seems that it should be
> changed to degrees/sec like the perceptors. right

I agree that using degrees/sec might be more convenient. But changing 
this causes trouble for existing agent implementations as they still 
expect rads/sec, so their agent implementation fails silently (i.e. 
without an obvious error).

To change this we must also change the message format of the effector to 
make it clear that degrees/sec are expected and still support the 
current message format. I don't know if this is worth the trouble though...

cheers,
Markus

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
Hi all,
These are some comments
about the simspark documents:
user docs:
gettingstarted.tex: in
Fedora, all of the simspark requirements are available in the official
Fedora repository. So, they can be installed with a "yum install"
command in a default Fedora installation with internet access. I can
provide the exact command if there is any interest about it. (Also,
with rpm package for simspark, a "yum localinstall
rcssserver3d-{version}.rpm" should install all of the required packages
(excluding development packages needed for server compilation.)
 

(Currently, the RPM
package is an all-in-one package. Hopefully, I'll split it to more
packages (such as simspark-libs, simspark-devel, soccer, soccer-devel,
rsgedit, simspark-docs, soccer-docs, etc!)
 

simspark.tex:
Yes, Gyro perceptor
uses the body's local coordinates.
Joschka's comments
about FRP calculation are correct. About the force unit, I can't find
anything about it in ODE docs, but it should be the standard unit
(newton).
 

(A question: currently,
the FRP perceptor doesn't generate anything when there is no contact.
Should it send zero force and center vectors in these situations?!) 

 

And for joint
effectors, the unit of passed parameter is the desired speed of the
motor in Rads/sec (but it seems that it should be changed to
degrees/sec like the perceptors. right?)
 

Good luck,
Hedayat 

</body>
</html>

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
Hi all,
As you may know it already, ode 0.9 can use GIMPACT for collision
detection instead of OPCODE. According to ode change log, GIMPACT is
faster than OPCODE. It can be selected by using --with-trimesh=gimpact
as a parameter to configure (notice that double precision should not be
enabled since currently it is not supported when gimpact is enabled). 
 
It would be nice if somebody could check it to see if it improves
server performance. I'll try to do it ASAP also. 
 
Cheers, 
Hedayat 
 
</body>
</html>

Hi Sander,

On Mar 12, 2008, at 5:40 AM, Sander van Dijk wrote:

> Glad to see it works well! I have put together a quick binary of  
> basically our agent used in Atlanta, but with the possibility to use  
> a different rsg file. I placed it at http://www.ai.rug.nl/~sgdijk/batscomptest20080311.tar.gz 
> . Run it using:

Great, thanks a lot!

> I get some questions about the latex documentation at the end of the  
> make process, if I answer those with X he just goes on and finishes  
> compiling.

What errors do you get there?

Cheers,
Joschka

Hi all,

On 12/03/2008, at 12:04 AM, Joschka Boedecker wrote:

> I just tested the current CVS version including Sander's changes. I
> only ran a simple test with 10 agentspark agents, but everything on
> one machine (Mac Pro). The simulation was running very smoothly, no
> LCP errors or time skipping messages for the most part; I only got
> time skips towards the end of the "game", but the values very quite
> small (sth. like 0.004) and there was a lot of console output from the
> talkative agentspark agents ;-)

> Other than that, great work Sander! :-D

I agree, sounds great :-) (maybe in RoboCup '09 simleague can be held  
on Macs ;-)

I've just read that the all new gcc has optimisation flags for core 2  
CPU's, this might give an extra bit of performance. ("Tuning for Intel  
Core 2 processors is available via -mtune=core2 and -march=core2." http://gcc.gnu.org/gcc-4.3/changes.html)

keep up the good work everyone ;-)
Oliver

Hey Sander,

On Mar 6, 2008, at 8:22 PM, Sander van Dijk wrote:

> On Mar 3, 2008, at 6:23 AM, Sander van Dijk wrote:
>
> > On Sat, Mar 1, 2008 at 12:55 PM, Joschka Boedecker <
> > jos...@am...> wrote:
> >
> >> I think we don't actually have an established
> >> protocol yet. Tagging the target branch before and after the merge
> >> sounds reasonable I think. Any other opinions?
> >>
> >
> > I think tagging the branch after merging with the trunk is good too,
> > when
> > development on that branch might continue.
>
> Yes, I agree.
>
> > This way on a second merge you
> > can easily apply only new changes, see [1] point 4.
>
> Sorry, the reference was missing ;-)
>
> Oops that was supposed to be http://smb.slac.stanford.edu/research/developments/blu-ice/dcsAdmin/node7.html 
> .

OK, thank you.

> Concerning naming the branches, I don't think we had anything
> established there either. Do you have a suggestion for a standard from
> now on?
>
>
> How about something like:
>
> tag trunk before branching: BRANCHNAME_base
> tag trunk before merge: BRANCHNAME_premergeN
> tag trunk after merge: BRANCHNAME_postmergeN
> tag branch after merge: BRANCHNAME_mergedN
>
> where N is the number of the merge.

This sounds good.

> Looking around on the web you come along a lot of different  
> conventions for the BRANCHNAME itself: including the project name,  
> version number of the base it branched of, branching date, etc. IMHO  
> these aren't really necessary if you tag at the points I mentioned  
> above, because then I think it isn't too hard to deduce the extra  
> data.

I agree. Usually we just chose a name that let's deduce some  
information about what is going on in the branch, e.g. like win32 for  
the windows implementation.

> However, perhaps including BRANCH or just a B or something makes it  
> easier to identify branches in the list of CVS symbolic names.

OK good, so we would choose sth. like WIN32_BRANCH_merged2 for the  
above example after merging back for the second time, right?
Let's document this in the new developer's manual also.

Thanks,
Joschka

Hi,

Glad to see it works well! I have put together a quick binary of basically
our agent used in Atlanta, but with the possibility to use a different rsg
file. I placed it at
http://www.ai.rug.nl/~sgdijk/batscomptest20080311.tar.gz. Run it using:

./humanoidbat -c lgb.xml -r soccerbotcomp.rsg -u 1 -t TEAMNAME

where -r gives the rsg file to use, -u gives the uniform number and -t the
teamname. using

./humanoidbat -c lgb.xml

defaults to -r soccerbot056.rsg -u 0 -t BATS. On my system (Intel(R)
Core(TM)2 CPU 6400  @ 2.13GHz, NVidia GeForce 7600GT) I can run 3vs3
smoothly, with some skipping time messages occuring when 3 or more agents
form a pile (with the 056 model they occur at every agent contact, often
resulting in LCP errors). With 4vs4 I get skipping time messages all the
time, but simulation still seems stable.

@Sahar: what kind of errors do you get? I get some questions about the latex
documentation at the end of the make process, if I answer those with X he
just goes on and finishes compiling.

Sander

On Tue, Mar 11, 2008 at 8:25 PM, Sahar Asadi <sah...@gm...> wrote:

> Hi Joschka,
>
> wow, great :-)
> I wanted to run the CVS version and I got errors in installation. Then I
> became busy with qualification till now. But I try to do the test also (on
> network if I can).
>
> I have binaries from Atlanta but they are not with the new agent.
>
> Best,
> Sahar
>
>
> On Tue, Mar 11, 2008 at 4:34 PM, Joschka Boedecker <
> jos...@am...> wrote:
>
> > Hi Sander, hi all,
> >
> > I just tested the current CVS version including Sander's changes. I
> > only ran a simple test with 10 agentspark agents, but everything on
> > one machine (Mac Pro). The simulation was running very smoothly, no
> > LCP errors or time skipping messages for the most part; I only got
> > time skips towards the end of the "game", but the values very quite
> > small (sth. like 0.004) and there was a lot of console output from the
> > talkative agentspark agents ;-)
> >
> > It would be nice to test with more advanced agents; can someone
> > provide a binary that uses the new soccerbotcomp.rsg file, please?
> >
> > Other than that, great work Sander! :-D
> >
> > Cheers,
> > Joschka
> >
>
>

Hi Joschka,

wow, great :-)
I wanted to run the CVS version and I got errors in installation. Then I
became busy with qualification till now. But I try to do the test also (on
network if I can).

I have binaries from Atlanta but they are not with the new agent.

Best,
Sahar

On Tue, Mar 11, 2008 at 4:34 PM, Joschka Boedecker <
jos...@am...> wrote:

> Hi Sander, hi all,
>
> I just tested the current CVS version including Sander's changes. I
> only ran a simple test with 10 agentspark agents, but everything on
> one machine (Mac Pro). The simulation was running very smoothly, no
> LCP errors or time skipping messages for the most part; I only got
> time skips towards the end of the "game", but the values very quite
> small (sth. like 0.004) and there was a lot of console output from the
> talkative agentspark agents ;-)
>
> It would be nice to test with more advanced agents; can someone
> provide a binary that uses the new soccerbotcomp.rsg file, please?
>
> Other than that, great work Sander! :-D
>
> Cheers,
> Joschka
>

Hi Sander, hi all,

I just tested the current CVS version including Sander's changes. I  
only ran a simple test with 10 agentspark agents, but everything on  
one machine (Mac Pro). The simulation was running very smoothly, no  
LCP errors or time skipping messages for the most part; I only got  
time skips towards the end of the "game", but the values very quite  
small (sth. like 0.004) and there was a lot of console output from the  
talkative agentspark agents ;-)

It would be nice to test with more advanced agents; can someone  
provide a binary that uses the new soccerbotcomp.rsg file, please?

Other than that, great work Sander! :-D

Cheers,
Joschka

Hi all,

I created an outline for a FAQ page concerning Simspark in the Wiki  
[1]. It would be great if you could help to fill in the information,  
and/or add things that you feel are missing. In order to edit the  
pages, you need to have an account and be logged in.

Thanks a lot!

Joschka

[1] http://simspark.sourceforge.net/wiki/index.php/FAQ

<!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">
<p><span>Hi Yuan,</span></p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><span></span></p>
<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>Hedayat
Vatankhah <a class="moz-txt-link-rfc2396E"   href="mailto:hed...@ai...">&lt;hed...@ai...&gt;</a></b></i>
wrote on 03/09/2008
10:45:48 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:47D...@ai..." type="cite">
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <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>"Yuan
Xu" <a moz-do-not-send="true" class="moz-txt-link-rfc2396E"   href="mailto:xuy...@gm...">&lt;xuy...@gm...&gt;</a></b></i>
wrote on 03/09/2008 12:19:22 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="">[...]
 I attached the testing server to this mail, could you test it in your system?
  </pre>
  </blockquote>
OK, I'll test it ASAP. Interesting!<br>
</blockquote>
Unfortunately, it doesn't work on my system :(<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:47D...@ai..." type="cite">
  <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=""> There is another issue should be in mind is that
 the multi-threads increase the sense act latency,
 it makes agent behavior unlike in the singled-thread.
 I think this will make teams in trouble while changing from
 singled-thread to multi-threads.
 What do you think about it?  </pre>
  </blockquote>
Sorry, would you please explain more about the reason of this increased
latency? In both single threaded and multi-threaded modes StartCycle()
is called immediately after EndCycle(). What increases the latency?<br>
</blockquote>
OK! I read the code and understood what you said. Yes, the variable
latency is not desirable specially that it is not predictable :(<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:47D...@ai..." type="cite">And another question:
it seems that it is enough to call
SceneServer::Pre/PostPhysicsUpdate() functions once in a cycle. So, we
can apply the same change in Step() for single threaded mode (to call
PhysicsUpdate() function inside it's while loop instead of Update()
function and calling Pre/PostPhysicsUpdate() functions (and
GameControlServer::Update()) outside the while loop); right? It should
benefit performance a little.<br>
</blockquote>
Another thing: PrePhysicsUpdate received a deltaTime parameter. But
currently, it is called once per cycle in RunMultiThreaded. We should
either remove the parameter (I'm not sure but it might be unused!) or
put it inside the PhysicsUpdate while loop. Which one is better?<br>
<br>
Thanks,<br>
Hedayat<br>
<blockquote   style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"   cite="mid:47D...@ai..." type="cite"> <br>
Thanks a lot,<br>
Hedayat<br>
  <br>
</blockquote>
</body>
</html>

<!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><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 03/09/2008 12:19:22 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 Hedayat and all,

</pre>
</blockquote>
Hi! 
 
<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="">
The rcssserver3d-0.5.6 can run multi-threads in my computer, it does
 not need to call opengl in the main thread. but the cvs head code
 can't.
 It is very strange, so I decide to look into this problem.

Because there are too many differences between cvs head and 0.5.6,
 I copy the barrier implementation to the rcssserver3d-0.5.6,
 then it works! while calling opengl in a new thread.
 I attached the testing server to this mail, could you test it in your system?
 </pre>
</blockquote>
OK, I'll test it ASAP. Interesting! 
 
<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=""> There is another issue should be in mind is that
 the multi-threads increase the sense act latency,
 it makes agent behavior unlike in the singled-thread.
 I think this will make teams in trouble while changing from
 singled-thread to multi-threads.
 What do you think about it?
 </pre>
</blockquote>
Sorry, would you please explain more about the reason of this increased
latency? In both single threaded and multi-threaded modes StartCycle()
is called immediately after EndCycle(). What increases the latency? 
 
And another question: it seems that it is enough to call
SceneServer::Pre/PostPhysicsUpdate() functions once in a cycle. So, we
can apply the same change in Step() for single threaded mode (to call
PhysicsUpdate() function inside it's while loop instead of Update()
function and calling Pre/PostPhysicsUpdate() functions (and
GameControlServer::Update()) outside the while loop); right? It should
benefit performance a little. 
 
Thanks a lot, 
Hedayat 
 
</body>
</html>

Hi Hedayat and all,

 >
 >  Yes :(. But Mesa might be thread safe now. Since I've installed nvidia
 > binary drivers, simspark uses nvidia OpenGL libraries instead of using Mesa.
 > So, I can't say anything about mesa, but nvidia opengl is not thread safe.
 >

The rcssserver3d-0.5.6 can run multi-threads in my computer, it does
 not need to call opengl in the main thread. but the cvs head code
 can't.
 It is very strange, so I decide to look into this problem.

 Because there are too many differences between cvs head and 0.5.6,
 I copy the barrier implementation to the rcssserver3d-0.5.6,
 then it works! while calling opengl in a new thread.
 I attached the testing server to this mail, could you test it in your system?

 So, the problem may caused by other changes relative to opengl,
 I tested and compared the of functions in class rendercontrol and
 rendernode, they should be OK.
 Thus, I think the problem may caused by the initialization of opengl,
 but the ruby scripts are changed a lot, I do not have time to trace them now.

 >
 >  The interesting (not much!) point is that I have not encountered any
 > problems by calling mSceneServer->PrePhysicsUpdate() in
 > parallel till now! Is there any conflicts between
 > mSceneServer->PrePhysicsUpdate() and EndCycle() functions
 > in the current code?!
 >

I am not sure, but they may conflict after future changing.
 I changes a little with your code.( See the package attached.)
 I hope it would be OK.

 There is another issue should be in mind is that
 the multi-threads increase the sense act latency,
 it makes agent behavior unlike in the singled-thread.
 I think this will make teams in trouble while changing from
 singled-thread to multi-threads.
 What do you think about it?

 --
 Best wishes!

 Xu Yuan
 School of Automation
 Southeast University, Nanjing, China

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

<!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 03/08/2008 08:27:05 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,

Thanks for your reply.
[...]
GameControlServer should be updated after the PostPhysicsUpdate.
So the loop of the main thread should be:
mSceneServer-&gt;PrePhysicsUpdate
mSceneServer-&gt;PhysicsUpdate
mSceneServer-&gt;PostPhysicsUpdate
GameControlServer-&gt;Update
  </pre>
</blockquote>
Done. Thanks! <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">
  <blockquote type="cite">
    <pre wrap=""> I'm using Mesa 7.0.1 with nvidia binary driver 169.09 and the problem still
exists.
 Yes, the main reason was rendering, but there is another problem too. FRP
sensor calls dJointGetFeedback(). ODE is not thread safe and this call will
generate segmentation faults some times. Also, this call should happen
before next physics update since the feedback information will not be
available then (I think!).
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Bad news, the OpenGL should be thread-safe.
  </pre>
</blockquote>
Yes :(. But Mesa might be thread safe now. Since I've installed nvidia
binary drivers, simspark uses nvidia OpenGL libraries instead of using
Mesa. So, I can't say anything about mesa, but nvidia opengl is not
thread safe.<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="">
You can call dJointGetFeedback() in PostPhysicsUpdateInternal(), and
cache the feedback information.
It just likes cache the actions and realize them in PrePhysicsUpdateInternal().
  </pre>
</blockquote>
<br>
Good suggestion. I never liked creating feedback structs using new, and
I've changed the code so the dJointFeedbacks are now stored inside
ForceResistancePerceptor and no ODE calls are necessary anymore. It
solved the problem.<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=""><!---->
Ah, I see! It is OK, and much simpler and clear than the old code, great job!
  </pre>
</blockquote>
Thanks! :)<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="">But there may be a small problem in current code:
The scene tree should not be accessed by the main thread and
SimCtrThreads at the same time.
(May be the problem will come after you remove the Step().)
So when call the follow functions, the SimCtrThreads should be blocked.
mSceneServer-&gt;PrePhysicsUpdate
mSceneServer-&gt;PostPhysicsUpdate
GameControlServer-&gt;Update
So the lines in RunMultiThreaded() needs adjustment, I think it is easy for you.
  </pre>
</blockquote>
I thought that I can call mSceneServer-&gt;PrePhysicsUpdate() in
parallel :(. This is really bad! This function should be called after
EndCycle() functions which run in parallel now. So, protecting
mSceneServer-&gt;PrePhysicsUpdate() needs two more wait() calls. I
wonder if this can be worse than calling EndCycle() and
mSceneServer-&gt;PrePhysicsUpdate() functions in the main thread!<br>
<br>
The interesting (not much!) point is that I have not encountered any
problems by calling mSceneServer-&gt;PrePhysicsUpdate() in parallel
till now! Is there any conflicts between
mSceneServer-&gt;PrePhysicsUpdate() and EndCycle() functions in the
current code?! <br>
<br>
I've committed my changes. Any suggestions/comments are highly
appreciated!<br>
<br>
Thanks,<br>
Hedayat<br>
</body>
</html>

Hi Hedayat,

Thanks for your reply.

>  You should know better than me. When I was writing the code, my main focus
> was on correctness. I was not sure about those functions and I didn't look
> further to see if they are redundant. I decided to wait for people who know
> it already! :). Yes, regarding to your description about
> Pre/PostPhysicsUpdate() functions, it seems that they are redundant. So, if
> updating GameControlServer is unnecessary too, Step() can be removed and
> using mSceneServer->PhysicsUpdate(mSimStep) before call to
> PostPhysicsUpdate() (with all required time calculations) should be enough.
>  So, please let me know if updating GameControlServer is necessary and I'll
> remove redundant calls. I have not investigated it thoroughly, but it seems
> that there is no need to update GameControlServer here. Am I right?

GameControlServer should be updated after the PostPhysicsUpdate.
So the loop of the main thread should be:
mSceneServer->PrePhysicsUpdate
mSceneServer->PhysicsUpdate
mSceneServer->PostPhysicsUpdate
GameControlServer->Update

>  I'm using Mesa 7.0.1 with nvidia binary driver 169.09 and the problem still
> exists.
>  Yes, the main reason was rendering, but there is another problem too. FRP
> sensor calls dJointGetFeedback(). ODE is not thread safe and this call will
> generate segmentation faults some times. Also, this call should happen
> before next physics update since the feedback information will not be
> available then (I think!).

Bad news, the OpenGL should be thread-safe.

You can call dJointGetFeedback() in PostPhysicsUpdateInternal(), and
cache the feedback information.
It just likes cache the actions and realize them in PrePhysicsUpdateInternal().

>
>  I don't think so. As far as I know, it is just another synchronization
> method. It doesn't affect thread execution model and they run in parallel.
> The only thing which it does is in it's wait function. According to boost
> docs:
> [...]
>
>  As all of the threads will be placed in a ready state, they should run in
> parallel. Please correct me if I'm wrong.
>

Ah, I see! It is OK, and much simpler and clear than the old code, great job!
But there may be a small problem in current code:
The scene tree should not be accessed by the main thread and
SimCtrThreads at the same time.
(May be the problem will come after you remove the Step().)
So when call the follow functions, the SimCtrThreads should be blocked.
mSceneServer->PrePhysicsUpdate
mSceneServer->PostPhysicsUpdate
GameControlServer->Update
So the lines in RunMultiThreaded() needs adjustment, I think it is easy for you.

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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

<!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><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 03/07/2008 11:59:43 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 and all,

I take a look at current multi-thread implementation.
 </pre>
</blockquote>
Hi Yuan, 
Thanks a lot for looking at the code and for your comments. 
 
<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="">But I can not understand it exactly, could you help me?

1). in simulationserver.cpp
00491 Step();
00492 ControlEvent(CE_EndCycle);
The Step() calls mSceneServer-&gt;Pre/PostPhysicsUpdate() again,
I think it is redundant, what should be called maybe
mSceneServer-&gt;PhysicsUpdate(mSimStep),
right?
 </pre>
</blockquote>
You should know better than me. When I was writing the code, my main
focus was on correctness. I was not sure about those functions and I
didn't look further to see if they are redundant. I decided to wait for
people who know it already! :). Yes, regarding to your description
about Pre/PostPhysicsUpdate() functions, it seems that they are
redundant. So, if updating GameControlServer is unnecessary too, Step()
can be removed and using mSceneServer-&gt;PhysicsUpdate(mSimStep)
before call to PostPhysicsUpdate() (with all required time
calculations) should be enough. 
So, please let me know if updating GameControlServer is necessary and
I'll remove redundant calls. I have not investigated it thoroughly, but
it seems that there is no need to update GameControlServer here. Am I
right? 
 
<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="">
Place ControlEvent(CE_EndCycle) here is for rendering function in the
main thread?
The original code 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-ﬁxes of thread
safe in Mesa-6.5.
Can you test that?
 </pre>
</blockquote>
I'm using Mesa 7.0.1 with nvidia binary driver 169.09 and the problem
still exists. 
Yes, the main reason was rendering, but there is another problem too.
FRP sensor calls dJointGetFeedback(). ODE is not thread safe and this
call will generate segmentation faults some times. Also, this call
should happen before next physics update since the feedback information
will not be available then (I think!). 
In fact, at first I decided to treat RenderControl as an exception (to
call its EndCycle() function in the main thread and other EndCycle
functions in their own thread), but because of the above problem I
decided to call all of them in the main thread. I put it in my TODO
list for future to consider a better implementation. 
 
<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="">
2). Synchronization by the barrier just make all the threads run one
by one, it is not the real parallel.
 </pre>
</blockquote>
I don't think so. As far as I know, it is just another synchronization
method. It doesn't affect thread execution model and they run in
parallel. The only thing which it does is in it's wait function.
According to boost docs: 
 
"When a barrier is created, it is initialized with a thread count N.
The first N-1 calls to <code class="computeroutput">wait()</code> will
all cause their threads to be blocked. The Nth call to <code class="computeroutput">wait()</code> will allow all of the waiting
threads, including the Nth thread, to be placed in a ready state. The
Nth call will also "reset" the barrier[...]. This functionality allows
the same set of N threads to re-use a barrier object to synchronize
their execution at multiple points during their execution." 
 
As all of the threads will be placed in a ready state, they should run
in parallel. Please correct me if I'm wrong. 
 
Thanks again, 
Hedayat 
 
<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="">The original idea is make SimControlNodes run parallel, and
PhysicsUpdate can also run at the same time.
Since the scene tree can be used as cache.
PrePhysicsUpdate copy data from scene tree to ODE, PosPhysicsUpdate
copy data from ODE to scene tree.
PhysicsUpdate only effects ODE internal data.

( To Joschka,
Sorry, I do not finished the document work about single-thread and multi-thread.
I want to make things clear firstly.)

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

Hi Hedayat and all,

I take a look at current multi-thread implementation.
But I can not understand it exactly, could you help me?

1). in simulationserver.cpp
00491             Step();
00492             ControlEvent(CE_EndCycle);
The Step() calls mSceneServer->Pre/PostPhysicsUpdate() again,
I think it is redundant, what should be called maybe
mSceneServer->PhysicsUpdate(mSimStep),
right?

Place ControlEvent(CE_EndCycle) here is for rendering function in the
main thread?
The original code 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-ﬁxes of thread
safe in Mesa-6.5.
Can you test that?

2). Synchronization by the barrier just make all the threads run one
by one, it is not the real parallel.
The original idea is make SimControlNodes run parallel, and
PhysicsUpdate can also run at the same time.
Since the scene tree can be used as cache.
PrePhysicsUpdate copy data from scene tree to ODE,  PosPhysicsUpdate
copy data from ODE to scene tree.
PhysicsUpdate only effects ODE internal data.

( To Joschka,
Sorry, I do not finished the document work about single-thread and multi-thread.
I want to make things clear firstly.)

-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

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

Hi,

On Wed, Mar 5, 2008 at 6:19 PM, Joschka Boedecker <
jos...@am...> wrote:

> Hey Sander,
>
> On Mar 3, 2008, at 6:23 AM, Sander van Dijk wrote:
>
> > Hi,
> >
> > On Sat, Mar 1, 2008 at 12:55 PM, Joschka Boedecker <
> > jos...@am...> wrote:
> >
> >> I think we don't actually have an established
> >> protocol yet. Tagging the target branch before and after the merge
> >> sounds reasonable I think. Any other opinions?
> >>
> >
> > I think tagging the branch after merging with the trunk is good too,
> > when
> > development on that branch might continue.
>
> Yes, I agree.
>
> > This way on a second merge you
> > can easily apply only new changes, see [1] point 4.
>
> Sorry, the reference was missing ;-)

Oops that was supposed to be
http://smb.slac.stanford.edu/research/developments/blu-ice/dcsAdmin/node7.html
.

Concerning naming the branches, I don't think we had anything
> established there either. Do you have a suggestion for a standard from
> now on?

How about something like:

tag trunk before branching: BRANCHNAME_base
tag trunk before merge: BRANCHNAME_premergeN
tag trunk after merge: BRANCHNAME_postmergeN
tag branch after merge: BRANCHNAME_mergedN

where N is the number of the merge.

Looking around on the web you come along a lot of different conventions for
the BRANCHNAME itself: including the project name, version number of the
base it branched of, branching date, etc. IMHO these aren't really necessary
if you tag at the points I mentioned above, because then I think it isn't
too hard to deduce the extra data. However, perhaps including BRANCH or just
a B or something makes it easier to identify branches in the list of CVS
symbolic names.

Regards,

Sander

Hey Sander,

On Mar 3, 2008, at 6:23 AM, Sander van Dijk wrote:

> Hi,
>
> On Sat, Mar 1, 2008 at 12:55 PM, Joschka Boedecker <
> jos...@am...> wrote:
>
>> I think we don't actually have an established
>> protocol yet. Tagging the target branch before and after the merge
>> sounds reasonable I think. Any other opinions?
>>
>
> I think tagging the branch after merging with the trunk is good too,  
> when
> development on that branch might continue.

Yes, I agree.

> This way on a second merge you
> can easily apply only new changes, see [1] point 4.

Sorry, the reference was missing ;-)

Concerning naming the branches, I don't think we had anything  
established there either. Do you have a suggestion for a standard from  
now on?

Cheers,
Joschka

Hi,

On Sat, Mar 1, 2008 at 12:55 PM, Joschka Boedecker <
jos...@am...> wrote:

> I think we don't actually have an established
> protocol yet. Tagging the target branch before and after the merge
> sounds reasonable I think. Any other opinions?
>

I think tagging the branch after merging with the trunk is good too, when
development on that branch might continue. This way on a second merge you
can easily apply only new changes, see [1] point 4.

Sander

Oops, ignore this. Stupid tab completion and similar addesses..

Sander

2008/2/29 Sander van Dijk <sgv...@gm...>:

> Het is ook tijd om te bespreken hoe we sponsoring gaan vinden. We (Mart,
> Jeroen, Gauke,Fons en ik) hebben hiervoor woensdag 5 maart 21:00 geprikt,
> bij mij thuis (Westerbadstraat 13) onder het genot van een biertje. Laat de
> rest ook ff weten of ie dan kan, weet ik hoeveel bier er moet komen ;-)
>
> Sander
>
>

Hi Sander,

On Feb 29, 2008, at 2:54 AM, Sander van Dijk wrote:

> I have aquestion about merging my branch with the CVS head. What is  
> the tagging protocol for the sserver repository? I have found  
> several systems (no tagging, tagging branch before merge to make  
> future merges easier, tag branch and target before and after  
> branching and merging..). What should I use and what naming style  
> should I use?

That's a good question, I think we don't actually have an established  
protocol yet. Tagging the target branch before and after the merge  
sounds reasonable I think. Any other opinions?

Cheers,
Joschka

Het is ook tijd om te bespreken hoe we sponsoring gaan vinden. We (Mart,
Jeroen, Gauke,Fons en ik) hebben hiervoor woensdag 5 maart 21:00 geprikt,
bij mij thuis (Westerbadstraat 13) onder het genot van een biertje. Laat de
rest ook ff weten of ie dan kan, weet ik hoeveel bier er moet komen ;-)

Sander

2005	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec (11)
2006	Jan	Feb (1)	Mar (6)	Apr (4)	May	Jun	Jul	Aug	Sep	Oct (2)	Nov (1)	Dec
2007	Jan	Feb (24)	Mar (19)	Apr (2)	May (45)	Jun (80)	Jul (1)	Aug	Sep (3)	Oct	Nov	Dec
2008	Jan (13)	Feb (57)	Mar (48)	Apr (71)	May (22)	Jun (26)	Jul (10)	Aug (1)	Sep	Oct (13)	Nov (21)	Dec (15)
2009	Jan (33)	Feb (36)	Mar (30)	Apr (8)	May (5)	Jun (29)	Jul (21)	Aug (4)	Sep (3)	Oct (9)	Nov (38)	Dec (17)
2010	Jan (13)	Feb (24)	Mar (18)	Apr (16)	May (13)	Jun (25)	Jul	Aug	Sep (4)	Oct	Nov (18)	Dec (2)
2011	Jan (2)	Feb (15)	Mar (15)	Apr (7)	May (16)	Jun	Jul (2)	Aug	Sep (4)	Oct (2)	Nov (4)	Dec (1)
2012	Jan (6)	Feb	Mar (9)	Apr (5)	May (1)	Jun	Jul	Aug	Sep (1)	Oct	Nov	Dec (2)
2013	Jan (4)	Feb (5)	Mar (2)	Apr	May (8)	Jun (15)	Jul	Aug	Sep	Oct	Nov	Dec
2014	Jan (4)	Feb (1)	Mar (1)	Apr (5)	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (3)	Oct	Nov	Dec
2017	Jan	Feb	Mar	Apr (1)	May	Jun	Jul	Aug	Sep	Oct (1)	Nov	Dec

simspark-devel Mailing List for Spark - A generic physical simulator (Page 28)

simspark-devel — Discussion about Spark development