Menu
▾
▴
simspark-devel
|
From: Yuan X. <xuy...@gm...> - 2007-04-15 16:02:51
|
Hi all, After several experiments, we got the conclusions below: * If the load of server is light, the timer works well. * The rendering influences the timer greatly. * The 10 humanoid robots physics simulation is too complex, the simulation time is longer than the real time, so that the timer can not work properly. The full report is at http://xuyuan.cn.googlepages.com/test-timer-rc1.pdf In the report, the experiment configurations are described firstly, then the experiment results are given, followed by the conclusion. Any comment is welcome! -- Best wishes! Xu Yuan School of Automation Southeast University, Nanjing, China mail: xuy...@gm... xy...@ya... web: http://xuyuan.cn.googlepages.com -------------------------------------------------- |
|
From: Joschka B. <jbo...@un...> - 2007-05-01 10:03:00
|
Hi Yuan, Yuan Xu wrote: > After several experiments, we got the conclusions below: > * If the load of server is light, the timer works well. > * The rendering influences the timer greatly. > * The 10 humanoid robots physics simulation is too complex, > the simulation time is longer than the real time, > so that the timer can not work properly. > > The full report is at http://xuyuan.cn.googlepages.com/test-timer-rc1.pdf > first of all, thank you very much for the detailed experiments and the report! I'm sorry I couldn't reply earlier :-( I couldn't really test the timer myself properly yet because of problems in the external monitor. I recently worked on that and submitted some updates to the server and the external monitor (monitorspark) to the CVS. The rendering is now by default disabled in the simspark (I added the TimerSDL in the initialization of the InputServer). The external monitor now gets an update every cycle, otherwise I got very strange rendering errors. I have to help out at the JapanOpen 2007 in the next days (until 05/05), but I would be glad if somebody could test the current setup, if possible, also using Yuan's timer (since the rendering can now be done on an external machine). Concerning the timer itself: * For submitting the code to the CVS, we need a test to check for the boost_thread-mt library. In some distributions, we need to use "-lboost_thread-mt", in others "-lboost_thread-gcc-mt" for linking. @Oliver: do you think you could do the Makefile magic for that? :-) * You noticed that only one CPU is used and the others remain idle even though we use different threads that should be able to execute in parallel without blocking themselves all the time; do you have an idea why this is the case? * It seems evident that we have to optimize the physics somehow. We should at least get to the point where 3 vs. 3 robots can be reliably simulated, I think. Without having done any profiling at all, my suggestion would be to take a look at possibilities to optimize the collision detection in the ODE part. One possibility is to use separate collision spaces for each robot. From the ODE Wiki [1]: "Spaces may contain other spaces. These sub-spaces will typically represent a collection of geoms (or other spaces) that are located near each other. This is useful for gaining extra collision performance by dividing the collision world into hierarchies. Here is an example of where this is useful: Suppose you have two cars driving over some terrain. Each car is made up of many geoms. If all these geoms were inserted into the same space, the collision computation time between the two cars would always be proportional to the total number of geoms (or even to the square of this number, depending on which space type is used). To speed up collision a separate space is created to represent each car. The car geoms are inserted into the car-spaces, and the car-spaces are inserted into the top level space. At each time step dSpaceCollide is called for the top level space. This will do a single intersection test between the car-spaces (actually between their bounding boxes) and call the callback if they touch. The callback can then test the geoms in the car-spaces against each other using dSpaceCollide2. If the cars are not near each other then the callback is not called and no time is wasted performing unnecessary tests." Anybody know any volunteers (we might ask on the server-three-d ML)? Cheers, Joschka [1] http://opende.sourceforge.net/wiki/index.php/Manual_(Collision_Detection) |
|
From: Markus R. <rol...@un...> - 2007-05-01 11:11:53
|
Hi all, Joschka Boedecker wrote: > * It seems evident that we have to optimize the physics somehow. We > should at least get to the point where 3 vs. 3 robots can be reliably > simulated, I think. Without having done any profiling at all, my > suggestion would be to take a look at possibilities to optimize the > collision detection in the ODE part. One possibility is to use separate > collision spaces for each robot. From the ODE Wiki [1]: [...] > Anybody know any volunteers (we might ask on the server-three-d ML)? I've been thinking about the collision issue lately and I think I'll volunteer ;) I think there are only very few changes necessary: - It is already possible to create the additional 'Space' nodes in the .rsg files. So putting each robot into it's own collision space would be a matter of enclosing the current soccerbot.rsg into an additional (node space ) expression or using an external wrapper .rsg that imports the soccerbot. - The problem is registering the ODE geoms to the proper space. This is done in the OnLink() method of the collider class. It calls GetSpaceId() wich in turn calls OdeObject::GetSpace(). Currently the global Space object below the SceneServer is returned. This behavior could be changed to walk the parent chain of the ODEObject in order to find the closest Space parent. If this fails we revert to the current behavior and return the default space. Therefore existing .rsg files will still work as expected. - The actual collision logic needs very little change. The wiki entry [1], that Joschka linked to provides a code snipped that we could nearly copy 1:1 into our code base. I'll try to implement these changes in the simspark CVS. cheers, Markus [1] http://opende.sourceforge.net/wiki/index.php/Manual_(Collision_Detection) |
|
From: Markus R. <rol...@un...> - 2007-05-01 13:34:36
|
Hi, Markus Rollmann wrote: > Joschka Boedecker wrote: >> * It seems evident that we have to optimize the physics somehow. We >> should at least get to the point where 3 vs. 3 robots can be reliably >> simulated, I think. Without having done any profiling at all, my >> suggestion would be to take a look at possibilities to optimize the >> collision detection in the ODE part. One possibility is to use separate >> collision spaces for each robot. From the ODE Wiki [1]: > [...] [...] > I think there are only very few changes necessary: > > - It is already possible to create the additional 'Space' nodes in the > .rsg files. So putting each robot into it's own collision space would be > a matter of enclosing the current soccerbot.rsg into an additional (node > space ) expression or using an external wrapper .rsg that imports the > soccerbot. > > - The problem is registering the ODE geoms to the proper space. This is > done in the OnLink() method of the collider class. It calls GetSpaceId() > wich in turn calls OdeObject::GetSpace(). Currently the global Space > object below the SceneServer is returned. > > This behavior could be changed to walk the parent chain of the ODEObject > in order to find the closest Space parent. If this fails we revert to > the current behavior and return the default space. Therefore existing > .rsg files will still work as expected. > > - The actual collision logic needs very little change. The wiki entry > [1], that Joschka linked to provides a code snipped that we could nearly > copy 1:1 into our code base. > > I'll try to implement these changes in the simspark CVS. The changes are now part of the simspark CVS trunk. I did test the changes with rsgedit and the jointtest.rsg demo, where I placed each hinge2thing.rsg, sliderthing.rsg and universalthing.rsg in a separate space each- and it worked fine ;) The problem was not in the setup of the different collision spaces but in the deconstruction of them. The problem is that all ODE objects should be deconstructed in the proper order. This means that joints should be removed before the attached bodies are destroyed, and geoms before the spaces they are contained in etc. If they are destroyed in the order in which they are traversed in the scene graph these conditions do not hold, which may lead to ODE segfaults. The problem will occcur whenever an agent disconnects from the server. In this case it's personal ODE sub spaces have to be destroyed and removed from the global space. In the simspark CVS I'm facing this problem when the user reloads the entire scene from rsgedit. For this case I added a virtual DestroyODEObject() dtor to each ODEObject that is called from World nodes OnUnlink() method. I'm not sure if it's necessary to copy this whole machinery to the rcsssrver3d CVS, maybe some special handling for agent disconnect will suffice? regards, Markus |
|
From: Joschka B. <jbo...@un...> - 2007-05-01 22:14:44
|
Hi Markus, > Hi, > > Markus Rollmann wrote: > >> Joschka Boedecker wrote: >> >>> * It seems evident that we have to optimize the physics somehow. We >>> should at least get to the point where 3 vs. 3 robots can be reliably >>> simulated, I think. Without having done any profiling at all, my >>> suggestion would be to take a look at possibilities to optimize the >>> collision detection in the ODE part. One possibility is to use separate >>> collision spaces for each robot. From the ODE Wiki [1]: >>> >> [...] >> > > [...] > >> I think there are only very few changes necessary: >> >> - It is already possible to create the additional 'Space' nodes in the >> .rsg files. So putting each robot into it's own collision space would be >> a matter of enclosing the current soccerbot.rsg into an additional (node >> space ) expression or using an external wrapper .rsg that imports the >> soccerbot. >> >> - The problem is registering the ODE geoms to the proper space. This is >> done in the OnLink() method of the collider class. It calls GetSpaceId() >> wich in turn calls OdeObject::GetSpace(). Currently the global Space >> object below the SceneServer is returned. >> >> This behavior could be changed to walk the parent chain of the ODEObject >> in order to find the closest Space parent. If this fails we revert to >> the current behavior and return the default space. Therefore existing >> .rsg files will still work as expected. >> >> - The actual collision logic needs very little change. The wiki entry >> [1], that Joschka linked to provides a code snipped that we could nearly >> copy 1:1 into our code base. >> >> I'll try to implement these changes in the simspark CVS. >> > > The changes are now part of the simspark CVS trunk. Wow, you are fast! Thanks a lot :-D > I did test the > changes with rsgedit and the jointtest.rsg demo, where I placed each > hinge2thing.rsg, sliderthing.rsg and universalthing.rsg in a separate > space each- and it worked fine ;) > > Nice :-) > The problem was not in the setup of the different collision spaces but > in the deconstruction of them. > > The problem is that all ODE objects should be deconstructed in the > proper order. [...] > > I'm not sure if it's necessary to copy this whole machinery to the > rcsssrver3d CVS, maybe some special handling for agent disconnect will > suffice? > Yes, maybe you're right and we can handle this in an easy way somehow for the agent disconnects. I'll take a look after I'm back from JapanOpen, but if anybody else wants to have a look in the meantime -- feel free ;-) Cheers, Joschka |
|
From: Markus R. <rol...@un...> - 2007-05-02 14:58:06
|
Hi, Joschka Boedecker wrote: >> Markus Rollmann wrote: >> I'm not sure if it's necessary to copy this whole machinery to the >> rcsssrver3d CVS, maybe some special handling for agent disconnect will >> suffice? >> > > Yes, maybe you're right and we can handle this in an easy way somehow > for the agent disconnects. I'll take a look after I'm back from > JapanOpen, but if anybody else wants to have a look in the meantime -- > feel free ;-) Ok. I'll see what I can do. It think I'll put the 'space' changes first into a separate test branch where in order to allow for some test phase. About the deconstruction problem we'll see after that... Cheers, Markus |
|
From: Markus R. <rol...@un...> - 2007-05-02 19:36:49
|
Hi, Markus Rollmann wrote: [...] > Ok. I'll see what I can do. It think I'll put the 'space' changes first > into a separate test branch where in order to allow for some test phase. I commited the changes to the ODE_SUBSPACES branch in the rcssserver3d CVS. They are currently untested (maybe they don't even compile), as I need to install a linux first ;-) So maybe someone of you could test these changes. As I said, the setup should work withouth problems, just insert an enclosing (node Space ... ) expression as the outermost expression to the soccerbot.rsg file and multiple robot instances may work a bit faster... cheers, Markus |
|
From: Jan M. <mu...@un...> - 2007-05-03 11:53:10
|
Hi Markus, Markus Rollmann wrote: > I commited the changes to the ODE_SUBSPACES branch in the rcssserver3d > CVS. They are currently untested (maybe they don't even compile), as I > need to install a linux first ;-) So maybe someone of you could test > these changes. I tried without success. :-( I get an "undefined reference to `oxygen::ODEObject::GetSpaceID()'" during make in the "app/*" subdirs. It looks like GetSpaceID() is declared (in odeobject.h), but not defined (The same is true in simspark/spark.) BTW, GetParentSpaceID() always returns 0. Is this correct? Bye, Jan |
|
From: Oliver O. <Oli...@ne...> - 2007-05-05 09:06:54
|
Hi,
On 01/05/2007, at 8:02 PM, Joschka Boedecker wrote:
> * For submitting the code to the CVS, we need a test to check for
> the boost_thread-mt library. In some distributions, we need to use
> "-lboost_thread-mt", in others "-lboost_thread-gcc-mt" for linking.
> @Oliver: do you think you could do the Makefile magic for that? :-)
Finally I've looked into it. The configure script now checks for this
lib (as boost_thread, boost_thread-mt, and boost_thread-gcc-mt). It's
somehow interesting that just the boost guys can't come up with one
standard way of calling the library.
The check creates a Makefile (Meta)variable @BOOST_THREADS_LIB@. If
you put it in a Makefile.am somewhere, it will be replaced by the
name of the boost thread library that was found (first) when the
Makefile gets created.
I haven't done this, because I haven't checked where you want to use
it. If you need it in, say oxygen, do something like this to the
corresponding Makefile.am:
change:
liboxygen_debug_la_LIBADD = -lode ${spades_libs}
to
liboxygen_debug_la_LIBADD = -lode ${spades_libs} -l@BOOST_THREADS_LIB@
(you have to do that 2x in the Makefile.am, one time for the debug
version of the lib, and one time for the normal version).
If you cvs up now, you need to booststrap the configure file again.
If there are problems (or more different versions of the thread lib),
let me know.
I have tested the script on one linux machine (@uni-koblenz.de), but
I haven't checked what happens if there's no boost thread library.
What should the check do in this case? Stop configuring?
cheers
Oliver
--
Oliver Obst ES208 form follows function (Louis Sullivan).
Fon: +61 2 492 16175 http://oliver.obst.eu/
Uni Newcastle School of Electrical Engineering and Computer Science
|
|
From: Oliver O. <fr...@ro...> - 2007-05-02 06:57:26
|
Hi, On 01/05/2007, at 8:02 PM, Joschka Boedecker wrote: > * For submitting the code to the CVS, we need a test to check for the > boost_thread-mt library. In some distributions, we need to use > "-lboost_thread-mt", in others "-lboost_thread-gcc-mt" for linking. > @Oliver: do you think you could do the Makefile magic for that? :-) yep, I'll go for it. cheers Oliver -- Oliver Obst ES208 form follows function (Louis Sullivan). Fon: +61 2 492 16175 http://oliver.obst.eu/ Uni Newcastle School of Electrical Engineering and Computer Science |
|
From: Yuan X. <xuy...@gm...> - 2007-05-02 16:01:33
|
Hi Joschka and all,
> I have to help out at the JapanOpen 2007 in the next days (until 05/05),
> but I would be glad if somebody could test the current setup, if
> possible, also using Yuan's timer (since the rendering can now be done
> on an external machine).
I have checked out the code from the cvs.
The server and monitor can be started,
but I got some problems:
* monitorspark:
First, some times it seems missing the data from the server,
the typical screen shots are [] and []. The body are fall apart...
Second, I do not know how to load the sparkmonitor.log,
I set $recordLogfile to true,
and tried run "./momitorspark --logfile sparkmonitor.log", but it
does not work.
* agentspark:
First, the agentspark does not terminate when the server is closed,
and even Ctrl-C can not terminate it. I have to kill it every time.
Second, it may abort with output "too long message; aborting",
but it does not occur often.
> * You noticed that only one CPU is used and the others remain idle even
> though we use different threads that should be able to execute in
> parallel without blocking themselves all the time; do you have an idea
> why this is the case?
The reason is that the physic thread can not execute parallel with
other threads.
There is only one sense in the program,
when the physic thread running, other thread have to wait.
Hope to get comments soon.
--
Best wishes!
Xu Yuan
School of Automation
Southeast University, Nanjing, China
mail: xuy...@gm...
xy...@ya...
web: http://xuyuan.cn.googlepages.com
--------------------------------------------------
|
|
From: Yuan X. <xuy...@gm...> - 2007-05-02 16:06:42
|
Hi all, Sorry, I missed the screen shots of monitorspark, they are placed here: http://picasaweb.google.com/xuyuan.cn/C75/photo#5059995259975158530 http://picasaweb.google.com/xuyuan.cn/C75/photo#5059995259975158546 2007/5/3, Yuan Xu <xuy...@gm...>: > Hi Joschka and all, > > > > I have to help out at the JapanOpen 2007 in the next days (until 05/05), > > but I would be glad if somebody could test the current setup, if > > possible, also using Yuan's timer (since the rendering can now be done > > on an external machine). > > I have checked out the code from the cvs. > The server and monitor can be started, > but I got some problems: > * monitorspark: > First, some times it seems missing the data from the server, > the typical screen shots are [] and []. The body are fall apart... > Second, I do not know how to load the sparkmonitor.log, > I set $recordLogfile to true, > and tried run "./momitorspark --logfile sparkmonitor.log", but it > does not work. > * agentspark: > First, the agentspark does not terminate when the server is closed, > and even Ctrl-C can not terminate it. I have to kill it every time. > Second, it may abort with output "too long message; aborting", > but it does not occur often. > > > > * You noticed that only one CPU is used and the others remain idle even > > though we use different threads that should be able to execute in > > parallel without blocking themselves all the time; do you have an idea > > why this is the case? > The reason is that the physic thread can not execute parallel with > other threads. > There is only one sense in the program, > when the physic thread running, other thread have to wait. > > Hope to get comments soon. > > -- > Best wishes! > > Xu Yuan > School of Automation > Southeast University, Nanjing, China > > mail: xuy...@gm... > xy...@ya... > web: http://xuyuan.cn.googlepages.com > -------------------------------------------------- > -- Best wishes! Xu Yuan School of Automation Southeast University, Nanjing, China mail: xuy...@gm... xy...@ya... web: http://xuyuan.cn.googlepages.com -------------------------------------------------- |
|
From: Markus R. <rol...@un...> - 2007-05-03 17:48:04
|
Jan Murray wrote: [...] > I tried without success. :-( > I get an "undefined reference to `oxygen::ODEObject::GetSpaceID()'" > during make in the "app/*" subdirs. There were two errors: The GetSpaceID() declaration in odeobject.h was obsolote but still used from collider.cpp. I changed that. Does it at least compile now ? ;) > It looks like GetSpaceID() is declared (in odeobject.h), but not defined > (The same is true in simspark/spark.) I'll check that. > BTW, GetParentSpaceID() always returns 0. Is this correct? only Collider and Space objects have parent spaces (bodies don't). The common base class of both is ODEObject. Therefore the base class returns 0, collider and space both use the dGeomGetSpace function (they implement identical functions). Maybe we could add a common base class to Space and Collider below ODEObject (OdeGeomObject?) to merge common methods between Space and Collider classes. Cheers, Markus |
|
From: Jan M. <mu...@un...> - 2007-05-04 09:33:16
|
|On Thu, 03 May 2007 19:47:46 +0200, Markus Rollmann <rol...@un...> said:
> Jan Murray wrote:
> [...]
>> I tried without success. :-(
>> I get an "undefined reference to `oxygen::ODEObject::GetSpaceID()'"
>> during make in the "app/*" subdirs.
> There were two errors: The GetSpaceID() declaration in odeobject.h was
> obsolote but still used from collider.cpp. I changed that.
> Does it at least compile now ? ;)
Almost. ;) I had to change Collider::OnLink() a little:
I added this at the beginning:
> weak_ptr<Node> parent = GetParent();
> if (
> (mODEGeom == 0) ||
> (parent.expired())
> )
> {
> return;
> }
and removed this as it's subsumed by the above test:
> if (mODEGeom == 0)
> {
> return;
> }
Now it seems to work. Adding the wrapper to the soccerbot.rsg worked
out of the box. :-) Now I have to check if it really gets faster.
Bye,
Jan
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X