simspark-devel

Re: [simspark-devel] Integrated_agent_draft

[Ben <lgp...@16...>]

Hi, Markus:

>The problems I see are hardcoded dependencies to the soccer simulation: 
>For example the TrainControl sets up a 'robot part map' and provides 
>functions to drop the ball etc. The behavior class implements functions 
>[...]
 Yes, we should consider the development in the aspect of pure 'train'.

And I think there are some other problems:
  1.  one instance of TrainControl is correspond to one agent?
    Should we make TrainControl to manage all the agents just like AgentControl,
   or in order to get some speed improvements in multi-threads mode, we do  
   one-to-one .

 2. some actions and decision can be written in Ruby script, they are executed every cycle, there exists problem for ruby script is only considered for initialization.
    For example, in 'Sparkmonitor::UpdateCached', 'ClearNodeCache' is called when after running scripts whick result in the failure of logger.

Best wishes!
Ben

Re: [simspark-devel] Integrated_agent_draft

[Hedayat V. <hed...@ai...>]

Hi,
I should admit that I have not looked to your code thoroughly enough (so 
please excuse me if I'm wrong!). But some comments for now:
1. I think it is better for the agent's to be initialized with the init 
command themselves, like what the current agents do (so they will be 
initialized with the init effector).

2. It might be better to remove functions like DropBall and 
MoveAndRotateAgent from TrainControl. A separate method for integrating 
agents with TrainerCommandParser might be better.

3. I should think a little more about it! But it might be better to 
control all of the agents using TrainControl. For multi-threaded 
running, we could apply the same strategy to AgentControl and 
TrainControl classes. It might be even better to use completely separate 
classes for multi-threaded running. Well, sorry! I should think before 
talking!! :)

Thanks a lot, and welcome to MC (also to Feng Xue!) :)
Hedayat

/*Ben <lgp...@16...>*/ wrote on 03/28/2008 07:28:21 AM:
> Hi, Markus:
>
> >The problems I see are hardcoded dependencies to the soccer simulation:
> >For example the TrainControl sets up a 'robot part map' and provides
> >functions to drop the ball etc. The behavior class implements functions
> >[...]
> Yes, we should consider the development in the aspect of pure 'train'.
>
> And I think there are some other problems:
> 1. one instance of TrainControl is correspond to one agent?
> Should we make TrainControl to manage all the agents just like 
> AgentControl,
> or in order to get some speed improvements in multi-threads mode, we do
> one-to-one .
>
> 2. some actions and decision can be written in Ruby script, they are 
> executed every cycle, there exists problem for ruby script is only 
> considered for initialization.
> For example, in 'Sparkmonitor::UpdateCached', 'ClearNodeCache' is 
> called when after running scripts whick result in the failure of logger.
>
> Best wishes!
> Ben
>

Re: [simspark-devel] Integrated_agent_draft

[Ben <lgp...@16...>]

Hi Hedayat:

>1. I think it is better for the agent's to be initialized with the init
>command themselves[...].
>2. It might be better to remove functions like DropBall and
>MoveAndRotateAgent from TrainControl[...]
  Yes, it's right, I'll work on it.

>3. I should think a little more about it! But it might be better to
>control all of the agents using TrainControl. For multi-threaded
>running, [...]
  When the thinking of agents' behaviors are runnig in other machines
(AgentControl itself do not do the thinking), we can consider the agents
of AgentControl as 'multi-threads', is that right?

Thanks!

Best wishes!
Ben

Re: [simspark-devel] Integrated_agent_draft

[Hedayat V. <hed...@ai...>]

Hi Ben,

/*Ben <lgp...@16...>*/ wrote on 03/28/2008 08:02:47 PM:
> Hi Hedayat:
>
> ...
> >3. I should think a little more about it! But it might be better to
> >control all of the agents using TrainControl. For multi-threaded
> >running, [..]
> When the thinking of agents' behaviors are runnig in other machines
> (AgentControl itself do not do the thinking), we can consider the agents
> of AgentControl as 'multi-threads', is that right?
Yes, thinking is parallel. But generating agents' percepts and parsing 
their commands are not (and maybe network communication to some extent). 
It might be better to have them running in parallel too. What do you think?

Cheers,
Hedayat

>
> Thanks!
>
> Best wishes!
> Ben
>
>
> ------------------------------------------------------------------------
> �� �� �� ǿ �� �� --- �� �� �� �� �� �� ��166 �� �� �� ͬ ʱ �� �� 
> <http://event.mail.163.com/chanel/click.htm?from=NO_26&domain=163> 

Re: [simspark-devel] Integrated_agent_draft

[Ben <lgp...@16...>]

Hi, all:    

2008-03-29，"Hedayat Vatankhah" <hed...@ai...>:
>Yes, thinking is parallel. But generating agents' percepts and parsing
>their commands are not (and maybe network communication to some
>extent). It might be better to have them running in parallel too. What
>do you think?
  I think so.

I get some issue to be discussed, please have a look of the updated source here[1].

  1. Where should 'Behavior' be installed in the object hierarchy?
     TrainControl should be able to enum all the behaviors.
  2. Dynamic connect and disconnect?
     Should the integrated agent be like the one in AgentControl, in which
     agents' connection is dynamic.
  3. Write an interface class to provide internal information, such as transformation,
      joints.
     The information can be used by scenario training or some learning algorithms.

Best wishes!
Ben

[1] http://www.apollo3d.cn/download/integrated_agent_v2.tar.gz

Re: [simspark-devel] Integrated_agent_draft

[Markus R. <rol...@un...>]

Hi all,

Ben wrote:
> 1. Where should 'Behavior' be installed in the object hierarchy? 
> TrainControl should be able to enum all the behaviors.

It should go below 'user/agent/' I think.

> 2. Dynamic connect and disconnect? Should the integrated agent be
> like the one in AgentControl, in which agents' connection is dynamic.
> 

What does it mean for an integrated agent to be dynamic?

Behavior nodes could register to the TrainControl (in their OnLink()).
The traincontrol then uses the GameControl Server to create an
AgentAspect (mGameControlServer->AgentConnect). As Hedayat already wrote
the agent then use their init effector to construct themselves.

When the behavior node is uninstalled it's OnUnlink unregisters from the
TrainControl. The TrainControl then disconnects the agent
(mGameControlServer->AgentConnect).

In this way behavior nodes could be installed an uninstalled at any time.

> 3. Write an interface class to provide internal information, such as
>  transformation, joints. The information can be used by scenario
> training or some learning algorithms.

This internal information is specific to the soccer simulation. We 
should implement it but put it in a derived class, something like 
SoccerBehavior that is a specialized behavior. The base behavior soukd 
only contain the mechanism to register with the TrainControl and some 
Send/Receive message api.

As Hedayat already noted the setup of training situation should be done 
using the TrainerCommandParser interface that is already there.

cheers,
Markus