Menu
▾
▴
Re: [simspark-devel] PAL_draft
|
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 |
