[Sserver-three-d] SPADES and Current New Simulator Integration

[Patrick R. <Pat...@cs...>]

All,

Here is a list of some issues to resolve and information about the
integration of SPADES and the current framework from Oliver. First, I
don't think that any of these will be too hard to deal with, but we just
need to do a little bit of planning. I hope this starts a discussion, so
please comment if you have suggestions, see errors, I was unclear, I
forgot something, or any other reason you feel like.

* Main event loop

SPADES wants to control the main event loop. In general, SPADES should
probably deal with all networking functionality, so it makes sense
that it maintain the event loop. If you know of any problem with this,
let's talk about it.

>From the WorldModel perspective, the simulation progresses by
simulating forward, realizing some event, then simulating forward
again. Event can mean many things, but it at least includes the
creation of sensations and reception of actions of the agents.

* WorldModel advancement

Oliver mentioned that his framework is based upon the update of a
scene graph. I think this is entirely compatible with SPADES. SPADES
does not care how the world model advances. The WorldModel::simToTime
method requests advancement and that's it as far as SPADES is
concerned. 

In general the world model advancement time step should be smaller
than the sensation time of the agents.

* Agent interactions -- senses and acts

As mentioned, SPADES considers all sensations and actions to be sent
to the agents as Events. There are two ways that I can see sensations
being created.

First, for sensors that send regular periodic updates (this I use
right now). When the sensor is added to the scene graph, a
CreateSenseEvent is enqueued. When it is realizes, a SenseEvent is
created (based upon the current state of the scene graph) and a new
CreateSenseEvent is enqueued. Question: does this match up with how
you generate sensations currently?

Second, for sensors that trigger only on events (like a bump sensor
for example), during the WorldModel advancement, a CreateSenseEvent
can be enqueued. In general, the WorldModel can enqueue arbitrary
types of events and perform other simulation controlling operations
during this advancement.

* Agent startup, esp. with agent types

Agents are created in the simulation by having the
SimEngine::startAgent method called by the WorldModel. How the
WorldModel decided how many and what agents to start is entirely up to
the WorldModel. I don't know how this decision is made for the current
simulator, but I hope that it is compatible with the this. If not,
let's figure out what to do.

When SPADES is told to start an agent, how does it know what to do? It
relies on an idea of agent types. What an agent type basically means
is a description of what program to execute in order to start this
agent, as well as a bunch of parameters about timing and I/O
descriptors etc. Currently, the agent types are listed in a file and
read in, but if you want a more dynamic definition of agent type,
there's no reason the WorldModel couldn't add new AgentTypes
dynamically.

Example: Team CMDragons want to play against UvATrilearn. Both teams
submit agent types describing how to execute their program. Each could
submit a goalie type and a player type for example. The WorldModel
then calls SimEngine::startAgent for CMDragons_goalie,
CMDragons_player (10 times), UvATrilearn_goalie, and
UvATriliearn_player (10 times).

Very soon, you will be able to specify agent types that in the same
process via a dynamically loaded library. 

* Parameter parsing

Currently SPADES wants the WorldModel to do all parameter parsing and
return to it an object of type EngineParam. You do NOT have to use all
of SPADES parsing stuff. Probably the easiest thing to do is to keep
your own parsing, but somehow specify a conf file for SPADES. Create
an object of type EngineParam and call method EngineParam::readFile
(which comes from a parent class FileReader).

Question: do you want some way to specify SPADES parameters on a
command line? EngineParam has setParam methods that could be used. We
should talk about this.

* Monitor interface

SPADES supports a monitor interface. A Monitor means a program that
connects over a network socket and receives messages from the
simulation. It can also send commands like pause, play, etc, as well
as arbitrary messages to be interpreted by the WorldModel. There are
simulation events (MonitorSendEvent) which deal with creating these
messages. The idea is that monitors receive periodic updates about the
state of the world.

* Logging 

SPADES supports a simple interface for recording all information that
would be sent to a monitor. Also, SPADES can record, as a text file,
all the simulation events. I expect this will not be a complete
enough log of the game. I would like to have some scheme where the
events can be written to a log in a format that is extensible and easy
to read in again, but I have not done this yet.

* Referee: agent?

Open Question: should the referee be an agent in the SPADES sense?
It's sensations and actions can be arbitrarily powerful, but it should
have some sensation and action delay in the same sense as the agents
(this will allow better distributed speedups).
-- 
Patrick Riley
Fifth Year Ph.D. Student                                 
Computer Science Department, Carnegie Mellon University     
http://www.cs.cmu.edu/~pfr