Menu
▾
▴
simspark-devel — Discussion about Spark development
You can subscribe to this list here.
| 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
|
|
From: Hedayat V. <hed...@ai...> - 2008-02-22 07:38:45
|
<!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;">I ported physicsserver changes from simspark to soccer3d. Then, I noticed that some of my robots don't move at all, while others move for some time and then stop! Finally I found the problem: setAutoDisableFlag(true) in spark.rb. Because of a bug in the implementation, it didn't work before and the flag was always false. This bug was solved in simspark, and because of the auto disable flag, ode disabled my robots when they didn't move for some time. I turned the flag off for now.</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">A disabled body will improve performance. If a disabled body is connected to an enabled body using joints, it'll be enabled too. So, I think when a part of the robot body is disabled, it'll be enabled by other parts, but when all of it's body parts are disabled, it'll be never enabled again (except if something collides with it, which in turns creates contact joints and so, I think, it'll enable the body).<br> </p> <br> I don't know if it can help improving performance, but we may try enabling the auto disable flag and configuring it with suitable parameter for its thresholds (ODE manual, part 6.5). Then when the agent sends new rotation speeds we should enable the bodies connected to the joint. While the robots move a lot, it may improve performance (?!). What do you think?<br> <br> Thanks,<br> Hedayat<br> <br> </body> </html> |
|
From: Markus R. <rol...@un...> - 2008-02-21 11:13:41
|
Hi Joschka, Joschka Boedecker schrieb: > 1) The "no-hierarchies bug" > > You cornered this bug that prevents the correct construction of > hierarchies in the scene graph last year. It had the effect that all > but the last body in a hierarchy in a scene description were set to > the origin, no matter what. I think it had something to do with the > Transform class, but I can't remember correctly. Did you ever get > around fixing this one? yes, I already changed this in the simspark CVS but not yet in the soccer3d CVS (I forgot to add it to the list of differences I posted recently). The original scene graph design does not support nested bodies in the sense that there must be no body node in the chain of parent nodes of any given body node. The problem is a follows: After each physics step the scene graph is updatetd to reflect the new position of each ODE body. This is done in Body::PostPhysicsUpdateInternal() that calls SetWorldTransform() of the parent node. This call is chained upwards in the hierarchy until the SetWorldTransform() of a transform node is called. In the current soccer3d implementation the given transform matrix is taken and all parent nodes are set to the identity matrix (via the same upchain mechanism). As the scene graph is updated bottom up (see BaseNode::PostPhysicsUpdate()) only the last body in each parent chain is updated correctly (every other body is forced to the origin). In the simspark implementation I fixed the Transform::SetWorldTransform() to multiply the new given world transform with the inverse of the parents world transform, to calculae the necessary 'delta' as the new local transform matrix. It therefore no longer needs to reset the parent to the origin. In my tests with the RosiML importer this worked ok. The new SetWorldTransform() depends on the full matrix inversion that is added to the salt::Matrix() class. > 2) The RosiML importer > > I remember you pointed out there were still problems with the importer > concerning composite bodies and some kind of macros. Could you give a > brief explanation of these problems in case someone is willing to work > on it? I implemented the RosiML importer using only some example files and an XML schema that lacked the semantics of the nodes. Simple demo files (i.e. block worlds and basic joint setups) work correctly but I was unable to fully parse the more complex robot files (e.g. aibos). The shapes (i.e. 3d meshes and textures) as well as the basic joint setup seem to work but the more subtle details like the correct mass center, joint stops, motor setup etc. are still lacking. I'll try to look into it again to come up with a more precise description of it's current state... ;) cheers, Markus |
|
From: Joschka B. <jos...@am...> - 2008-02-21 10:32:17
|
Hi Markus, since we're in the progress of collecting ToDo information concerning the simulator, I wanted to ask about two issues in the code for which I can't remember the details. 1) The "no-hierarchies bug" You cornered this bug that prevents the correct construction of hierarchies in the scene graph last year. It had the effect that all but the last body in a hierarchy in a scene description were set to the origin, no matter what. I think it had something to do with the Transform class, but I can't remember correctly. Did you ever get around fixing this one? 2) The RosiML importer I remember you pointed out there were still problems with the importer concerning composite bodies and some kind of macros. Could you give a brief explanation of these problems in case someone is willing to work on it? Thanks a lot in advance! Cheers, Joschka |
|
From: Joschka B. <jbo...@un...> - 2008-02-21 09:35:38
|
Hi all, as you all know and many of you experienced painfully, to this day, there is no complete manual for users and developers of our simulator. Some information is available, but it is scattered over text files, master's thesis, different Wiki and web pages, incomplete manuals, and the mailing list archives. This makes it very hard for newcomers to get started, and it results in the same questions being asked on the mailing lists time and again. I think this is not a desirable state, and with an organized effort, we should be able to change this rather quickly. I think we need at least a "getting started" guide, an F.A.Q. list, a user manual, and a developer manual. To get an idea of what I would like to see (concerning quality) for a manual, please have a look at [1]. This is the beginning of a manual that Oliver Obst started a while ago. Rodrigo da Silva Guerra also did an excellent job creating a manual for the Mixed Reality robots which you can find in the repository of [2]. I'd like to see something of similar quality for our simulator. Concerning the contents of the user's manual, I think the manual of the 2D simulator can be a good example to follow. Even though it is a bit dated by now, it's organization has stood the test of time and it has been useful for many people to get started, and keep going using the simulator. Besides that, we have resources like the manual Markus Rollmann started in the sserver CVS (docs/manual in the rcssserver3d distribution), and the well known TEXT_INSTEAD_OF_A_MANUAL text file. Markus' manual contains information for both users and developers, and should be distributed accordingly. Also, there are different installation instructions and getting started pieces scattered over the net (I'm not aware of them all, please give me a yell). Everybody on this mailing list is using the simulator, and everybody can contribute at least some part to a manual I think. You all depended on someone giving you information on how to get started with this strange, complicated piece of software, so maybe you can give something back now :-) Concerning the developer's manual, we have Marco's thesis at [3], and Markus' thesis at [4], Oliver's and Markus' journal paper [5], plus information contained in Markus' manual mentioned above. Everybody who has ever ventured to touch the code, or just read parts of it (or plans on doing so), is welcome to contribute. The F.A.Q, the getting started guide, and maybe some HOWTOs (e.g. how to export models from Blender to SimSpark, how to create a new robot, etc.) could be placed in the simspark wiki at [6]. (A note concerning this: we're still planning on moving the simspark code to the simspark repository completely at some point, but right now, this would be too much work. Actually, Hedayat ist now porting improvements from that repository back to the sserver one, and once this is complete, we can do the transition, I hope.) For the organization of the documentation effort, I think it would be good to have a dedicated individual (maybe one for user and one for developer manual), or a small group. They should determine the contents, assign work to volunteers, and do the final editing. If you're interested to help out with this, please contact me. But again, overall, this has to be a community effort. Alright, let's get started :-) Maybe if we're good, sometime in the future then, we won't ever have to reply an email with "Please set your LD_LIBRARY_PATH variable to..." ;-) Cheers, Joschka [1] http://www.oliverobst.eu/tmp/hope-1.pdf [2] http://sourceforge.net/projects/pv-league/ [3] http://www.uni-koblenz.de/~fruit/ftp/teaching/koe03-diplomarbeit.pdf [4] http://www.uni-koblenz.de/~fruit/ftp/teaching/rol04-diplomarbeit.pdf [5] http://www.oliverobst.eu/publications/2005/spark-OR05.pdf [6] http://simspark.sourceforge.net/wiki/ |
|
From: Hedayat V. <hed...@ai...> - 2008-02-20 12:05:41
|
<!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>
<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..."><xuy...@gm...></a></b></i> wrote on 02/20/2008 11:29:27 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,
</pre>
</blockquote>
Hi,<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="">
In my system, the external monitor works when only one agent and all
programs in one machine.
But when another robot connects, the monitor will stoped ;-(
</pre>
</blockquote>
Yes, I didn't test the external monitor connecting from another system.
<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 think it is not only the problem of monitorspark, since we have
implemented a monitor ourselves,
the problem is the same: the monitor only receive the message "NULL".
BTW, should we need the external monitor run in multi-threads?
</pre>
</blockquote>
No, I don't think so! It was just a simple experiment to know why it
crashes in that mode. <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="">I think the changes you made may mess the design.
</pre>
</blockquote>
If you mean the changes to SparkMonitor, I didn't commit it. I did a
small test and I thought that it might worth noting!<br>
But if you are talking about the multi-threaded implementation I
committed, please explain more. I don't know why it could mess the
design. <br>
<br>
Thanks,<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="">
2008/2/20, Hedayat Vatankhah <a class="moz-txt-link-rfc2396E" href="mailto:hed...@ai..."><hed...@ai...></a>:
</pre>
<blockquote type="cite">
<pre wrap=""> Hi,
I'm agree! :)
And about external monitor, I can successfully run the external monitor in
multi-threaded mode by renaming SparkMonitorClient's StartCycle to EndCycle.
(Like RenderControl, it should needs to be run in the main thread to prevent
crash). I have not tested much to see if it works fine, but in some very
simple tests it works just like the internal monitor. The only issue is that
it crashes on quit.
Have a nice time,
Hedayat
"Yuan Xu" <a class="moz-txt-link-rfc2396E" href="mailto:xuy...@gm..."><xuy...@gm...></a> wrote on 02/19/2008 08:29:15 PM:
Hi Joschka,
It is well organized. The schedule is clear, I think.
The date to release rcssserver3d-0.5.7 is coming,
maybe we should make a alpha package firstly, and test it by MC members.
Let's make decision which features/patches should be included in 0.5.7.
As you have mentioned, simRate, multithreading + internal rendering
should be included.
And also communication, Composite bodies?
I also hope I can make the external monitor working these days.
2008/2/19, <a class="moz-txt-link-abbreviated" href="mailto:jos...@go...">jos...@go...</a>
<a class="moz-txt-link-rfc2396E" href="mailto:jos...@go..."><jos...@go...></a>:
Hey guys, I've shared this item with you using Google Docs. To open
it, just click the link below. It's not too organized right now and I'm
not sure if the schedule is realistic, but it's a start. Let's keep
moving quickly on this, time's quite advanced already.
Cheers,
Joschka
RoboCup Soccer Simulation Maintenance...
<a class="moz-txt-link-freetext" href="http://docs.google.com/Doc?id=djkzvqh_3d8w7g6cx&invite=">http://docs.google.com/Doc?id=djkzvqh_3d8w7g6cx&invite=</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>
|
|
From: Joschka B. <jos...@am...> - 2008-02-20 10:13:51
|
Hi Yuan, welcome back :-) On Feb 20, 2008, at 1:59 AM, Yuan Xu wrote: > It is well organized. The schedule is clear, I think. OK, thank you. > The date to release rcssserver3d-0.5.7 is coming, Just to let everyone here know: I created a document in Google Docs to collect things concerning the simulator development and Maintenance Committee activities. You'll find the link below (let me know if you're interested, but can't access it). This includes the following suggestion for a (tentative) schedule: 02/25: Release rcssserver3d-0.5.7 include communication, the changes from Atlanta, and the patches/fixes posted after that (simRate, multithreading + internal rendering, etc.) 03/10: Release rcssserver3d-0.5.8: include Sander's changes concerning the composite bodies, improved rule tests (test bounding box instead of center point) 03/24: Release rcssserver3d-0.5.9: include fixes for external monitor + multithreading, speed optimizations, improved vision perceptor 04/07: Release rcssserver3d-0.5.10: beta version of the simulator for RC08, include new robot and ball model 04/21: Release rcssserver3d-0.6rc1: release candidate #1 of the simulator for RC08, try to fix ODE settings 04/28: Release rcssserver3d-0.6rc2: release candidate #2 of the simulator for RC08, mainly bug fixes and polishing 05/07: Release rcssserver3d-0.6: final version for RC08, after that only bug fixes if they are causing serious trouble and changes don't affect the teams too much 07/14: RoboCup 2008 begins I hope this is somewhat realistic. > maybe we should make a alpha package firstly, and test it by MC > members. > Good idea, I would recommend this for every release, but it should be done rather soon. > Let's make decision which features/patches should be included in > 0.5.7. > As you have mentioned, simRate, multithreading + internal rendering > should be included. I don't have a full overview over what exactly has happened since Atlanta. I think it's best to check the SF Tracker for the patches and the mailing list archives, but this is difficult. Maybe we should write an email to the sserver-three-d list to ask for everybody who submitted a patch or a fix to check whether it ended up on the tracker, and if not, ask them to submit it there. > And also communication, Jan and Hesham both did tests with the communication. I'm not sure about the status, is it ready to included in a release? > Composite bodies? Sander has made good progress on this, but I think there are still some things left to be figured out concerning automatic adjustment of the center of mass for the composite bodies. Maybe Sander can give a rough estimate about the time frame this will take? > I also hope I can make the external monitor working these days. > Great! Cheers, Joschka > 2008/2/19, jos...@go... > <jos...@go...>: >> Hey guys, I've shared this item with you using Google Docs. To open >> it, just click the link below. It's not too organized right now >> and I'm >> not sure if the schedule is realistic, but it's a start. Let's keep >> moving quickly on this, time's quite advanced already. >> >> Cheers, >> Joschka >> >> RoboCup Soccer Simulation Maintenance... >> http://docs.google.com/Doc?id=djkzvqh_3d8w7g6cx&invite= >> |
|
From: Yuan X. <xuy...@gm...> - 2008-02-20 08:00:35
|
Hi Hedayat, In my system, the external monitor works when only one agent and all programs in one machine. But when another robot connects, the monitor will stoped ;-( I think it is not only the problem of monitorspark, since we have implemented a monitor ourselves, the problem is the same: the monitor only receive the message "NULL". BTW, should we need the external monitor run in multi-threads? I think the changes you made may mess the design. > > 2008/2/20, Hedayat Vatankhah <hed...@ai...>: > > > > Hi, > > I'm agree! :) > > And about external monitor, I can successfully run the external monitor in > > multi-threaded mode by renaming SparkMonitorClient's StartCycle to EndCycle. > > (Like RenderControl, it should needs to be run in the main thread to prevent > > crash). I have not tested much to see if it works fine, but in some very > > simple tests it works just like the internal monitor. The only issue is that > > it crashes on quit. > > > > Have a nice time, > > Hedayat > > > > "Yuan Xu" <xuy...@gm...> wrote on 02/19/2008 08:29:15 PM: > > > > Hi Joschka, > > > > It is well organized. The schedule is clear, I think. > > The date to release rcssserver3d-0.5.7 is coming, > > maybe we should make a alpha package firstly, and test it by MC members. > > > > Let's make decision which features/patches should be included in 0.5.7. > > As you have mentioned, simRate, multithreading + internal rendering > > should be included. > > And also communication, Composite bodies? > > I also hope I can make the external monitor working these days. > > > > 2008/2/19, jos...@go... > > <jos...@go...>: > > > > > > Hey guys, I've shared this item with you using Google Docs. To open > > it, just click the link below. It's not too organized right now and I'm > > not sure if the schedule is realistic, but it's a start. Let's keep > > moving quickly on this, time's quite advanced already. > > > > Cheers, > > Joschka > > > > RoboCup Soccer Simulation Maintenance... > > http://docs.google.com/Doc?id=djkzvqh_3d8w7g6cx&invite= > > > > > > > > > > -- 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...> - 2008-02-20 07:44:10
|
Hi Hesham, Thanks for your comments and code. In fact, SDL_GetTicks() call clock_gettime(CLOCK_MONOTONIC, &now), if it's available[1]. But the clocks are different, the SDL use CLOCK_MONOTONIC. I am not sure which is better, since clock_getres() with the two clocks returns the same precision in my systeam(Suse10.2): they are both ( 0 4000250). And you mentioned the nanosleep() error is around 0.5 msec. But I think it is the same mean with the 10 msec precision. I have done a test on different sleeps: usleep, boost::thread::sleep and nanosleep. The results showed that there are nearly the same: Input(ms) boost usleep nanosleep gettimeofday clock_gettime 0 4 4 4.03694 0.000556 0.000409 1 4.01191 4.0041 4.00091 1.00193 1.00087 2 4.044 4.01201 4.02362 2.00263 2.00181 3 8.03601 8.08801 8.07893 3.00388 3.01715 4 8.00801 7.9996 8.01276 4.00417 4.00744 5 8.46001 12.0281 10.2573 5.00107 5.0015 6 8.02001 8.02391 8.2374 6.04204 6.01252 7 12.024 12.008 12.0635 7.00603 7.01054 8 12.052 12.532 12.0045 8.0039 8.00347 9 13.8839 12.056 12.0787 9.04589 9.01147 The program which I used to test have been attached, you can compile it by: "g++ test_timer.cpp -lrt -lboost_thread" I noticed that SDL_Delay() is implemented by a while loop(also see [1]), which is similar as our current code. The last two rows of above table are results of 'while loop' method with gettimeofday() and clock_gettime(). I think I can make a conclusion: if we use 'sleep', no matter which one, the precision can not guaranteed; if we use 'while loop' the precision is better(It is also tested in my program), but it will cost lots of computation. [1] http://www.libsdl.org/cgi/viewvc.cgi/trunk/SDL/src/timer/unix/SDL_systimer.c?view=markup > > Apparently the new kernels already have high resolution timers (they have > problem just with old cpus). I can get nanosecond with this program on my > laptop: > > #include <ctime> > #include <iostream> > using namespace std; > int main() > { > float temp; > struct timespec ts1; > struct timespec ts2; > clock_gettime( CLOCK_REALTIME, &ts1 ); > for (size_t i=0; i<50000000; i++) > temp = 10.0 + 0.1; > clock_gettime( CLOCK_REALTIME, &ts2 ); > long long int count1 = static_cast<long > long>(1000000000UL)*static_cast<long long>(ts1.tv_sec) + > static_cast<long long>(ts1.tv_nsec); > long long int count2 = static_cast<long > long>(1000000000UL)*static_cast<long long>(ts2.tv_sec) + > static_cast<long long>(ts2.tv_nsec); > cout<<(count2-count1)<<endl; > return 0; > } > > And also there is no need to worry about new multi-core CPUs, they have > synchronized cores (at least that's the case with Intel, according to the > comments in the kernel code). > > I did some tests with nanosleep() too. The error is around 0.5 msec (much > less than 10 msec that you mentioned), so it shows we may can use it if that > error is acceptable (to me it is). > > Bests, > Hesham > > > On 27/01/2008, Yuan Xu <xuy...@gm...> wrote: > > 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 > > -------------------------------------------------- > > > > -- Best wishes! Xu Yuan School of Automation Southeast University, Nanjing, China mail: xuy...@gm... xy...@ya... web: http://xuyuan.cn.googlepages.com -------------------------------------------------- |
|
From: Hedayat V. <hed...@ai...> - 2008-02-19 23:29:45
|
Hi, I'm agree! :) And about external monitor, I can successfully run the external monitor in multi-threaded mode by renaming SparkMonitorClient's StartCycle to EndCycle. (Like RenderControl, it should needs to be run in the main thread to prevent crash). I have not tested much to see if it works fine, but in some very simple tests it works just like the internal monitor. The only issue is that it crashes on quit. Have a nice time, Hedayat /*"Yuan Xu" <xuy...@gm...>*/ wrote on 02/19/2008 08:29:15 PM: > Hi Joschka, > > It is well organized. The schedule is clear, I think. > The date to release rcssserver3d-0.5.7 is coming, > maybe we should make a alpha package firstly, and test it by MC members. > > Let's make decision which features/patches should be included in 0.5.7. > As you have mentioned, simRate, multithreading + internal rendering > should be included. > And also communication, Composite bodies? > I also hope I can make the external monitor working these days. > > 2008/2/19, jos...@go... <jos...@go...>: > >> Hey guys, I've shared this item with you using Google Docs. To open >> it, just click the link below. It's not too organized right now and I'm >> not sure if the schedule is realistic, but it's a start. Let's keep >> moving quickly on this, time's quite advanced already. >> >> Cheers, >> Joschka >> >> RoboCup Soccer Simulation Maintenance... >> http://docs.google.com/Doc?id=djkzvqh_3d8w7g6cx&invite= >> >> > > > |
|
From: Hesham <hes...@gm...> - 2008-02-19 20:38:48
|
Hi Yuan,
Sorry for getting back to this late.
On 27/01/2008, Yuan Xu <xuy...@gm...> wrote:
1. to get precise time, use RealTime-Linux as platform [It will
narrow OS platform]
Apparently the new kernels already have high resolution timers (they have
problem just with old cpus). I can get nanosecond with this program on my
laptop:
#include <ctime>
#include <iostream>
using namespace std;
int main()
{
float temp;
struct timespec ts1;
struct timespec ts2;
clock_gettime( CLOCK_REALTIME, &ts1 );
for (size_t i=0; i<50000000; i++)
temp = 10.0 + 0.1;
clock_gettime( CLOCK_REALTIME, &ts2 );
long long int count1 = static_cast<long
long>(1000000000UL)*static_cast<long long>(ts1.tv_sec) + static_cast<long
long>(ts1.tv_nsec);
long long int count2 = static_cast<long
long>(1000000000UL)*static_cast<long long>(ts2.tv_sec) + static_cast<long
long>(ts2.tv_nsec);
cout<<(count2-count1)<<endl;
return 0;
}
And also there is no need to worry about new multi-core CPUs, they have
synchronized cores (at least that's the case with Intel, according to the
comments in the kernel code).
I did some tests with nanosleep() too. The error is around 0.5 msec (much
less than 10 msec that you mentioned), so it shows we may can use it if that
error is acceptable (to me it is).
Bests,
Hesham
On 27/01/2008, Yuan Xu <xuy...@gm...> wrote:
>
> 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
> --------------------------------------------------
>
|
|
From: Yuan X. <xuy...@gm...> - 2008-02-19 16:59:22
|
Hi Joschka, It is well organized. The schedule is clear, I think. The date to release rcssserver3d-0.5.7 is coming, maybe we should make a alpha package firstly, and test it by MC members. Let's make decision which features/patches should be included in 0.5.7. As you have mentioned, simRate, multithreading + internal rendering should be included. And also communication, Composite bodies? I also hope I can make the external monitor working these days. 2008/2/19, jos...@go... <jos...@go...>: > Hey guys, I've shared this item with you using Google Docs. To open > it, just click the link below. It's not too organized right now and I'm > not sure if the schedule is realistic, but it's a start. Let's keep > moving quickly on this, time's quite advanced already. > > Cheers, > Joschka > > RoboCup Soccer Simulation Maintenance... > http://docs.google.com/Doc?id=djkzvqh_3d8w7g6cx&invite= > -- Best wishes! Xu Yuan School of Automation Southeast University, Nanjing, China mail: xuy...@gm... xy...@ya... web: http://xuyuan.cn.googlepages.com -------------------------------------------------- |
|
From: Hedayat V. <hed...@ai...> - 2008-02-18 20:00:48
|
Hi, OK, You are right. I will do that. But what do you think about dropping the spark version in soccer3d repository immediately after that? Then, simspark changes will be followed by the corresponding changes in soccer3d. If not, I think the current situation will last for ever! I think that I will need your help from time to time, so I want to say thanks for your patience! :) Good luck, Hedayat /*Markus Rollmann <rol...@un...>*/ wrote on 02/18/2008 01:44:06 PM: > Hi, > > Hedayat Vatankhah wrote: > [...] > >> But about selecting a repository, what about removing the spark core >> libraries (oxygen, kerosin, ...) and other things which are currently in >> simspark from soccer3d repository? For now, we could just split two >> repositories so that the soccer3d code requires simspark installed on >> the system. >> > > You want to use the libraries from the simspark repository tpgether with > the simulation from the soccer3d repository, right? > > I think thats not practical as the two spark version have various > differences that does not allow a for a simple replacement (see my 2nd > mail for a list of differences) > > Therefore keeping a known working version (the soccer3d repo) and > gradually picking changes from the simspark repo is my preferred way. > > >> To make it simpler for users, we could then release them as >> one package, so that they will not notice the change. (Also, I will >> release RPM/SRPM packages for them). At least, it is more fun I think! >> > [...] > > The idea to release rpm or debian packages is good I think and would > ease the installation process for the user. > > cheers, > Markus > > |
|
From: Markus R. <rol...@un...> - 2008-02-18 10:51:13
|
Hi all, Sander van Dijk wrote: [...] > However, it seems that the colliders and transforms with the meshes > are linked into the graph before the body is, no matter how they are > ordered in the rsg files . how did you test that? The RubySceneImporter (rsg) importer creates the nodes in the top down order as they are defined, i.e. the creation of nodes is not deferred or ordered in any way. The current design of the scene graph however requires that the body node is linked in before any dependent geom node. Please see the dGeomSetBody call in Collider::Onlink() method that looks for a body below the colliders parent node. So bodies need to be linked in before the geoms in order to work correctly. > I have tried to dig through the code to find out why this is and how > to prevent this, but couldn't really get a lead. Do you have any > ideas on this? I don't want to make an 'UpdateWholeTree' kind of > method. I think a variant of 'UpdateWholeTree' is needed. However it should be limited to the set of the bodies that were actually created by the importer. The COM of already existing nodes should not be modified. One possibility is that an importer keeps track of the set of created body nodes and updates their COM after the scene is constructed. The calculation of the mass center should the then become part of the PhysicsServer class so its accessible from all importer classes. Another possibility is to add a member flag to each body node and update the COM on the first call to Body::PrePhysicsUpdateInternal(). cheers, Markus |
|
From: Markus R. <rol...@un...> - 2008-02-18 10:14:16
|
Hi, Hedayat Vatankhah wrote: [...] > But about selecting a repository, what about removing the spark core > libraries (oxygen, kerosin, ...) and other things which are currently in > simspark from soccer3d repository? For now, we could just split two > repositories so that the soccer3d code requires simspark installed on > the system. You want to use the libraries from the simspark repository tpgether with the simulation from the soccer3d repository, right? I think thats not practical as the two spark version have various differences that does not allow a for a simple replacement (see my 2nd mail for a list of differences) Therefore keeping a known working version (the soccer3d repo) and gradually picking changes from the simspark repo is my preferred way. > To make it simpler for users, we could then release them as > one package, so that they will not notice the change. (Also, I will > release RPM/SRPM packages for them). At least, it is more fun I think! [...] The idea to release rpm or debian packages is good I think and would ease the installation process for the user. cheers, Markus |
|
From: Sander v. D. <sgv...@gm...> - 2008-02-17 17:00:42
|
Hi, On Feb 17, 2008 5:38 AM, Joschka Boedecker < jos...@am...> wrote: > > Actually, I'm thinking now the solution would be to translate all the > masses and the geometries (like in the ODE example in the Wiki) in > order to satisfy the ODE constraint of having the COM of the body at > (0,0,0), then assign the composite mass to the body, but then place > the body at the position we intended + the original COM offset > ( (0,0,-0.286) in the above example). This way, the masses and the > geometries are in the right position, only the body's origin is a > little displaced. Like Sander pointed out, in this case, we need to > adjust the joint anchors. > Yes, that was what I was thinking. I am trying to make it this way now, by adding the masses, translate the mass to the center of the body, translate the geometries and visual parts the same distance and then translate the whole body back to get it in the right position relative to the rest of the body again. All code is in place, but.. it relies on the masses being set before the the geometries and meshes are added, so the final center of mass is determined and can be used to determine the final positions of the other parts. However, it seems that the colliders and transforms with the meshes are linked into the graph before the body is, no matter how they are ordered in the rsg files . I have tried to dig through the code to find out why this is and how to prevent this, but couldn't really get a lead. Do you have any ideas on this? I don't want to make an 'UpdateWholeTree' kind of method.. Cheers, Sander |
|
From: Hedayat V. <hed...@ai...> - 2008-02-17 12:50:47
|
Hi Markus, Thank you a lot for your responses. But about selecting a repository, what about removing the spark core libraries (oxygen, kerosin, ...) and other things which are currently in simspark from soccer3d repository? For now, we could just split two repositories so that the soccer3d code requires simspark installed on the system. To make it simpler for users, we could then release them as one package, so that they will not notice the change. (Also, I will release RPM/SRPM packages for them). At least, it is more fun I think! From that, we could move parts from soccer3d repository to simspark repo part by part, and always having one codebase. I think this will make the whole transition simpler. Thanks again, Hedayat /*Markus Rollmann <rol...@un...>*/ wrote on 02/17/2008 12:18:45 PM: > Hi all, > > Hedayat Vatankhah wrote: > > ... >> 3. What should be done?! >> > > We should decide for one repository. Going with the simspark repo > requires initial porting effort to move the current soccer3d simulation > and get it running- a lot of work to reach status quo again... > > I'd vote for staying on the soccer3d repo for the time being. > > regards, > Markus > > |
|
From: Markus R. <rol...@un...> - 2008-02-17 10:28:13
|
Hi all,
in order to set up a todo list I looked through the diff between our
two repositories (simspark and soccer3d)
There are a whole bunch of compile fixes (f), small additional helper
functions (h) and renames in the simspark repo. But there are also
some new concepts (c) and reorganizations.
[Salt library]
- (h) matrix.h InvertMatrix()
[Zeitgeist library]
- (f) class: {h,cpp}: removed some static shared_ptr instances, their
use count never gets zero resulting a memory leaks
- (h) core: catchsignal() implements a stack walker that dumps the
callstack if the server crashes (using the gnu addr2line tool)
- (c) core: keep track of already loaded bundles. The server happily
reloaded bundles multiple times
- (c) core, class: Registry of cached path name lookups. In the
soccer3d repo every node implements the lookup and caching of paths
itself (e.g. to well known server locations). This is now moved into
the core and allows a refresh of all cached paths with a simple
function call(). This change affects the whole tree, but is only a
small change to most classes.
- (h) node, leaf: GetnumberOfChildren()
- (c) leaf: assure that each child node has a unique name. Check for
name clashes and append a numeric postfix (i.e <name>1, <name>2)
- (f) various compile fixes for win32 build
[Oxygen library]
- (c) class TransformCollider. This class implements the Ode transform
collider concept for composite bodies. For this class to work various
other classes need to be adapted to be aware of a TransformCollider. I
think Sander already made a patch to port this to the soccer3d repo?
- (c) OdeObject and all derived classes: The destruction of managed
ODE objects is moved from the destructor into a separate virtual
function DestroyODEObject(). This is necessary to destroy all ODE
object in the scene in a defined order if the scene is rebuilt (e.g. a
robot that is contained in its own Space is dropped from the scene)
The major problem was that an ODE space must not be destroyed before
all contained ODE objects are destroyed (this resulted in crashs
within ODE). Currently this is not an issue for the socced3d
simulation as robots usually connect and are never destroyed again
during one server run. Unlinking a Space node and recursively
destroying all child nodes did not achieve this. See (space.cpp
Space::DestroySpaceObjects()) for the implementation.
- (h) body: Several additional wrapper methods for ODE mass
calculation Addphere, AddSphereTotal, AddBox, PrepareBoxTotal,
AddBoxTotal, AddMass...
- (h): SynchronizeParent() factored out from
PostPhysicsUpdateInternal()
- (h) camera: new LookAt() function that points the camera to a given
coordinate
- (c) FpsController: The FpsController gained a 'static update'
functionality. This enables the controller to be moved even if the
simulation is paused. In the soccer3d repo camera movement is
implemented using an ODE body. The updates of the controller therefore
only work if the simulation is running. If you pause the simulation
the camera position freezes.
- (c): The SceneServer maintains a 'scene dictionary'. The idea is to
keep track by which specific line of source code (e.g. rsg file) any
given object was created.
Each importer therefore enters the needed information into the scene
dictionary of the scene server. This is a weak mapping from 'leaf
pointer' to a file reference. A file reference is the name of a source
file and a line number.
This functionality allowed rsgedit (the spark gui tool) to show the
source code location for any object you double clicked. Maybe this
functionality is stil valuable for debug purposes? (e.g annotating
scene dumps)
[kerosin library]
- (c) OpenGLSystem: The setup of the opengl output windows was
factored out into a separate OpenGLSytem class. This was useful to
implement different opengl system (the classic SDL based, a wxWidget
win32 based and on Ogre [1] based for Mac OS X)
- (C) MaterialExternal: Oliver implemented a set of helper classes to
use material systems from the OpenGLSystem used. In his case he used
the Ogre materialsystem and translated our material definitions using
these classes.
The above list should serve as a rough overview and todo list to
cherry pick changes from the simspark repo into the soccer3d repo (if
we choose to stay with the current repo)
cheers,
Markus
[1] http://www.ogre3d.org/
|
|
From: Markus R. <rol...@un...> - 2008-02-17 08:48:59
|
Hi all, Hedayat Vatankhah wrote: > The current status of having simspark sources in two places (both > simspark and sserver projects) is annoying and will waste time. I'm > interested to remove this redundancy, but I need some help to start: > > 1. What is the purpose of simspark precisely? I thought that it is going > to hold the core libraries, but I found some soccer plugins there. I > want to know if you are going to move rcssserver to simspark completely > or not? (Which parts of the rcssserver are going to be a part of > simspark and how?) the original intent was to move the entire codebase over to the simspark repository. Reasons were are modified layout of the source tree. It should have a more strict separation between the server and the hosted simulations (in the soccer3d CVS generic and soccer specific plugins are in on place) and some further cleanups. > 2. What is the current status of simspark? (about different branches and > any other related things) In effect the new CVS was used to develop some more experimental features like - ODE space and composite body support - an additional scene importer (RoSim XML) - compile fixes and cleanups (the server builds and runs under windows) - some gui specific plugins (input plugins for wxWidgets events) - rsgedit (a gui for running spark simulations) Meanwhile most cleanups and features (notably ode space and composite bodies) found their way back to the soccer3d CVS. What's left in the simspark CVS is a somewhat streamlined directory layout and some more cleanups that could also be ported with some effort. > 3. What should be done?! We should decide for one repository. Going with the simspark repo requires initial porting effort to move the current soccer3d simulation and get it running- a lot of work to reach status quo again... I'd vote for staying on the soccer3d repo for the time being. regards, Markus |
|
From: Joschka B. <jos...@am...> - 2008-02-17 04:38:20
|
Hi again,
On Feb 16, 2008, at 6:29 PM, Joschka Boedecker wrote:
> On Feb 16, 2008, at 8:28 AM, Sander van Dijk wrote:
>
>> [...] The solution I think would be to translate the body to
>> the center of mass (as also done in the official ODE examples ),
>
> Should be the other way round, but I guess that's what you meant ;-)
> Translate the masses so that the center of the composite mass
> coincides with the body's origin.
>
> One thing I realize is that this seems to be quite a constraint when
> it comes to realism of the simulation. If you think of an example like
> a table made up of five bodies: a flat surface on the top, and four
> legs, e.g.
>
> pos_top = (0,0,0)', pos_leg_1 = (-1,-1,-0.5)', pos_leg_2 =
> (1,-1,-0.5)', pos_leg_3 = (1,1,-0.5)', pos_leg_4 = (-1,1,-0.5)'
>
> and
>
> mass_top = 0.3, mass_leg_[1,2,3,4] = 0.1
>
> and you assume point masses (which is the default in ODE, IIRC), you
> calculate the COM as:
>
> COM = (pos_top * mass_top + sum_{i=1}^{4} pos_leg_i * mass_leg_i) /
> (mass_top + sum_{i=1}^{4} mass_leg_i) %%% Latex like notation...
>
> Which is the sum of all the positions weighted by their masses divided
> by the total mass. For this example, you'll get a COM at about
> (0,0,-0.286), so we need to subtract -0.286 from the z-coordinate of
> each of the leg masses in order to fulfill the ODE constraint.
We also need to translate the top mass, of course, otherwise the COM
won't be at (0,0,0).
> However, you probably don't want to change the position of the
> geometries, since then you get a different shape from what you
> intended. So the collision shape will be correct, but leg masses will
> be slightly higher than intended.
Actually, I'm thinking now the solution would be to translate all the
masses and the geometries (like in the ODE example in the Wiki) in
order to satisfy the ODE constraint of having the COM of the body at
(0,0,0), then assign the composite mass to the body, but then place
the body at the position we intended + the original COM offset
( (0,0,-0.286) in the above example). This way, the masses and the
geometries are in the right position, only the body's origin is a
little displaced. Like Sander pointed out, in this case, we need to
adjust the joint anchors.
>
>> but I suspect this messes up joint placement..
>
> It shouldn't be a problem, since you only move the masses, not the
> body.
You're right, see above.
Cheers,
Joschka
|
|
From: Joschka B. <jos...@am...> - 2008-02-16 09:30:11
|
Hi Sander,
thanks for keeping up the work on this!
On Feb 16, 2008, at 8:28 AM, Sander van Dijk wrote:
> On Sat, Feb 16, 2008 at 12:17 AM, Hedayat Vatankhah
> <hed...@ai...> wrote:
> Yes, it crashes on my system too. :(
>
>
> :( What version + configure flags of ODE do you use? Weirdly enough,
> the three systems we tested it on all have the same version (0.9 +
> double precission) and only at one it doesn't work, so was hoping it
> was a fluke. The solution I think would be to translate the body to
> the center of mass (as also done in the official ODE examples ),
Should be the other way round, but I guess that's what you meant ;-)
Translate the masses so that the center of the composite mass
coincides with the body's origin.
One thing I realize is that this seems to be quite a constraint when
it comes to realism of the simulation. If you think of an example like
a table made up of five bodies: a flat surface on the top, and four
legs, e.g.
pos_top = (0,0,0)', pos_leg_1 = (-1,-1,-0.5)', pos_leg_2 =
(1,-1,-0.5)', pos_leg_3 = (1,1,-0.5)', pos_leg_4 = (-1,1,-0.5)'
and
mass_top = 0.3, mass_leg_[1,2,3,4] = 0.1
and you assume point masses (which is the default in ODE, IIRC), you
calculate the COM as:
COM = (pos_top * mass_top + sum_{i=1}^{4} pos_leg_i * mass_leg_i) /
(mass_top + sum_{i=1}^{4} mass_leg_i) %%% Latex like notation...
Which is the sum of all the positions weighted by their masses divided
by the total mass. For this example, you'll get a COM at about
(0,0,-0.286), so we need to subtract -0.286 from the z-coordinate of
each of the leg masses in order to fulfill the ODE constraint.
However, you probably don't want to change the position of the
geometries, since then you get a different shape from what you
intended. So the collision shape will be correct, but leg masses will
be slightly higher than intended. Hopefully, it shouldn't be a big
deal, but it's something to keep in mind when thinking about the
realism of the robot models. (I hope the example is somewhat
understandable... it's much easier to see with a drawing actually...)
> but I suspect this messes up joint placement..
It shouldn't be a problem, since you only move the masses, not the body.
> I'll have further look into it this weekend. Anyway thanks for
> testing!
Thanks a lot!
Cheers,
Joschka
|
|
From: Hedayat V. <hed...@ai...> - 2008-02-15 23:42:29
|
I'm using the official ode packages for Fedora. It is version 0.9 + single precision. (I thought that it uses double precision till now!! :) But according to it's config.h it uses single precision). I will test with another configuration ASAP. Thanks, Hedayat /*"Sander van Dijk" <sgv...@gm...>*/ wrote on 02/16/2008 02:58:29 AM: > > > On Sat, Feb 16, 2008 at 12:17 AM, Hedayat Vatankhah <hed...@ai... > <mailto:hed...@ai...>> wrote: > > Yes, it crashes on my system too. :( > > > > :( What version + configure flags of ODE do you use? Weirdly enough, > the three systems we tested it on all have the same version (0.9 + > double precission) and only at one it doesn't work, so was hoping it > was a fluke. The solution I think would be to translate the body to > the center of mass (as also done in the official ODE examples ), but > I suspect this messes up joint placement.. I'll have further look into > it this weekend. Anyway thanks for testing! > > Sander > |
|
From: Sander v. D. <sgv...@gm...> - 2008-02-15 23:28:32
|
On Sat, Feb 16, 2008 at 12:17 AM, Hedayat Vatankhah <hed...@ai...> wrote: > Yes, it crashes on my system too. :( > :( What version + configure flags of ODE do you use? Weirdly enough, the three systems we tested it on all have the same version (0.9 + double precission) and only at one it doesn't work, so was hoping it was a fluke. The solution I think would be to translate the body to the center of mass (as also done in the official ODE examples ), but I suspect this messes up joint placement.. I'll have further look into it this weekend. Anyway thanks for testing! Sander |
|
From: Hedayat V. <hed...@ai...> - 2008-02-15 23:17:04
|
/*"Sander van Dijk" <sgv...@gm...>*/ wrote on 02/15/2008 07:30:43 PM: > Hi, Hi > > Thanks. Don't know how I could have sent it out with such a blatant > error ;-) :) > I have continued working on it and made it possible to attach multiple > masses that can be translated and rotated to a single body. Using that > I changed the soccerbot such that the torso + head now consist of a > single body, as well as the lower arm + hand. Now all joint stops and > fixed joints are gone. This seems to have a great effect on stability: > I can run 3vs3 games pretty stably. LCP errors still sometimes occur, > when a faulty agent performs some weird behavior, however normal > behavior and even piles of 3 or 4 agents have not produced any LCP > errors on my system yet. Great! It should have a significant effect on speed too. (In fact, the stability comes from the server speedup I think). According to ODE docs, fixed joints have the greatest effect on the performance of ODE. > However, on at least one of our systems, the server crashes with the > ODE message that mass should be centered at the body's center. If > anybody can test it to see if this occurs on other systems too it > would be great. Also, the behavior of an agent with the new body > should still be the same. Yes, it crashes on my system too. :( > > ... > Let me know the results. If it looks alright I'll also put it on the > 3d server mailing list. > > Maybe it's a good idea then to put all patches that are out now in one > big patch? Or apply them into the CVS repository? When ready, I think it's better to apply them to CVS. Thanks, Hedayat > > Looking forward to your replies! > > Cheers, > > Sander |
|
From: Hedayat V. <hed...@ai...> - 2008-02-15 15:05:18
|
<!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;">The current status of having simspark sources in two places (both simspark and sserver projects) is annoying and will waste time. I'm interested to remove this redundancy, but I need some help to start:</p> <p style="margin-bottom: 0cm; margin-top: 0pt;">1. What is the purpose of simspark precisely? I thought that it is going to hold the core libraries, but I found some soccer plugins there. I want to know if you are going to move rcssserver to simspark completely or not? (Which parts of the rcssserver are going to be a part of simspark and how?)</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">2. What is the current status of simspark? (about different branches and any other related things)</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">3. What should be done?! </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">4. I will probably need CVS access to simspark repository!</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">Thanks,</p> <p style="margin-bottom: 0cm; margin-top: 0pt;">Hedayat</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> </body> </html> |
|
From: Hedayat V. <hed...@ai...> - 2008-02-07 15:26:51
|
Hi, It is interesting to see some activities here! :) Thanks for your patch. I've tried your patch and I found a little problem in soccerbottorso057.rsg This line: (setBoxLengths pperLenX $upperLenY $upperLenZ) should be: (setBoxLengths $upperLenX $upperLenY $upperLenZ) Good luck, Hedayat /*"Sander van Dijk" <sgv...@gm...>*/ wrote on 02/07/2008 02:07:00 AM: > Hi, > > 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. > > As you also pointed out, the mass distribution of composite bodies > still should be sorted out. > > 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. > > Sander > > 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. > |
45 messages has been excluded from this view by a project administrator.
