 |
An agent is propelled to act only after receiving some form of input,
that is, after the activity manager receives a new object of the Input
class. This class has three sub-classes: SensorInput,
Message, and Event.
A SensorInput is a set
of inputs that come directly from the agent's sensors. Biter provides
a parsing function that transforms the input from its original format
- a list - into an object of this class. In most implementations a class
hierarchy should be created under this class in order to differentiate
between the various types of sensor inputs. Biter defines ObjectInfo
and ObjectInfoContainer
as extensions of this class. The Message
class represents a message from another agent. Robocup players can use
a broadcast mechanism ("say") to send messages to all nearby
players. Finally, the Event
class is a special form of input that represents an event the agent itself
created. Events function as alarms set to go off at a certain time. They
are important because they provide a way to implement timeouts. Timeouts
are used when waiting for a reply to a message, when waiting for some
input to arrive, or when repeatedly taking an action in the hope of generating
some effect.
Biter implements a
special instance of Event,
which we call the act event. This event fires when the time window for
sending an action to the soccer server opens. That is, it tries to fire
every 100ms, in accordance with the soccerserver's main loop. Since the
messages between Biter and the soccerserver can be delayed, and their
clocks can get skewed over time, the actual firing time of the act event
needs to be constantly monitored. Biter uses an algorithm similar to the
one used in [12] for keeping these events synchronized with the soccerserver.
The Activity
class represents our basic building block. Biter agents are defined by
creating a number of activities and letting the activity manager schedule
them as needed. The Activity
class has three main member functions: canHandle,
handle, and inhibits.
The canHandle
member function receives an input object as an argument and returns true
if the activity can handle the input, that is, if it can execute as a
consequence of receiving that input. This function could not only consider
the contents of the input, but it could also consider the agent's
current internal state, the agent's world model, etc. Since this
is a generic framework, we do not constrain the canHandle
function to only access a certain subset of the available data. That decision
is left to the software engineer who wants to refine the architecture.
The only requirement we make is for the function to be speedy since it
will need to be called after each new input has arrived.
The handle
member function is called when the activity is chosen to handle that input.
It is called when the activity manager wants the activity to execute with
the given input. This function usually generates one or more atomic actions,
sets some member variables, and returns. A call to the handle function
executes the next step in the activity, the step that corresponds to the
received input. The function can set member variables as a way to maintain
a state between successive invocations. This state allows the activity
to implement multistep plans and other complex long-term behaviors. The
handle function will return true when the activity is done, at which point
it will be deleted. We expect that in most agents there will be a set
of persistent activities that are never done and always return false.
Finally, the inhibits
member function receives an Activity
object as a parameter and returns true if that activity is inhibited by
the current one. This function implements the control knowledge which
the activity manager will use to determine which activity to execute.
The use of this function mirrors the use of subsuming behaviors in the
subsumption architecture [4]. However, the function can also consult state
variables in order to calculate its value, thereby extending the functionality.
Since the activities are organized in a hierarchy, this function is able
to easily inhibit whole subtrees of that hierarchy. This allows users
to add new activities without having to modify all existing ones.
A significant advantage
of representing each activity by its own class, and with the required
member functions, is that we enforce a clear separation between the behavior
knowledge and the control knowledge. That is, the handle function implements
the knowledge about how to accomplish certain tasks or goals. The canHandle
function tells us under which conditions this activity represents a suitable
solution. Meanwhile the inhibits
function incorporates some control knowledge that tells us when this activity
should be executed. This separation is a necessary requirement of a modular
and easily expandable agent architecture.
The Behavior
class is an abstract class that groups all long-term behaviors of the
agent. We define these behaviors as series of atomic actions. For example,
a robotic behavior might be to "avoid obstacles," while a software
agent might have a "gather data from sources" behavior. Behaviors
can, like all activities, create new activities and add them to the set
of activities.
Biter defines its
own behavior hierarchy by extending the Behavior
class, starting with the abstract class RobocupBehavior
which implements many useful functions. The hierarchy continues with standard
behaviors such as DashToBall,
IncorporateObservation,
and DribbleToGoal. For
example, a basic Biter agent can be created by simply adding these three
behaviors to a player's activity manager. The resulting player would
always run to the ball and then dribble it towards the goal.
The Conversation
class is an abstract class that serves as the base class for all the agent's
conversations. In general, we define a conversation as a set of messages
sent between one agent and other agents for the purpose of achieving some
goal, e.g, the purchase of an item, the delegation of a task, etc. A GAA
implementation defines its own set of conversations as classes that inherit
from the general Conversation
class. For example, if an agent wanted to use the contract-net protocol,
it would implement a contract-net class that inherits from Conversation.
Conversations implement protocols.
Most protocols can be represented with a finite state machine where the
states represent the current status of the conversation and the edges
represent the messages sent between agents (see [9] for specific proposal
that extends UML to cover agent conversations). In some protocols each
agent will play one of the available "roles." For example,
in the contract-net protocol agents can play the role of contractor or
contractee. The conversations will, therefore, implement a finite state
machine.
Multiple conversations
can be handled by having the existing conversation add a new one to the
set of activities. For example, if a message that starts a new conversation
(e.g., a request-for-bids) is received by an agent the canHandle
function of the appropriate conversation will return true
even if the conversation is already busy, that is, even if it is not in
its starting state. When the handle
function is called with the new message the conversation will recognize
that it is busy and create a new conversation, add it to the action manager,
call the new conversation's handle method with the new input, and return.
In this way, a new conversation object is created to handle the new message.
Behaviors can use the same method to initialize a conversation.
For example, a "move
to point" behavior might realize that another agent is blocking
the path and start a conversation with that agent in an effort to convince
it to move out of the way. If only one instance of a conversation is desired
the user can implement a conversation factory [5, Factory Method] in order
to dynamically limit the number and type of conversations.
We are also planning
to add error handling and verification functions to the top-level Conversation.
Specifically, many conversations will want to implement some timeout mechanism
for expected replies, as well as a method for determining what the next
action should be (e.g., resend the message, send another message, fail).
Given the commonality of this functionality, it makes sense for us to
implement it on the base class.
The ActivityManager
picks one of the activities to execute for each input the agent receives.
It implements the agent's control loop. The manager runs in its own thread,
where it receives input from the sensors and dispatches it to the appropriate
activity. The dispatching is done by the handle function, shown in Figure
3, which determines which of the activities will actually handle the input.
The algorithm it implements echoes the type of control mechanism implemented
by subsumption and Belief, Desire, Intention [6] architectures. The function
first finds all activities that can handle the input; from this group
it chooses one which is not inhibited by any other one in the group and
asks it to handle the input. Since the inhibition function can be arbitrarily
defined by its activity, the ordering becomes very flexible. That is,
the user of the GAA has options ranging from no organization (no activity
inhibits any other activity), to a static organization (activities inhibit
a fixed type of activities), to a dynamic organization (activities inhibit
based on many other factors). As an agent matures, the user can choose
to increase the organizational complexity without re-implementing the
architecture.
|
|
