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: Yuan X. <xu...@in...> - 2008-11-24 21:28:59
|
Hi Hedayat, 2008/11/24 Hedayat Vatankhah <hed...@ai...>: > Hi all, > I've committed rcssserver3d to simspark SVN. So, the main parts of the > server in CVS are now available in Simspark SVN. I'll move the remaining > parts soon. Great work! The new era starts ;-) > Now, we need a plan for MC for 2009; please help in this area so that we can > announce MC plan for this year before December (or a little later in the > worst case). Notice that 3DD teams should consider our plan when deciding > about their proposal. There are some tasks proposed at [1], but you may add > new tasks to the list. Please let us know about what you want to do in MC in > the following months. Also, express your opinions about the tasks and their > priorities. > What features should be added to the next version of the simulator? > I hope the simulator can support Nao Team better. I am working on Nao Team Humboldt now, and I have recommended they to use simspark instead of webots. They are interested in simspark, but only keep eye on it at present. Since, the image sensor is missing ( I have already done some work on it, and hope it will work in this week) And also, they think the installation is too difficult, and more, they hope simspark works in no-Linux system, in fact, there are already binaries for windows and Mac, but they are out of date. I hope use Scon/Cmake will make the compilation work in different system easily. > It seems that the current server (maybe version 0.6 or 0.6 with latest > updates) is good enough for the qualification round. My suggestion is to > have 2 main server releases before RoboCup 2009, the first one around > January 10th which provides all of the new features (which affect teams) > targeted for RoboCup 2009 and another one around April 10th with performance > improvements and bug fixes or other changes which don't affect the teams. > Then (hopefully!) we will present other interesting new features plus > features added by 3DD teams in RoboCup 2009. > What do you think?!! Agree, but maybe, we need to ask TC and OC. > > However, without your help, nothing will happen! > > Good luck, > Hedayat > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > -- Sincerely, Xu Yuan Institute of Informatics, Humboldt University Berlin -------------------------------------------------- |
|
From: Hedayat V. <hed...@ai...> - 2008-11-24 20:46:49
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Hi all,<br> I've committed rcssserver3d to simspark SVN. So, the main parts of the server in CVS are now available in Simspark SVN. I'll move the remaining parts soon. <br> Now, we need a plan for MC for 2009; please help in this area so that we can announce MC plan for this year before December (or a little later in the worst case). Notice that 3DD teams should consider our plan when deciding about their proposal. There are some tasks proposed at [1], but you may add new tasks to the list. Please let us know about what you want to do in MC in the following months. Also, express your opinions about the tasks and their priorities.<br> What features should be added to the next version of the simulator?<br> <br> It seems that the current server (maybe version 0.6 or 0.6 with latest updates) is good enough for the qualification round. My suggestion is to have 2 main server releases before RoboCup 2009, the first one around January 10th which provides all of the new features (which affect teams) targeted for RoboCup 2009 and another one around April 10th with performance improvements and bug fixes or other changes which don't affect the teams. Then (hopefully!) we will present other interesting new features plus features added by 3DD teams in RoboCup 2009.<br> What do you think?!! <br> <br> However, without your help, nothing will happen!<br> <br> Good luck,<br> Hedayat<br> </body> </html> |
|
From: Hedayat V. <hed...@ai...> - 2008-11-21 01:15:19
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Hi all,<br> I'm uploading spark/ directory to simspark svn. From now on, please consider rcssserver3d CVS as a read-only repository and swith to simspark svn for development work. Please check simspark svn and let me know about your opinions or any problems you find. Some files are completely empty for now, it would be nice if you add some appropriate content to them (for example the README file). I'll try to migrate other files before Saturday, but any help is highly appreciated!<br> <br> Something unrelated: as stated before, it would be nice if we can use a new build tool instead of autotools. Specially it could eliminate the need of maintaining VC project files. It seems that SCons and CMake are good candidates. Can anybody provide a comparison between these tools (or any other tool which might be better)?<br> <br> Good luck,<br> Hedayat<br> <br> </body> </html> |
|
From: Mahdi <zig...@gm...> - 2008-11-16 20:57:39
|
Hi All > On Sun, Nov 16, 2008 at 7:13 PM, Hedayat Vatankhah <hed...@ai...>wrote: > As far as I remember, I've ported all of the changes in simspark CVS to > rcssserver3d repository, and simspark CVS has not been updated since then (I > think!). > Yes it is not much work. ZigoratAssistant should be ported by Zigorat > people I think, but others can be done by any other person. Maybe I can do > it myself. But it would be nice if someone can port rsgedit and > simspark-utilities in parallel for example. > ZigoratAssistant is being cleaned up and fully documented plus some nifty and small features are being added to it. In the first time I'll update the svn with the full source. I've talked with Sahar about it. We should not rely on 3DD teams' works. So, > we thought that it is better to do the reverse: creating MC plan before 3DD > proposal submission deadline so that 3DD teams could select tasks which > don't overlap with our plan. > Our suggestion is to determine and publish MC plan for 2009 in November > (around November 26th), so that 3DD teams consider our plan when deciding > about their work. > What do you think about it? > I agree with this. Since most of the teams which participate in 3DD league have members in MC, this won't be any problem. If everyone cooperates, then planning for 3DD presentations won't be any difficult for no one. Thanks for your notice, > Hedayat > Cheers Mahdi |
|
From: Hedayat V. <hed...@ai...> - 2008-11-16 15:44:39
|
<!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 Sander and all, <br>
(CC: Sahar)<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>"Sander
van Dijk" <a class="moz-txt-link-rfc2396E" href="mailto:sgv...@gm..."><sgv...@gm...></a></b></i> wrote on ۰۸/۱۱/۱۶
03:53:05:</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:efd...@ma..."
type="cite">Hey guys,<br>
<br>
I think this structure sounds good too. How shall we go ahead? It will
probably be best if one builds and fills the structure in the SVN
repository, it's probably not that much work that it makes sense to
divide over multiple people, right? The changes in the simspark CVS
have already been ported to the rcsoccersim repository, or not? If not,
I think that's the next step after moving to SVN.<br>
</blockquote>
As far as I remember, I've ported all of the changes in simspark CVS to
rcssserver3d repository, and simspark CVS has not been updated since
then (I think!). <br>
Yes it is not much work. ZigoratAssistant should be ported by Zigorat
people I think, but others can be done by any other person. Maybe I can
do it myself. But it would be nice if someone can port rsgedit and
simspark-utilities in parallel for example. <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:efd...@ma..."
type="cite"><br>
Then I think we probably should look at basic bugs/code clean
up/documentation etc. until proposals for the 3DD league are in, so we
don't take on big changes that may overlap or interfere with work of
the 3DD teams.<br>
</blockquote>
I've talked with Sahar about it. We should not rely on 3DD teams'
works. So, we thought that it is better to do the reverse: creating MC
plan before 3DD proposal submission deadline so that 3DD teams could
select tasks which don't overlap with our plan. <br>
Our suggestion is to determine and publish MC plan for 2009 in November
(around November 26th), so that 3DD teams consider our plan when
deciding about their work.<br>
What do you think about it?<br>
<br>
Thanks for your notice,<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:efd...@ma..."
type="cite"><br>
Sander<br>
<br>
<div class="gmail_quote">On Sun, Nov 16, 2008 at 12:01 PM, Hedayat
Vatankhah <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:hed...@ai...">hed...@ai...</a>></span> wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div style="direction: ltr;" bgcolor="#ffffff" text="#000000"><span>Hi,<br>
OK, it seems that we are agree with most of the suggestions. I think
the migration process can be started now, with ZigoratAssistant and
spark/ since they don't depend on anything else and everybody seems to
agree with the proposed structure for them.<br>
<br>
Good luck,<br>
Hedayat<br>
<br>
<i><b>Mahdi
<a moz-do-not-send="true" href="mailto:zig...@gm..."
target="_blank"><zig...@gm...></a></b></i> wrote on
۰۸/۱۱/۱۶ 01:48:12:</span>
<div>
<div class="Wj3C7c"><br>
<blockquote
style="border-left: 2px solid rgb(16, 16, 255); color: navy; background-color: rgb(245, 245, 245); padding-left: 15px;"
type="cite">Hi Hedayat and all<br>
<br>
I think it's better if rsgedit is not moved anywhere and be a package
itself. Since rsgedit is not used commonly among RoboCup researchers.
The sole use of rsgedit is for developers and people who intend to run
their own simulations.<br>
<br>
In case that every top-level directory is an independent package
(which I did not know it beforehand!), I agree with most of the things
spoken till now. 5 packages seems to be fair: spark, rcssserver3d,
rsgedit, simspark-utilities, ZigoratAssistant plus a package which
contains all of the above. (Just like previous versions of 2D simulator
- rcsoccersim)<br>
<br>
Current version of the ZigoratAssistant does not rely on any part of
simulator or spark code. It's completely standalone (The only packages
needed is of course ogre and it's related ones!). So it may be as you
said. But I thought it would be better if it is placed beside the
simulator packages, since all tools and packages needed (mandatory or
optionally) would be all together. The primary good point for this idea
is that everything would be found easily and all their wiki's and user
faq's would be reachable in one place.<br>
<br>
Cheers<br>
Mahdi<br>
<br>
</blockquote>
</div>
</div>
</div>
<br>
-------------------------------------------------------------------------<br>
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge<br>
Build the coolest Linux based applications with Moblin SDK & win
great prizes<br>
Grand prize is a trip for two to an Open Source event anywhere in the
world<br>
<a moz-do-not-send="true"
href="http://moblin-contest.org/redirect.php?banner_id=100&url=/"
target="_blank">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a><br>
_______________________________________________<br>
Simspark Generic Physical MAS Simulator<br>
simspark-devel mailing list<br>
<a moz-do-not-send="true"
href="mailto:sim...@li...">sim...@li...</a><br>
<a moz-do-not-send="true"
href="https://lists.sourceforge.net/lists/listinfo/simspark-devel"
target="_blank">https://lists.sourceforge.net/lists/listinfo/simspark-devel</a><br>
<br>
</blockquote>
</div>
<br>
<pre wrap="">
<hr size="4" width="90%">
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
<a class="moz-txt-link-freetext" href="http://moblin-contest.org/redirect.php?banner_id=100&url=/">http://moblin-contest.org/redirect.php?banner_id=100&url=/</a>
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
Simspark Generic Physical MAS Simulator
simspark-devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sim...@li...">sim...@li...</a>
<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/simspark-devel">https://lists.sourceforge.net/lists/listinfo/simspark-devel</a>
</pre>
</blockquote>
</body>
</html>
|
|
From: Sander v. D. <sgv...@gm...> - 2008-11-16 12:23:09
|
Hey guys, I think this structure sounds good too. How shall we go ahead? It will probably be best if one builds and fills the structure in the SVN repository, it's probably not that much work that it makes sense to divide over multiple people, right? The changes in the simspark CVS have already been ported to the rcsoccersim repository, or not? If not, I think that's the next step after moving to SVN. Then I think we probably should look at basic bugs/code clean up/documentation etc. until proposals for the 3DD league are in, so we don't take on big changes that may overlap or interfere with work of the 3DD teams. Sander On Sun, Nov 16, 2008 at 12:01 PM, Hedayat Vatankhah <hed...@ai...>wrote: > Hi, > OK, it seems that we are agree with most of the suggestions. I think the > migration process can be started now, with ZigoratAssistant and spark/ since > they don't depend on anything else and everybody seems to agree with the > proposed structure for them. > > Good luck, > Hedayat > > *Mahdi <zig...@gm...> <zig...@gm...>* wrote on ۰۸/۱۱/۱۶ > 01:48:12: > > Hi Hedayat and all > > I think it's better if rsgedit is not moved anywhere and be a package > itself. Since rsgedit is not used commonly among RoboCup researchers. The > sole use of rsgedit is for developers and people who intend to run their own > simulations. > > In case that every top-level directory is an independent package (which I > did not know it beforehand!), I agree with most of the things spoken till > now. 5 packages seems to be fair: spark, rcssserver3d, rsgedit, > simspark-utilities, ZigoratAssistant plus a package which contains all of > the above. (Just like previous versions of 2D simulator - rcsoccersim) > > Current version of the ZigoratAssistant does not rely on any part of > simulator or spark code. It's completely standalone (The only packages > needed is of course ogre and it's related ones!). So it may be as you said. > But I thought it would be better if it is placed beside the simulator > packages, since all tools and packages needed (mandatory or optionally) > would be all together. The primary good point for this idea is that > everything would be found easily and all their wiki's and user faq's would > be reachable in one place. > > Cheers > Mahdi > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > |
|
From: Hedayat V. <hed...@ai...> - 2008-11-16 11:07:06
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
<span>Hi,<br>
OK, it seems that we are agree with most of the suggestions. I think
the migration process can be started now, with ZigoratAssistant and
spark/ since they don't depend on anything else and everybody seems to
agree with the proposed structure for them.<br>
<br>
Good luck,<br>
Hedayat<br>
<br>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;} blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important} blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important} blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important} blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>Mahdi
<a class="moz-txt-link-rfc2396E" href="mailto:zig...@gm..."><zig...@gm...></a></b></i> wrote on ۰۸/۱۱/۱۶ 01:48:12:</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:fca...@ma..."
type="cite">Hi Hedayat and all<br>
<br>
I think it's better if rsgedit is not moved anywhere and be a package
itself. Since rsgedit is not used commonly among RoboCup researchers.
The sole use of rsgedit is for developers and people who intend to run
their own simulations.<br>
<br>
In case that every top-level directory is an independent package
(which I did not know it beforehand!), I agree with most of the things
spoken till now. 5 packages seems to be fair: spark, rcssserver3d,
rsgedit, simspark-utilities, ZigoratAssistant plus a package which
contains all of the above. (Just like previous versions of 2D simulator
- rcsoccersim)<br>
<br>
Current version of the ZigoratAssistant does not rely on any part of
simulator or spark code. It's completely standalone (The only packages
needed is of course ogre and it's related ones!). So it may be as you
said. But I thought it would be better if it is placed beside the
simulator packages, since all tools and packages needed (mandatory or
optionally) would be all together. The primary good point for this idea
is that everything would be found easily and all their wiki's and user
faq's would be reachable in one place.<br>
<br>
Cheers<br>
Mahdi<br>
<br>
</blockquote>
</body>
</html>
|
|
From: Mahdi <zig...@gm...> - 2008-11-15 22:18:16
|
Hi Hedayat and all I think it's better if rsgedit is not moved anywhere and be a package itself. Since rsgedit is not used commonly among RoboCup researchers. The sole use of rsgedit is for developers and people who intend to run their own simulations. In case that every top-level directory is an independent package (which I did not know it beforehand!), I agree with most of the things spoken till now. 5 packages seems to be fair: spark, rcssserver3d, rsgedit, simspark-utilities, ZigoratAssistant plus a package which contains all of the above. (Just like previous versions of 2D simulator - rcsoccersim) Current version of the ZigoratAssistant does not rely on any part of simulator or spark code. It's completely standalone (The only packages needed is of course ogre and it's related ones!). So it may be as you said. But I thought it would be better if it is placed beside the simulator packages, since all tools and packages needed (mandatory or optionally) would be all together. The primary good point for this idea is that everything would be found easily and all their wiki's and user faq's would be reachable in one place. Cheers Mahdi |
|
From: Hedayat V. <hed...@ai...> - 2008-11-15 19:00:28
|
<!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></span>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Hi Mahdi,</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>Mahdi
<a class="moz-txt-link-rfc2396E" href="mailto:zig...@gm..."><zig...@gm...></a></b></i>
wrote on 11/15/2008 01:38:57 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:fca...@ma..." type="cite">Hi Hedayat and all<br>
<br>
For you directory listing proposal, I saw a couple of points to
mention:<br>
<br>
- As you mentioned, rename the gui to rsgedit, and I think it would be
better if the rsgedit folder goes inside the spark folder, cause it is
only spark specific application and no direct relationships to the
rcssserver3d folder.<br>
</blockquote>
The spark/ directory as I suggested contains only the core simspark
libraries (except test applications) which could be treated as a
library package. Also, rsgedit requires wxWidgets, and it is not
required for simspark, so I thought that it is better to be outside
other directories as an independent package. I did not put it under
rcssserveer3d directory, so it doesn't need to be soccer related. <br>
But if you think that rsgedit is not that big to be an independent
package, I think it should be moved inside simspark-utilities package
where other simspark applications exist.<br>
So, which is better: rsgedit as an independt package or as a component
of simspark-utilities?<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:fca...@ma..." type="cite"> <br>
- Zigorat Assistant be move out of the simspark package, into a
different dedicated package, aside from the simulator, since its
installtion is dependent on installation of ogre, which is indeed a big
package to install (or a very big tarball to config-make-install).
Since installation of the simulator itself is independent of ogre, I
suggest this opinion.<br>
</blockquote>
My suggestion was to put Zigorat Assistant as a top level directory (an
independent package) inside simspark SVN. But if you like, you can
create a separate project in SourceForge for Zigorat Assistant with a
dedicated SVN. It might be even better since ZigoratAssistant doesn't
depend on simspark code. What do you think?<br>
<br>
(Notice that in my suggestion, every top level directory is an
independent package, so my suggestion consisted of 5 separate packages:
spark/ (simspark libraries), simspark-utilities, rsgedit, rcssserver3d
and Zigorat Assistant. And (maybe) releasing a package containing
rcssservere3d/ and spark/ packages, to make it easier for users to
install the server.)<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:fca...@ma..." type="cite"> <br>
- There are two utility folders for spark in your proposal. I think
they better be merged into one, so I suggest that simspark-utilities be
removed, and every utility package go inside the utility folder inside
spark/utility<br>
</blockquote>
These utility directories are completely different. Maybe we should
rename spark/utility directory. <br>
spark/utility directory is the same as current rcssserver3d/utility
directory: containing libraries which is used in simspark/rcssserver3d.
(libraries such as rcssnet/ and tinyxml are inside this directory). So,
spark/utility directory contains libraries used by simspark libraries.
But simspark-utilities directory in my suggestion contains applications
based on simspark libraries like gendot/ and others.<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:fca...@ma..." type="cite"> <br>
- There are two kinds of monitor for the simulator. One in
rcssserver3d/rcssmonitor3d and one in simspark-utilities/monitorspark/ <br>
I can't quite get what are differences. Maybe they could be set to a
base monitor code and a soccer specific monitor.<br>
</blockquote>
Yes, current monitorspark (which I suggested to be
rcssserver3d/rcssmonitor3d) uses a SoccerRenderer plugin and is
essentially a soccer dependent monitor (which shows things like game
time, team names and scores). But simspark-utilities/monitorspark
should be a general monitor without any soccer specific things, just
having a plane.<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:fca...@ma..." type="cite"> <br>
- I propose that scripts folder be added to the rcssserver3d which
contains scripts only for the soccer server simulation.</blockquote>
I'm agree. :)<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:fca...@ma..." type="cite"> And they should
be installed in home directory of the executing user, so that changing
them would not need root privalge. Both good for developers, cause they
should change scripts more often, and for researchers.<br>
</blockquote>
I've added something based on your suggestion to the Google document
set up by Joschka. <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:fca...@ma..." type="cite"> <br>
Here is my proposal based on Yours:<br>
<br>
<span style="font-family: courier new,monospace;">simspark/</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> rcssserver3d/</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;"> </span><font face="courier new,monospace">data/<br>
ros/<br>
rsg/<br>
scripts/<br>
doc/<br>
linux/<br>
macosX/<br>
plugin/<br>
rcssagent3d/<br>
rcssmonitor3d/<br>
rcssserver3d/<br>
windows/<br>
<br style="font-family: courier new,monospace;">
</font><span style="font-family: courier new,monospace;"> spark/</span><font face="courier new,monospace"><br>
data/<br>
ros/<br>
rsg/<br>
scripts/<br>
doc/<br>
lib/<br>
kerosin/<br>
oxygen/<br>
salt/<br>
zeitgeist/<br>
macosX/<br>
plugin/<br>
rsgedit/<br>
doc/<br>
res/<br>
spark/<br>
test/<br>
coretest/<br>
utility/<br>
windows/<br style="font-family: courier new,monospace;">
</font><br>
<font face="courier new,monospace">* Each user has ".rcssserver3d"
folder which scripts go inside it</font><br>
</blockquote>
(This directory will be created when running simspark/ for the user who
runs it, and all of the scripts which a user may like to modify will be
copied to this directory. These files will be used when available.)<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:fca...@ma..." type="cite"> <span style="font-family: courier new,monospace;">*
ZigoratAssistant
as a whole another package and svn</span><br>
</blockquote>
I think it depends on you. Any other opinions?!<br>
<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:fca...@ma..." type="cite"> <br style="font-family: courier new,monospace;">
Looking forward to hear opinions<br>
<br>
Cheers<br>
Mahdi<br>
<br>
<div class="gmail_quote">On Tue, Nov 11, 2008 at 9:23 PM, Hedayat
Vatankhah <span dir="ltr"><<a moz-do-not-send="true" href="mailto:hed...@ai..." target="_blank">hed...@ai...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">Hi all,<br>
It seems that we need a kind of development plan! First, I think we
need some deadlines. Then, it would be nice if everybody says what he
is interested to do (preferably based on the current tasks and their
priorities).<br>
About the migration to simspark SVN, I suggest that we set a deadline
for it: November 21th. The current directory structure proposal is what
I said in my last email, with these modifications:<br>
1. Put ZigoratAssistant as a top level directory with its own name.<br>
2. Rename gui directory back to rsgedit since we have not decided about
the Simspark GUI yet. Fortunately SVN supports renaming, we can rename
the directory in future if needed.<br>
<br>
It would be nice if we could create a development plan up to the same
day too.<br>
Any suggestions are highly appreciated.<br>
<br>
Good luck,<br>
Hedayat<br>
</div>
<br>
</blockquote>
</div>
</blockquote>
</body>
</html>
|
|
From: Marian B. <mar...@gm...> - 2008-11-15 00:29:31
|
Best description of bug is on the picture [1]. Lines in football field behind soccer net are displayed, but nao agent not. System: Ubuntu 8.10 (also tested in Windows XP) ODE: 0.9 Agent: agentspark [1] http://img90.imageshack.us/my.php?image=bugodeik4.png Best wishes Marian Buchta |
|
From: Hedayat V. <hed...@ai...> - 2008-11-11 17:55:04
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Hi all,<br> It seems that we need a kind of development plan! First, I think we need some deadlines. Then, it would be nice if everybody says what he is interested to do (preferably based on the current tasks and their priorities).<br> About the migration to simspark SVN, I suggest that we set a deadline for it: November 21th. The current directory structure proposal is what I said in my last email, with these modifications:<br> 1. Put ZigoratAssistant as a top level directory with its own name.<br> 2. Rename gui directory back to rsgedit since we have not decided about the Simspark GUI yet. Fortunately SVN supports renaming, we can rename the directory in future if needed.<br> <br> It would be nice if we could create a development plan up to the same day too.<br> Any suggestions are highly appreciated.<br> <br> Good luck,<br> Hedayat<br> </body> </html> |
|
From: Marian B. <mar...@gm...> - 2008-11-09 22:58:40
|
Hi Sander, Ravil maybe thought the source of rcssserver3D. Feng Xue published new version of rcssserver3D in [1] for China Open 2008. This changes are not in CVS and is not part of [2] package (specially rcssserver3D.tar.gz) . Last information about change source code in changelog is mine. If I'm wrong, please correct me. Thanks. Cheers, Marian [1] http://home.ustc.edu.cn/~henry519/3d.html [2] http://home.ustc.edu.cn/~henry519/chinaopen2008.zip From: Sander van Dijk [mailto:sgv...@gm...] Sent: Sunday, November 09, 2008 11:14 PM To: Ravil Bayramgalin Cc: sim...@li... Subject: Re: [simspark-devel] Robocup 08: Where are all the sources? Dear Ravil, In the 3D simulation league it is not obligatory for teams to release their source code. There has been some discussion about this throughout the years, but it hasn't been decided to make it a rule to have all sources released. However, it is highly encouraged for teams to do this and some have released (part of) their sources. See [1], [2] and [3] for instance. If you want to be kept informed on releases (or want to discuss the rules on this subject), keep an eye on the community mailing list [4]. This list is for discussion with/amongst of the developers of the simulation server (the Maintenance Committee (MC)). Good luck, Sander van Dijk RoboCup 3D Simulation League MC [1] http://www.sourceforge.net/projects/apollo3d [2] http://www.cs.osakafu-u.ac.jp/~nakashi/download/hana08_3D_src.tar.gz [3] https://sourceforge.net/projects/littlegreenbats [4] https://lists.sourceforge.net/lists/listinfo/sserver-three-d On Sun, Nov 9, 2008 at 10:50 PM, Ravil Bayramgalin <ra...@gm...> wrote: I thought, it is obligatory to publish your source if you participate in robocup. At least I heard this is true for 2d, so if 3d differences then why? ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100 <http://moblin-contest.org/redirect.php?banner_id=100&url=/> &url=/ _______________________________________________ Simspark Generic Physical MAS Simulator simspark-devel mailing list sim...@li... https://lists.sourceforge.net/lists/listinfo/simspark-devel __________ Information from ESET NOD32 Antivirus, version of virus signature database 3597 (20081108) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com |
|
From: Sander v. D. <sgv...@gm...> - 2008-11-09 22:14:24
|
Dear Ravil, In the 3D simulation league it is not obligatory for teams to release their source code. There has been some discussion about this throughout the years, but it hasn't been decided to make it a rule to have all sources released. However, it is highly encouraged for teams to do this and some have released (part of) their sources. See [1], [2] and [3] for instance. If you want to be kept informed on releases (or want to discuss the rules on this subject), keep an eye on the community mailing list [4]. This list is for discussion with/amongst of the developers of the simulation server (the Maintenance Committee (MC)). Good luck, Sander van Dijk RoboCup 3D Simulation League MC [1] http://www.sourceforge.net/projects/apollo3d [2] http://www.cs.osakafu-u.ac.jp/~nakashi/download/hana08_3D_src.tar.gz [3] https://sourceforge.net/projects/littlegreenbats [4] https://lists.sourceforge.net/lists/listinfo/sserver-three-d On Sun, Nov 9, 2008 at 10:50 PM, Ravil Bayramgalin <ra...@gm...> wrote: > I thought, it is obligatory to publish your source if you participate > in robocup. At least I heard this is true for 2d, so if 3d differences > then why? > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > |
|
From: Ravil B. <ra...@gm...> - 2008-11-09 21:50:42
|
I thought, it is obligatory to publish your source if you participate in robocup. At least I heard this is true for 2d, so if 3d differences then why? |
|
From: Hedayat V. <hed...@ai...> - 2008-10-31 15:28:21
|
<!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;">This is the current version of my proposed directory structure. Please express your opinions about it. I think I'll start the migration soon (any volunteers?!). (Hey, is there any way for migrating rcssserver3d CVs to simspark in Sourceforge without losing CVS history?)</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">The structure:</p> <p style="margin-bottom: 0cm; margin-top: 0pt;">spark/<br> doc/<br> plugin/</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> lib/<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> kerosin/</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> oxygen/<br> salt/<br> zeitgeist/<br> spark/<br> utility/<br> test/<br> coretest/<br> ...<br> (test apps)<br> data/ <br> rsg/ (including common rsg files like boxspheres/ directory, and probably rsg/jointtest(?)) <br> ros/ (exists only if there are any general ros files, sample ros files might go inside simspark-utilities/samplesim)<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> scripts/<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> windows/</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> macosX/<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">simspark-utilities/ (nobody should use soccer plugins here.)<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> gendot/<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> samplesim/ (a simspark clone which runs a simulation with a very simple area in a simple monitor with no soccer specific content)<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> ros/</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> rsg/ (agents such as legged sphere and car agents are here)(Well, humanoid agents might be considered as general agents too?!)<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> plugin/<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> sampleagent/ (agentspark, but with no soccer specific behaviours (nao and soccer bot behaviours)<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> monitorspark/ (a simple general monitor: the old monitor spark but with no soccer specific content, like what is used in samplesim)</p> <p style="margin-bottom: 0cm; margin-top: 0pt;">(may be called samplemonitor instead of monitorspark)<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"></p> <p style="margin-bottom: 0cm; margin-top: 0pt;">gui/ (previously rsgedit, to be extended as the simspark's GUI (still no comment?!!)<br> res/<br> doc/<br> <br> rcssserver3d/<br> doc/</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> rcssagent3d/ (agentspark but only with nao and soccerbot behaviours. it might become a more soccer oriented agent in future?!)<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> rcssmonitor3d/ (monitorspark or ZigoratAssistant, to become a beautiful soccer monitor!)<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> rcssserver3d/ (simspark. we could create a simspark symbolic link during installation as a compatibility feature.)<br> plugin/ <br> data/<br> rsg/<br> ros/<br> linux/<br> windows/ <br> macosX/</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">About the build system: it seems that we are going to use SCons instead of autotools. If there is anybody who knows enough about SCons and can do the migration quickly, we can do it during the SVN migration. If not, I think we should keep using autotools for now and start creating SCons scripts simultaneously.</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">And in the current suggestion, every top-level is a separate package with an independent build structure. Also, we provide each of them as a separate package. But, to simplify user experience, we can release all-in-one packages containing all of these directories which can be built and installed at once (like the current packages).<br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> <br> Good luck,</p> <p style="margin-bottom: 0cm; margin-top: 0pt;">Hedayat<br> </p> </body> </html> |
|
From: Hedayat V. <hed...@ai...> - 2008-10-24 19:55:55
|
Hi Joschka and all, /*Joschka Boedecker <jos...@am...>*/ wrote on 10/23/2008 05:49:42 PM: > Hi, > > On Oct 23, 2008, at 4:34 AM, Hedayat Vatankhah wrote: >> Hi, >>> ... >> I'm not sure, maybe Ben knows better than me now. What do you think Ben? >> I think we should try to reuse the available code as much as >> possible; but in that case I think we should feel free to modify PAL >> as we wish. So, we will probably come up with a derivation of PAL >> inside our project or (depending on the PAL developer) we will >> essentially develop PAL alongside our project. >> > > Yes, this would be a possibility. I just thought, if PAL restricts us > too much and we don't need to take care of integrating that many > different engines, it might be easier for us to develop something on > our own. But I agree that we should take advantage as much as possible > of what's there already. You're right. >> >> "Zigorat Team" <zig...@gm...> wrote on 10/21/2008 12:37:06 AM: >>> ... >> OK, I'll start with a suggestion and some questions. First, my >> proposed directory structure (still needs work!): >> > Thanks for getting the discussion started :-) :) You're welcome! >> spark/ >> doc/ >> plugin/ >> kerosin/ >> oxygen/ >> salt/ >> zeitgeist/ >> spark/ >> utility/ >> test/ >> agenttest/ > > I think agenttest was from the spheres simulator, but I might be wrong... Well I didn't thought about these names! :) I just wanted to say "test apps!" and so I wrote some names ended with "test". >> >> coretest/ >> ... >> (test apps) >> data/ >> rsg/ (including common rsg files like boxspheres/ directory) >> ros/ >> windows/ >> macosX/ > > Sounds good. > >> >> gendot/ >> >> rsgedit/ >> res/ >> doc/ > > This might become a directory 'gui' inside simspark, but that depends > on what we decide about the GUI. It seems to me that rsgedit could be > a good starting point for an integrated GUI, and the ZigoratAssistant > could replace monitorspark, but we should discuss about that. So, we want to have a GUI for simspark, then having a gui directory is reasonable. And it seems that it'll be an integrated GUI, so I think renaming rsgedit directory to gui in the proposed structure is enough. right? (And something like monitorspark or ZigoratAssistant are not considered as a part of simspark GUI?) >> >> >> soccer/ (propose a better name: simspark-soccer, rcssserver3d, >> ... ?) > > Right, we could maybe use rcssserver3d here. OK, it's rcssserver3d for now! Any other opinions?! :) >> doc/ >> agentspark/ >> monitorspark/ >> simspark/ (I think we should rename this application, >> rcssserver3d might be a condidate!) > > I would be in favor of keeping simspark: the name has been used in > several papers, and it's not soccer specific. Since agentspark, > monitorspark, and simspark, are not soccer specific (we only used them > for that so far), maybe we should take them out of the soccer > directory. What do you think? > But then the question is: what should be left in the soccer directory? > Only the plugins and the data? How about the soccer-specific agent > behaviors and initialization files for simspark? Difficult... don't > have a good solution now either :-( I thought a little about it when I wanted to propose the directory structure. At that time I felt that these applications are soccer specific. But, I checked agentspark again and yes, it's not soccer specific and so it should be inside the "simspark-utilities" directory (besides gendot). But that's true when we consider agentspark as a sample source code, not as an application. As an application, it is currently a sample nao agent controller. In fact, I'm completely confused about these applications!! We can consider simspark and monitorspark as general applications (not soccer specific) since you can run a completely different simulation by changing ruby scripts. But, if you change the ruby scripts, do you still run the same application?! In fact, if you remove all soccer specific functions from simspark and monitorspark, then what remains from both of these applications are almost the same thing! So, maybe simspark and monitorspark are in fact one application! The only difference is that simspark runs simspark.rb, but monitorspark runs monitorspark.rb!! :) Considering these, I feel that when you change simspark to run another simulation, you've created a different application and you'll probably prefer to call it something other than simspark, since it's not easy to run two different simulations using the same simspark application. This is why I thought that currently, simspark, agentspark and monitorspark are essentially soccer specific and it might be better to rename these applications to something soccer specific. But certainly, sticking with simspark is really good from historical point of view. Renaming simspark to something else could be problematic for users. So I agree with keeping the current names for these applications, but I think we can safely consider them as soccer applications. (If we decided to rename these applications, we should provide some backward compatibility for awhile, for example by creating symbolic links with the old names) >> plugin/ >> data/ >> rsg/ >> ros/ >> linux/ >> windows/ >> macosX/ >> >> Now, some questions: >> 1. Are we going to use a new build system (instead of autotools)? > > I would be very much in favor of that (for instance using Scons). Let's decide! Anybody against SCons?!! >> 2. Do we want to separate building spark from other apps? Currently >> in simspark CVS, spark and contrib directories have separate build >> structures (you should build them independently). This way, we can >> split the server package to more than one package: a library package >> (spark directory, creating simspark package), rsgedit package, and >> rcssserver3d package. But something like gendot is too small, so we >> may put such small applications in a directory (like contrib/ >> directory in simspark CVS), maybe with a name such as >> "simspark-utilities" or a better name. > > This sounds good. >> Another option is to rename spark/test/ to spark/apps/ and put gendot >> there. >> But if we are going to provide a single package containing all source >> code, having one build system for the complete project might be >> better and is simpler for the users. > > That's also true. How about having a complete build system, but > splitting the packages? mmm.... sorry, I can't get it! :( If the packages are separate, they should have separate build systems so that a package is usable by itself. Maybe we can have separate packages, but providing a "super package" which for example contains a small script to build and install the contained packages? Did you mean something like this? >> 3. spark's libraries (kerosin, ...) might be moved to spark/lib/ >> sub-directory! >> > > Good idea, I think. 2 votes for now! >>> There is a slight problem I've been noticing since a long time >>> ago, which the ruby files with the options in them, are installed in >>> typical application installation folder, like /usr/local/bin, which >>> makes it hard to change the simulators options, as they are needed. >>> I suggest some of the configuration files be moved to the local >>> folder of ~/.rcssserver3D/ >> I think it's a good suggestion. We can do what is currently done with >> files such as kerosin.rb: copying the installed configuration files >> into ~/.rcssserver3D if they don't exist, and using ~/.rcssserver3D >> files when available. > > Sounds reasonable. > > Cheers, > Joschka Thanks a lot, Hedayat |
|
From: Joschka B. <jos...@am...> - 2008-10-23 14:20:44
|
Hi, On Oct 23, 2008, at 4:34 AM, Hedayat Vatankhah wrote: > Hi, >> Hmm, in that case, we should think about whether PAL is really the >> best choice for us. We could only take it as an inspiration and >> implement our own, hopefully more complete, abstraction for the >> engines we would like to integerate (ODE, Bullet, and PhysX in my >> case). What do you think? > I'm not sure, maybe Ben knows better than me now. What do you think > Ben? > I think we should try to reuse the available code as much as > possible; but in that case I think we should feel free to modify PAL > as we wish. So, we will probably come up with a derivation of PAL > inside our project or (depending on the PAL developer) we will > essentially develop PAL alongside our project. > Yes, this would be a possibility. I just thought, if PAL restricts us too much and we don't need to take care of integrating that many different engines, it might be easier for us to develop something on our own. But I agree that we should take advantage as much as possible of what's there already. > > "Zigorat Team" <zig...@gm...> wrote on 10/21/2008 12:37:06 AM: >> Hi all >> >> I agree with Joschka on restructuring directories and cleaning up >> the codes. > OK, I'll start with a suggestion and some questions. First, my > proposed directory structure (still needs work!): > Thanks for getting the discussion started :-) > spark/ > doc/ > plugin/ > kerosin/ > oxygen/ > salt/ > zeitgeist/ > spark/ > utility/ > test/ > agenttest/ I think agenttest was from the spheres simulator, but I might be wrong... > > coretest/ > ... > (test apps) > data/ > rsg/ (including common rsg files like boxspheres/ directory) > ros/ > windows/ > macosX/ Sounds good. > > gendot/ > > rsgedit/ > res/ > doc/ This might become a directory 'gui' inside simspark, but that depends on what we decide about the GUI. It seems to me that rsgedit could be a good starting point for an integrated GUI, and the ZigoratAssistant could replace monitorspark, but we should discuss about that. > > > soccer/ (propose a better name: simspark-soccer, > rcssserver3d, ... ?) Right, we could maybe use rcssserver3d here. > > doc/ > agentspark/ > monitorspark/ > simspark/ (I think we should rename this application, > rcssserver3d might be a condidate!) I would be in favor of keeping simspark: the name has been used in several papers, and it's not soccer specific. Since agentspark, monitorspark, and simspark, are not soccer specific (we only used them for that so far), maybe we should take them out of the soccer directory. What do you think? But then the question is: what should be left in the soccer directory? Only the plugins and the data? How about the soccer-specific agent behaviors and initialization files for simspark? Difficult... don't have a good solution now either :-( > > plugin/ > data/ > rsg/ > ros/ > linux/ > windows/ > macosX/ > > Now, some questions: > 1. Are we going to use a new build system (instead of autotools)? I would be very much in favor of that (for instance using Scons). > > 2. Do we want to separate building spark from other apps? Currently > in simspark CVS, spark and contrib directories have separate build > structures (you should build them independently). This way, we can > split the server package to more than one package: a library package > (spark directory, creating simspark package), rsgedit package, and > rcssserver3d package. But something like gendot is too small, so we > may put such small applications in a directory (like contrib/ > directory in simspark CVS), maybe with a name such as "simspark- > utilities" or a better name. This sounds good. > Another option is to rename spark/test/ to spark/apps/ and put > gendot there. > But if we are going to provide a single package containing all > source code, having one build system for the complete project might > be better and is simpler for the users. That's also true. How about having a complete build system, but splitting the packages? > > 3. spark's libraries (kerosin, ...) might be moved to spark/lib/ sub- > directory! > Good idea, I think. >> There is a slight problem I've been noticing since a long time >> ago, which the ruby files with the options in them, are installed >> in typical application installation folder, like /usr/local/bin, >> which makes it hard to change the simulators options, as they are >> needed. I suggest some of the configuration files be moved to the >> local folder of ~/.rcssserver3D/ > I think it's a good suggestion. We can do what is currently done > with files such as kerosin.rb: copying the installed configuration > files into ~/.rcssserver3D if they don't exist, and using > ~/.rcssserver3D files when available. Sounds reasonable. Cheers, Joschka |
|
From: Hedayat V. <hed...@ai...> - 2008-10-23 14:08:18
|
/*Joschka Boedecker <jos...@am...>*/ wrote on 10/23/2008 04:59:46 PM: > Hi Hedayat, Hi Joschka, > > On Oct 23, 2008, at 9:10 PM, Hedayat Vatankhah wrote: > >> Hi all, >> Some weeks ago I had a discussion with an @Home participant about our >> simulator. He was interested in our simulator, and he felt that it >> would be really nice if the server provides the possibility of >> controlling its simulation loop with external agents. He thinks that >> it is really nice feature for agent development. I'm agree with him, >> and it is not hard to add that feature to the simulator. What do you >> think about it? I think it is nice to be added to our TODO list. > > Do you mean something like the Sync-Mode in the 2D simulator (the > simulator waits until all the agents have send a message that they are > done for this step, and then the loop is advanced)? This would be a > nice addition, indeed. Yes! Thanks, Bye, Hedayat > > Cheers, > Joschka |
|
From: Joschka B. <jos...@am...> - 2008-10-23 13:30:49
|
Hi Hedayat, On Oct 23, 2008, at 9:10 PM, Hedayat Vatankhah wrote: > Hi all, > Some weeks ago I had a discussion with an @Home participant about > our simulator. He was interested in our simulator, and he felt that > it would be really nice if the server provides the possibility of > controlling its simulation loop with external agents. He thinks that > it is really nice feature for agent development. I'm agree with him, > and it is not hard to add that feature to the simulator. What do you > think about it? I think it is nice to be added to our TODO list. Do you mean something like the Sync-Mode in the 2D simulator (the simulator waits until all the agents have send a message that they are done for this step, and then the loop is advanced)? This would be a nice addition, indeed. Cheers, Joschka |
|
From: Hedayat V. <hed...@ai...> - 2008-10-23 12:48:52
|
<!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;">Some weeks ago I had a discussion with an @Home participant about our simulator. He was interested in our simulator, and he felt that it would be really nice if the server provides the possibility of controlling its simulation loop with external agents. He thinks that it is really nice feature for agent development. I'm agree with him, and it is not hard to add that feature to the simulator. What do you think about it? I think it is nice to be added to our TODO list.</p> <p style="margin-bottom: 0cm; margin-top: 0pt;"><br> </p> <p style="margin-bottom: 0cm; margin-top: 0pt;">Good luck,</p> <p style="margin-bottom: 0cm; margin-top: 0pt;">Hedayat<br> </p> </body> </html> |
|
From: Hedayat V. <hed...@ai...> - 2008-10-22 19:36:40
|
Hi,
> Hmm, in that case, we should think about whether PAL is really the
> best choice for us. We could only take it as an inspiration and
> implement our own, hopefully more complete, abstraction for the
> engines we would like to integerate (ODE, Bullet, and PhysX in my
> case). What do you think?
I'm not sure, maybe Ben knows better than me now. What do you think Ben?
I think we should try to reuse the available code as much as possible;
but in that case I think we should feel free to modify PAL as we wish.
So, we will probably come up with a derivation of PAL inside our project
or (depending on the PAL developer) we will essentially develop PAL
alongside our project.
/*"Zigorat Team" <zig...@gm...>*/ wrote on 10/21/2008 12:37:06 AM:
> Hi all
>
> I agree with Joschka on restructuring directories and cleaning up
> the codes.
OK, I'll start with a suggestion and some questions. First, my proposed
directory structure (still needs work!):
spark/
doc/
plugin/
kerosin/
oxygen/
salt/
zeitgeist/
spark/
utility/
test/
agenttest/
coretest/
...
(test apps)
data/
rsg/ (including common rsg files like boxspheres/ directory)
ros/
windows/
macosX/
gendot/
rsgedit/
res/
doc/
soccer/ (propose a better name: simspark-soccer, rcssserver3d, ... ?)
doc/
agentspark/
monitorspark/
simspark/ (I think we should rename this application,
rcssserver3d might be a condidate!)
plugin/
data/
rsg/
ros/
linux/
windows/
macosX/
Now, some questions:
1. Are we going to use a new build system (instead of autotools)?
2. Do we want to separate building spark from other apps? Currently in
simspark CVS, spark and contrib directories have separate build
structures (you should build them independently). This way, we can split
the server package to more than one package: a library package (spark
directory, creating simspark package), rsgedit package, and rcssserver3d
package. But something like gendot is too small, so we may put such
small applications in a directory (like contrib/ directory in simspark
CVS), maybe with a name such as "simspark-utilities" or a better name.
Another option is to rename spark/test/ to spark/apps/ and put gendot
there.
But if we are going to provide a single package containing all source
code, having one build system for the complete project might be better
and is simpler for the users.
3. spark's libraries (kerosin, ...) might be moved to spark/lib/
sub-directory!
> There is a slight problem I've been noticing since a long time ago,
> which the ruby files with the options in them, are installed in
> typical application installation folder, like /usr/local/bin, which
> makes it hard to change the simulators options, as they are needed. I
> suggest some of the configuration files be moved to the local folder
> of ~/.rcssserver3D/
I think it's a good suggestion. We can do what is currently done with
files such as kerosin.rb: copying the installed configuration files into
~/.rcssserver3D if they don't exist, and using ~/.rcssserver3D files
when available.
Good luck,
Hedayat
> That would even working easier for teams which use network based
> user accounts and each member does independent jobs from the others
> (thus needing his own configuration, like testing a trainer for future
> purposes).
>
> Cheers
> Mahdi
>
> On Mon, Oct 20, 2008 at 5:33 PM, Joschka Boedecker
> <jos...@am...
> <mailto:jos...@am...>> wrote:
>
> Hi all,
>
> On Oct 20, 2008, at 9:49 PM, Hedayat Vatankhah wrote:
>
> > Hi,
> >
> > Ben <lgp...@16... <mailto:lgp...@16...>> wrote on
> ۰۸/۱۰/۲۰ 12:18:33:
> >> Hi,
> >> >What is the current status of the conversion?
> >> It's just a try and I think 'PAL' itself is not mature, some
> >> interfaces are missing, for example, 'dJointFeedBack',(maybe lost
> >> for *general*) and strange properties of a certain physical engine.
> >>
> > Yes, the last time I checked PAL (a year ago), I found that it have
> > a lot of functionality missing (different things for different
> > engines) and it seems that it have not been updated since then. I
> > guess it doesn't have composite body support for ODE for example. I
> > think I've sent an email to this list and talked about it. Anyway,
> > working on PAL maybe still provide some time savings for us.
>
> Hmm, in that case, we should think about whether PAL is really the
> best choice for us. We could only take it as an inspiration and
> implement our own, hopefully more complete, abstraction for the
> engines we would like to integerate (ODE, Bullet, and PhysX in my
> case). What do you think?
>
> >
> >> >It seems that a significant part of the utility functions are
> still
> >> >missing, like most of the mass calculation function in
> body.cpp etc.
> >> >That's to be expected, as it's tedious work..
> >> Yes, that's really tedious.
> >>
> >> >Further we should put it into a new CVS branch to make it
> easier to
> >> >follow development.
> >> I think so ;-)
>
>
> I would suggest that before we start the new development, we might
> want to move our sources into the SVN at the simspark project (I
> activated the SVN yesterday), restructuring the directories, and
> cleaning up in the progress (for instance, purge legacy projects like
> rcssmonitor3d-lite, etc). Let's maybe try to come up with a plan for
> the directory structure as a first task.
>
> Cheers,
> Joschka
>
|
|
From: Zigorat T. <zig...@gm...> - 2008-10-20 21:07:21
|
Hi all I agree with Joschka on restructuring directories and cleaning up the codes. There is a slight problem I've been noticing since a long time ago, which the ruby files with the options in them, are installed in typical application installation folder, like /usr/local/bin, which makes it hard to change the simulators options, as they are needed. I suggest some of the configuration files be moved to the local folder of ~/.rcssserver3D/ That would even working easier for teams which use network based user accounts and each member does independent jobs from the others (thus needing his own configuration, like testing a trainer for future purposes). Cheers Mahdi On Mon, Oct 20, 2008 at 5:33 PM, Joschka Boedecker < jos...@am...> wrote: > Hi all, > > On Oct 20, 2008, at 9:49 PM, Hedayat Vatankhah wrote: > > > Hi, > > > > Ben <lgp...@16...> wrote on ۰۸/۱۰/۲۰ 12:18:33: > >> Hi, > >> >What is the current status of the conversion? > >> It's just a try and I think 'PAL' itself is not mature, some > >> interfaces are missing, for example, 'dJointFeedBack',(maybe lost > >> for *general*) and strange properties of a certain physical engine. > >> > > Yes, the last time I checked PAL (a year ago), I found that it have > > a lot of functionality missing (different things for different > > engines) and it seems that it have not been updated since then. I > > guess it doesn't have composite body support for ODE for example. I > > think I've sent an email to this list and talked about it. Anyway, > > working on PAL maybe still provide some time savings for us. > > Hmm, in that case, we should think about whether PAL is really the > best choice for us. We could only take it as an inspiration and > implement our own, hopefully more complete, abstraction for the > engines we would like to integerate (ODE, Bullet, and PhysX in my > case). What do you think? > > > > >> >It seems that a significant part of the utility functions are still > >> >missing, like most of the mass calculation function in body.cpp etc. > >> >That's to be expected, as it's tedious work.. > >> Yes, that's really tedious. > >> > >> >Further we should put it into a new CVS branch to make it easier to > >> >follow development. > >> I think so ;-) > > > I would suggest that before we start the new development, we might > want to move our sources into the SVN at the simspark project (I > activated the SVN yesterday), restructuring the directories, and > cleaning up in the progress (for instance, purge legacy projects like > rcssmonitor3d-lite, etc). Let's maybe try to come up with a plan for > the directory structure as a first task. > > Cheers, > Joschka > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > |
|
From: Joschka B. <jos...@am...> - 2008-10-20 14:03:28
|
Hi all, On Oct 20, 2008, at 9:49 PM, Hedayat Vatankhah wrote: > Hi, > > Ben <lgp...@16...> wrote on ۰۸/۱۰/۲۰ 12:18:33: >> Hi, >> >What is the current status of the conversion? >> It's just a try and I think 'PAL' itself is not mature, some >> interfaces are missing, for example, 'dJointFeedBack',(maybe lost >> for *general*) and strange properties of a certain physical engine. >> > Yes, the last time I checked PAL (a year ago), I found that it have > a lot of functionality missing (different things for different > engines) and it seems that it have not been updated since then. I > guess it doesn't have composite body support for ODE for example. I > think I've sent an email to this list and talked about it. Anyway, > working on PAL maybe still provide some time savings for us. Hmm, in that case, we should think about whether PAL is really the best choice for us. We could only take it as an inspiration and implement our own, hopefully more complete, abstraction for the engines we would like to integerate (ODE, Bullet, and PhysX in my case). What do you think? > >> >It seems that a significant part of the utility functions are still >> >missing, like most of the mass calculation function in body.cpp etc. >> >That's to be expected, as it's tedious work.. >> Yes, that's really tedious. >> >> >Further we should put it into a new CVS branch to make it easier to >> >follow development. >> I think so ;-) I would suggest that before we start the new development, we might want to move our sources into the SVN at the simspark project (I activated the SVN yesterday), restructuring the directories, and cleaning up in the progress (for instance, purge legacy projects like rcssmonitor3d-lite, etc). Let's maybe try to come up with a plan for the directory structure as a first task. Cheers, Joschka |
|
From: Hedayat V. <hed...@ai...> - 2008-10-20 13:33:40
|
Hi, /*Ben <lgp...@16...>*/ wrote on ۰۸/۱۰/۲۰ 12:18:33: > Hi, > >What is the current status of the conversion? > It's just a try and I think 'PAL' itself is not mature, some interfaces are missing, for example, 'dJointFeedBack',(maybe lost for *general*) and strange properties of a certain physical engine. > Yes, the last time I checked PAL (a year ago), I found that it have a lot of functionality missing (different things for different engines) and it seems that it have not been updated since then. I guess it doesn't have composite body support for ODE for example. I think I've sent an email to this list and talked about it. Anyway, working on PAL maybe still provide some time savings for us. Nice work, Goodbye Hedayat > >It seems that a significant part of the utility functions are still > >missing, like most of the mass calculation function in body.cpp etc. > >That's to be expected, as it's tedious work.. > Yes, that's really tedious. > > >Further we should put it into a new CVS branch to make it easier to > >follow development. > I think so ;-) > > >An alternative might be to first refactor the existing > >physics systems as a plugin first, move it into plugins/ and create the > >the new PAL pyhsics system there as an alternative you can switch to. In > >this way the PAL pyhsics can stay in CVS head. > I'd ever try the 'plugin' way, but some classes should be abstracted by > ourselves, which has been done in 'PAL'. Maybe it's a coincide, I'm not > sure. > > Regards > Ben > > > > > ------------------------------------------------------------------------ > [���] ��������ע¥��-����ʤ�� > <http://popme.163.com/link/003985_1010_7027.html> > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > ------------------------------------------------------------------------ > > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > |
|
From: Ben <lgp...@16...> - 2008-10-20 08:49:45
|
Hi, >What is the current status of the conversion? It's just a try and I think 'PAL' itself is not mature, some interfaces are missing, for example, 'dJointFeedBack',(maybe lost for *general*) and strange properties of a certain physical engine. >It seems that a significant part of the utility functions are still >missing, like most of the mass calculation function in body.cpp etc. >That's to be expected, as it's tedious work.. Yes, that's really tedious. >Further we should put it into a new CVS branch to make it easier to >follow development. I think so ;-) >An alternative might be to first refactor the existing >physics systems as a plugin first, move it into plugins/ and create the >the new PAL pyhsics system there as an alternative you can switch to. In >this way the PAL pyhsics can stay in CVS head. I'd ever try the 'plugin' way, but some classes should be abstracted by ourselves, which has been done in 'PAL'. Maybe it's a coincide, I'm not sure. Regards Ben |
45 messages has been excluded from this view by a project administrator.
