Menu
▾
▴
simspark-devel
|
From: Markus R. <rol...@un...> - 2008-04-06 12:50:19
|
Hi, Ben schrieb: > I have make a update of integrated_agent[1], please have a look, > thank you! thanks Ben for your work. I looked at the source code and it's getting better ;-) I have some comments: Concerning the base behavior class. - I wonder if it's better to give the prdicate list directly to the think method of the behavior class. In the current implementation the predicates are collected, then converted into a string. The behavior class then parses the string back into predicates. That's much overhead. The TrainControl::EndCycle() method get's the senselist from the agentaspect. This could be passed on to the behavior class directly. - Some technical issues. If you hold a reference to another node in the system please use the CachedPath template together with the RegisterCachedPath() method (for the mTrainControl reference). Same for the mTrainControl reference in the TrainControl class. - I think we should change the behavior class to cach the command string it sends. I.e. move the mCmdMsg member and the SetCmdMsg() member to the base class and change the think(...) to return void. In this way it is possible to use the ruby interface for behavior classes that are not derived from the soccerbehavior, i.e make it available to other simulations. Concerning the base behavior class. - You are using cerrs and stdouts to give agent responses instead of the Logserver (i.e. GetLog()->Normal() << "msg"). Maybe we should introduce a new log channel for agent responses? - don't run the debug.rb script from SoccerbotBehavior. This should only be done from classes that derive from SoccerbotBehavior. I.e. it is specific to your agent implementation. Concerning the TrainControl class - I think we could use a std::set<shared_ptr<Client> TClientSet instead of the TClientList. This makes searching for a client instance easier (operator == and < are defined for shared_ptr) and makes sure that each behavior instance is registered only once. - I think we should rename the mClientSize member that reflects its purpose, maybe to mNextClientId? > I have a question: can we make the library zeitgeist, kerosin, oxygen > as dll in windows? I don't think it is possible without some changes. The problem is that the different libraries are dependent on each other and access implementation details from each other. However on windows only symbols (i.e. function names and members) that are explicitly declared are exported (i.e. visible from outside the .dll). So declaring all required symbols as DLL-Export is quite a lot of work. In contrast Linux and MacOs work the other way round. By default _all_ symbols are visible. On these platforms it's therefore no problem to load our libraries dynamically. cheers, Markus > [1] www.apollo3d.cn/download/integrated_agent_v3.tar.gz |
|
From: Ben <lgp...@16...> - 2008-04-10 19:18:52
|
Hi, Markus: >thanks Ben for your work. I looked at the source code and it's getting >better ;-) It's a pleasure :) 1. >I have some comments: >- I wonder if it's better to give the prdicate list directly to the >think method of the behavior class. In the current implementation the >predicates are collected[...] >The TrainControl::EndCycle() method get's the senselist from the >agentaspect. This could be passed on to the behavior class directly. This can reduce the time of 'parse', and I think 'GameControlServer' should overload 'Parse()' to accept 'predicatelist'. but when the behavior want to print the message received, is predicate better? 2. >- You are using cerrs and stdouts to give agent responses instead of the >Logserver (i.e. GetLog()->Normal() << "msg"). Maybe we should introduce >a new log channel for agent responses? I copy it from 'agentspark'. A new log channel is appreciated. 3. > So declaring all required symbols as DLL-Export is quite a lot of work. define macro SHARED_LIB_COMPILE, and add CLASS_EXPORT in each function can make it work, right? This is really lots of work. Lastly, I've make a update here[1], and I add a 'SphereBehavior' which can be controlled by 'GameInput'. There is an issue: the keys should be pressed as soon as the simulation started, otherwise the agent can not be controlled, I don't know why :( Thanks! Best wishes! Ben [1] www.apollo3d.cn/download/sparkgame.tar.gz |
|
From: Markus R. <rol...@un...> - 2008-04-11 17:35:34
|
Hi, Ben schrieb: > 1. >I have some comments: > >- I wonder if it's better to give the prdicate list directly to the > >think method of the behavior class. In the current implementation the > >predicates are collected[...] > >The TrainControl::EndCycle() method get's the senselist from the > >agentaspect. This could be passed on to the behavior class directly. > This can reduce the time of 'parse', and I think 'GameControlServer' > should overload 'Parse()' to accept 'predicatelist'. > but when the behavior want to print the message received, is predicate > better? I think using predicates list in both directions (for senses and actions) is better for performance. As it completely avoids the parsing overhead. Overloading the GameControlServer Parse() to accept a predicate list is a good idea. You are right that the internal agent might want to print the received senses. For this case we could provide a method in the base Behavior class that looks up the parser in the GameControl server and generates the string on demand for debug purposes. For the main game loop however I'd prefer the predicate lists. This method could be refactored from TrainControl::EndCycle to lookup the parser and call generate with a given senselist parameter. > 2. >- You are using cerrs and stdouts to give agent responses instead of > the > >Logserver (i.e. GetLog()->Normal() << "msg"). Maybe we should introduce > >a new log channel for agent responses? > I copy it from 'agentspark'. A new log channel is appreciated. The most simple solution would be a single logchannel for all integrated agents. A more elaborate solution would provide a channel for each agent. Opinions? [...] > Lastly, I've make a update here[1], and I add a 'SphereBehavior' which > can be controlled by 'GameInput'. There is an issue: the keys should be > pressed as soon as the simulation started, otherwise the agent can not > be controlled, I don't know why :( sorry, I didn't test this game. But I looked over the last version of the integrated agent patch and I'd say that it's ready for inclusion into CVS! ;) The change concerning the use of predicate lists would be nice however ;) cheers, Markus |
|
From: Ben <lgp...@16...> - 2008-04-12 10:29:10
|
Hi Markus, 1. >The most simple solution would be a single logchannel for all integrated >agents. A more elaborate solution would provide a channel for each >agent. Opinions? A channel with different kinds of streams for each agent is perfect. Then an agent can log itself powerfully just like the server. 2. >But I looked over the last version of the integrated agent patch and I'd >say that it's ready for inclusion into CVS! ;) Where should the files be placed? A single app or as plugin? And how to name it is a sticky problem to me :( 3. >The change concerning the use of predicate lists would be nice however ;) ok, I'll work it out. Best wishes! Ben |
|
From: Markus R. <rol...@un...> - 2008-04-12 11:15:45
|
Hi Ben, Ben wrote: > 1. >The most simple solution would be a single logchannel for all > integrated > >agents. A more elaborate solution would provide a channel for each > >agent. Opinions? > A channel with different kinds of streams for each agent is perfect. > Then an agent can log itself powerfully just like the server. The question is how to extend the logserver to support that. Some issues are: Currently the Logserver supports different priority levels, i.e. normal, debug, warning, error. If we extend the logserver to provide additional channels we could add the agent channels as new priority levels (see zeitgeist/logserver/logserver.h the EPriorityLevel enum). In this case using a single new constant like 'eAgent' and offset that with the uniqe agent id would provide a channel id for each agent (i.e. eAgent + 1, eAgent + 2 ...) The downside is we cannot provide different loglevels (i.e. debug, normal etc. for one agent channel). One possibility would be to provide multiple bases like eAgentNormal, eAgentDebug etc. and offset them. This could be hidden behind a nice interface like "GetLog()->AgentDebug(agentId)" > 2. >But I looked over the last version of the integrated agent patch and > I'd > >say that it's ready for inclusion into CVS! ;) > Where should the files be placed? A single app or as plugin? > And how to name it is a sticky problem to me :( I'd say the names are fine. The soccebotbehavior could become part of the existing soccer plugin. This class derives from the base behavior class, so this must be part of one core library (you cannot inherit a class from a base that is part of another plugin). The base behavior class could go into the gamecontrol directory and the traincontrol class into the simulationserver directory. > 3. >The change concerning the use of predicate lists would be nice > however ;) > ok, I'll work it out. thanks. cheers, Markus |
|
From: Ben <lgp...@16...> - 2008-04-12 22:34:37
|
Hi Markus, 2008-04-12，"Markus Rollmann" <rol...@un...> > The change concerning the use of predicate lists would be nice > however ;) > ok, I'll work it out. After using predicate lists, the arms' wave action of soccerbotbehavior is abnormal, and I found that it's concerned about the precision. In SexpParser::ListToString: ss.precision(2). So in order to make the behavior through integration and network work the same exactly, there maybe need some changes. Finally, how to output the cvs commit into 'ChangeLog'? Thanks. Best wishes! Ben |
|
From: Markus R. <rol...@un...> - 2008-04-13 10:09:20
|
Hi, Ben wrote: > 2008-04-12£¬"Markus Rollmann" <rol...@un...> > > The change concerning the use of predicate lists would be nice > > however ;) > > ok, I'll work it out. > After using predicate lists, the arms' wave action of soccerbotbehavior > is abnormal, and I found that it's concerned about the precision. > In SexpParser::ListToString: ss.precision(2). So in order to make > the behavior through integration and network work the same exactly, > there maybe need some changes. We loose precision in the conversion from string to float? I think the sensor should have authority about the precision. So the rounding should occur within the Sensor classes. We already have the gRound() function in gmath.h for this purpose. > Finally, how to output the cvs commit into 'ChangeLog'? That is a feature of the Emacs editor. Load the version control hooks with m-x, vc-load-vc-hooks. Open the Changelog file. And use m-x, vc-update-change-log to transfer your changes. cheers, Markus |
|
From: Joschka B. <jbo...@un...> - 2008-04-14 04:01:43
|
Hi Ben, On Apr 13, 2008, at 7:34 AM, Ben wrote: > > Finally, how to output the cvs commit into 'ChangeLog'? > Thanks. Emacs has a nice front-end to work with cvs, called PCL-CVS. You can use it to first write your ChangeLog entries and then use them automatically when you commit your files from within PCL-CVS. It's quite convenient to use :-) Have a look at [1] to get started. Cheers, Joschka [1] http://www.gnu.org/software/emacs/manual/html_node/pcl-cvs/index.html |
|
From: Hedayat V. <hed...@ai...> - 2008-04-12 21:34:53
|
Hi All, /*Markus Rollmann <rol...@un...>*/ wrote on 04/12/2008 03:45:22 PM: > Hi Ben, > > Ben wrote: >> 1. >The most simple solution would be a single logchannel for all >> integrated >> >agents. A more elaborate solution would provide a channel for each >> >agent. Opinions? >> A channel with different kinds of streams for each agent is perfect. >> Then an agent can log itself powerfully just like the server. > > The question is how to extend the logserver to support that. Some > issues are: > > Currently the Logserver supports different priority levels, i.e. > normal, debug, warning, error. If we extend the logserver to provide > additional channels we could add the agent channels as new priority > levels (see zeitgeist/logserver/logserver.h the EPriorityLevel enum). > In this case using a single new constant like 'eAgent' and offset that > with the uniqe agent id would provide a channel id for each agent > (i.e. eAgent + 1, eAgent + 2 ...) > > The downside is we cannot provide different loglevels (i.e. debug, > normal etc. for one agent channel). One possibility would be to > provide multiple bases like eAgentNormal, eAgentDebug etc. and offset > them. This could be hidden behind a nice interface like > "GetLog()->AgentDebug(agentId)" Or maybe each agent should have it's own LogServer instance?! Also notice that priority levels should be powers of 2. So, (at least currently) we can have at most 32 priority levels. Cheers, Hedayat > > |
|
From: Ben <lgp...@16...> - 2008-04-12 22:28:01
|
Hi Hedayat: It's great! Why not come into my head? :) Best wishes! Ben 在2008-04-13，"Hedayat Vatankhah" <hed...@ai...> 写道： Hi All, Markus Rollmann <rol...@un...> wrote on 04/12/2008 03:45:22 PM: Hi Ben, Ben wrote: 1. >The most simple solution would be a single logchannel for all integrated >agents. A more elaborate solution would provide a channel for each >agent. Opinions? A channel with different kinds of streams for each agent is perfect. Then an agent can log itself powerfully just like the server. The question is how to extend the logserver to support that. Some issues are: Currently the Logserver supports different priority levels, i.e. normal, debug, warning, error. If we extend the logserver to provide additional channels we could add the agent channels as new priority levels (see zeitgeist/logserver/logserver.h the EPriorityLevel enum). In this case using a single new constant like 'eAgent' and offset that with the uniqe agent id would provide a channel id for each agent (i.e. eAgent + 1, eAgent + 2 ...) The downside is we cannot provide different loglevels (i.e. debug, normal etc. for one agent channel). One possibility would be to provide multiple bases like eAgentNormal, eAgentDebug etc. and offset them. This could be hidden behind a nice interface like "GetLog()->AgentDebug(agentId)" Or maybe each agent should have it's own LogServer instance?! Also notice that priority levels should be powers of 2. So, (at least currently) we can have at most 32 priority levels. Cheers, Hedayat |
|
From: Hedayat V. <hed...@ai...> - 2008-04-13 14:21:16
|
Hi Ben, /*Ben <lgp...@16...>*/ wrote on 04/13/2008 02:57:48 AM: > Hi Hedayat: > > It's great! > > Why not come into my head? :) Thanks! :-[ Good luck, Hedayat > > Best wishes! > Ben > > |
|
From: Markus R. <rol...@un...> - 2008-04-13 10:01:13
|
Hedayat Vatankhah wrote: [...] >> The downside is we cannot provide different loglevels (i.e. debug, >> normal etc. for one agent channel). One possibility would be to >> provide multiple bases like eAgentNormal, eAgentDebug etc. and offset >> them. This could be hidden behind a nice interface like >> "GetLog()->AgentDebug(agentId)" > Or maybe each agent should have it's own LogServer instance?! I like that idea... We could install a LogServer instance below each Behavior class. Further the Object::GetLog() function should become vritual (see zeitgeist\object.h). Called from within a behavior class it would return the LogServer instance assigned to the agent, (maybe a direct child) and return the default LogServer instance otherwise. > Also notice that priority levels should be powers of 2. So, (at least > currently) we can have at most 32 priority levels. Your're right. Id didn't notice that. I favor the idea of separate LogServcer instances (or a similar concept) cheers, Markus |
|
From: Hedayat V. <hed...@ai...> - 2008-04-13 14:21:32
|
Hi Markus, Glad to hear that! :) But (well, I wonder if I'm getting too sensitive about this :( ), it might be better to find a way to avoid the overhead of calling a virtual function?! (Sorry again, I think I'm going too far in this direction! Is it really a overhead which I should think about?) Thanks a lot, Hedayat /*Markus Rollmann <rol...@un...>*/ wrote on 04/13/2008 02:30:51 PM: > Hedayat Vatankhah wrote: > [...] >>> The downside is we cannot provide different loglevels (i.e. debug, >>> normal etc. for one agent channel). One possibility would be to >>> provide multiple bases like eAgentNormal, eAgentDebug etc. and >>> offset them. This could be hidden behind a nice interface like >>> "GetLog()->AgentDebug(agentId)" >> Or maybe each agent should have it's own LogServer instance?! > > I like that idea... We could install a LogServer instance below each > Behavior class. Further the Object::GetLog() function should become > vritual (see zeitgeist\object.h). Called from within a behavior class > it would return the LogServer instance assigned to the agent, (maybe a > direct child) and return the default LogServer instance otherwise. > >> Also notice that priority levels should be powers of 2. So, (at least >> currently) we can have at most 32 priority levels. > > Your're right. Id didn't notice that. I favor the idea of separate > LogServcer instances (or a similar concept) > > cheers, > Markus > |
|
From: Markus R. <rol...@un...> - 2008-04-13 17:53:17
|
Hi, Hedayat Vatankhah wrote: > But (well, I wonder if I'm getting too sensitive about this :( ), it > might be better to find a way to avoid the overhead of calling a virtual > function?! (Sorry again, I think I'm going too far in this direction! > Is it really a overhead which I should think about?) I think this is a quite light weight solution and has the benefit that the syntax stays the same, so you just write GetLog() and receive the correct LogServer instance. If we install multiple LogServer instances there has to be a way to get the correct one. Hiding this behind one standard function call allows use to keep this logic in one place and change our minds later what LogServer instance we use and where to install them. cheers, Markus |
|
From: Ben <lgp...@16...> - 2008-04-16 00:51:09
|
Hi Markus and all:
> I have a question: can we make the library zeitgeist, kerosin, oxygen
> as dll in windows?
>However on windows only symbols
>(i.e. function names and members) that are explicitly declared are
>exported (i.e. visible from outside the .dll). So declaring all required
>symbols as DLL-Export is quite a lot of work.
Yes, it's really a lot of work, however, I make one avaible here[1].
I use '#define SHARED_LIB_COMPILE' in 'windows/sparkconfig.h',
add 'CLASS_EXPORT' before all the classes needed, and It works.
There is only one technical issue:
when there is a static member in a class(to be export), for example,
in salt::Matrix (mIdentity), salt.dll is produced, but when zeitgeist links
to salt, there is a unresovled symbol of 'mIdentity'.
I have to add an additional file like this to define it:
#include <salt/matrix.h>
using namespace salt;
float Matrix::mIdentity[16]=
{
1.0, 0.0, 0.0, 0.0,
0.0, 1.0, 0.0, 0.0,
0.0, 0.0, 1.0, 0.0,
0.0, 0.0, 0.0, 1.0
};
Is there any other solution?
Best wishes!
Ben
[1] www.apollo3d.cn/download/winserver_dll.rar |
|
From: Markus R. <rol...@un...> - 2008-04-16 17:41:42
|
Ben wrote: [...] > I use '#define SHARED_LIB_COMPILE' in 'windows/sparkconfig.h', > add 'CLASS_EXPORT' before all the classes needed, and It works. > There is only one technical issue: > when there is a static member in a class(to be export), for example, > in salt::Matrix (mIdentity), salt.dll is produced, but when zeitgeist links > to salt, there is a unresovled symbol of 'mIdentity'. > I have to add an additional file like this to define it: [...] > Is there any other solution? It should be possible to compile salt/oxygen/kerosin and spark as one single dll. In this case we don't have the dependency issues between our libraries. SimSpark would then link to the 'bundle' dll that contains all our base libraries. cheers, Markus |
×
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