Menu
▾
▴
simspark-devel
|
From: Ben <lgp...@16...> - 2008-10-19 02:28:51
|
Hi, all: A draft hacking version of 'PAL' is uploaded here[1]. Please have a look if you'd like to, I think we can make some dissusions about it ;-P [1] http://www.apollo3d.cn/download/physicsserver.rar Regards Ben |
|
From: Markus R. <rol...@un...> - 2008-10-19 08:07:22
|
Hi all, Ben wrote: > A draft hacking version of 'PAL' is uploaded here[1]. Please have a > look if you'd like to, I think we can make some dissusions about it > ;-P thanks for your effort Ben, this start's out looking good! ;) What is the current status of the conversion? 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.. So to get to a working point fast and to make it easily testable and hackable for a larger group of people I'd suggest adding the missing functions as stubs, that just print out 'function blabla not implemented yet!' in order to get it to compile. In this way you can see in the logs what's still missing when testing the system. Further we should put it into a new CVS branch to make it easier to follow development. 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. cheers, Markus |
|
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 |
|
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: 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: 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: 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: 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-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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X