Hamid Mohammadi wrote:
> What is "plugin" based system??
I'm afraid it was me who coined the term "plugin-based system" for this
kind of path-planning component - so I'd better clarify:
First the context from Cameron's list of proposals:
> 8) Extension of AK_MOVE
> It was proposed that the AK_MOVE command be modified to allow for agents
> to change their movement orders during the timestep. This is to alleviate
> the current problem where an agent simply stops for the rest of the
> timestep when it hits a blocked road, whereas in real life it should
> immediately turn around and try a different path. A potential solution is
> for agents to send a function that returns the path they wish to travel
> instead of simply sending one path, or to use a "plugin" based system.
A path planner plugin would be a piece of source code that each team
provides for the competition which is "plugged" into the traffic
simulator (TS), i.e. it implements a specific interface that the TS can
use to provide the plugin with "perceptions" during the 60 secs of one
minute (cycle) and ask for the "next move" in each second. So instead of
executing a piece of a given path in each second, the plugin would
execute a *reactive* plan that takes new information into account. When
the TS is started for a given team's run some parameter would have to be
passed to it ensuring which plugin to use for path planning in this run.
The plugin is part of each agent (just run on a different machine,
namely where the TS is running) so its code would have to be fixed like
the code of the agents. Since the TS is written in Java the easiest way
to achieve this would be a Java class, but since Java is very open to
that kind of stuff using code written in other languages should not be
very problematic.
In each cycle, instead of sending a path to the kernel (which is
transmitted to the TS) an agent (not the plugin) would send some string
that is passed to the TS and on to the plugin which allows the plugin to
compute the appropriate moves for any given situation. This could be an
ordered list of preferred destinations, roads or some more complex
information like "follow police #1234 wherever it goes". Of course we
could force this string to have a specific format, but I would rather
not: after all, now we allow agents to choose their paths as they want,
too. Of course, there should be a length restriction (255 bytes or less).
There are several problems with this approach (but which I think can be
overcome):
- a large amount of computation is outsourced to the plugin/the TS.
There should be away to restrict computation time in each virtual second
to a very brief time. Otherwise the TS will not be able to handle the
decision.
- world model equivalence between plugin and agent: since the plugin is
actually an "outsourced" part of each agent it must be ensured that
their world models are equivalent. Therefore the plugin must not only
get all the perceptions the corresponding agent receives, but also get
the same messages (in case they provide some update to the world model).
Vice-versa, the perceptions from "on the way" must somehow be sent to
the agent, too.
Even more complicated, these perceptions are actually time series, i.e.
they have a time stamp and include things like "in sec 17 police44 is
seen on road88, in sec 18 police44 is seen on road89". This is
information that might be very interesting (plan recognition of other
agents...) but it is *huge* amount of information. Do we want this, can
we deal with this in terms of network traffic etc.
There are variants (especially restrictions) of this proposal that might
be more feasible. What do you think out there?
michael
-- Michael Brenner Phone: (+49) (761) 203-8226 Institute of Computer Science Fax: (+49) (761) 203-8222 Albert-Ludwigs-University mailto:brenner@informatik.uni-freiburg.de Am Flughafen 17, Geb. 52 http://www.informatik.uni-freiburg.de/~brenner D-79110 Freiburg, Germany
This archive was generated by hypermail 2.1.3 : Wed 10 Nov 2004 - 14:23:21 GMT