AgeS - An Environment for Experiments with Autonomous Agents
Synopsis:
AgeS is an agent simulation environment,
which allows for the definition and implementation of control systems
for autonomous simulated and robotic agents. Furthermore, it permits
users to run their control systems on robots or on simulated agents in
simulation environments without the need to modify the control code,
thus facilitating experiments with agent architectures. AgeS
consists of four major components: (1) an agent client, (2) an agent
server, (3) an environment server, and (4) a registry (the user is
typically only concerned with the first). Multiple clients can
connect to the same server, which in turn might either control a
simulated or a real (i.e., robotic) agent. AgeS is written
in JAVA and thus runs on several OS platforms.
A Brief Introduction
AgeS allows users to define control systems for simulated and
robotic agents. These agents can be either predefined (e.g., as in
the case of a particular robot), or user-defined (e.g., as in the case
of a particular simulated agent). Agents in AgeS are defined
in terms of their sensors, their effectors, and their
brain. For each predefined agent type, only the given sensors
and effectors should be used (e.g., the sensors and effectors of a
Pioneer P2X), although it is possible for users to add more sensors
and effectors to such an agent. For robotic agents, the predefined
sensors and effectors can be connected to an actual robot's sensors
and effectors. Agents are programmed by extending the basic "brain"
class, which in turn requires the selection of a particular agent.
Each brain has automatically access to the agent's sensors and
effectors through special instance variables. By reading these
variables regularly, brains can determine what action needs to be
performed at any given time and send commands to their effectors.
AgeS will make sure that sensor information in brain is
updated and effector commands are forwarded appropriately. In
particular, depending on whether the agent will run in simulation or
robot mode, AgeS will get sensory information from the
simulation environment or the robot's sensors, and send effector
commands to the simulation or the robot's effectors. This setup makes
it possible to use the same brain class to control both a simulated
and a robotic agent.
As mentioned above, the main division in the AgeS system follows
the client/server paradigm. A client consists of all the code that is normally
written to control a robot's actions. A server consists of code that interprets
the commands from the client and interfaces with actual or simulated hardware.
The mechanism for connecting the two is called the registry, which makes
use of Java remote method invocation (RMI) calls. A more detailed look at the
components of the registry, a client, and a server follow.
An AgeS Server
An AgeS Server is the interface that handles commands from a client
and translates them into a form that can be used either by an actual robot or
a simulator. Each particular type of robot must have a server written for it.
Because the hardware capabilities must be specified, it also contains the specification
for all the sensors and effectors available to a certain class of robot. A standardized
abstract class is available for various sensors and effectors, allowing a consistent
set of commands across different platforms.
An AgeS Client
An AgeS client (also called an agent) is composed of at
least two components: a set of sensors/effectors and a brain. The sensors
and effectors are already specified in the server, which means that only the
method calls (not their inner workings) are relevant to the client. The brain
consists of any and all functionality the user wishes to give the robot.
The AgeS registry
The AgeS registry handles the initial communication between clients
and servers. It is essentially a database that maintains a list of active
servers, possibly of a variety of types. A client contacts the registry
directly, supplying any information necessary to allow a connection (such
as the type of server, in addition to a user name and password). Once
approved, the server creates an agent object for that type of server and
returns it to the client. As mentioned above, the agent object contains
initialized sensors and effectors, which allow the client and server to
communicate directly with one another. Once the client disconnects, the
server goes back into the available pool and waits for another connection.
An AgeS Connection Example
The following is a basic example of the connection process using the AgeS
Registry.
 |
The AgeS Registry is started on some host and is waiting for both a
server to register and a client to request a connection.
|
 |
An AgeS server is started and contacts the AgeS registry with its
IP address and server type. The registry adds the server to its
available list.
|
 |
An AgeS client is started and contacts the AgeS registry, which
checks its available list for an eligible server. If one is found,
the registry requests a connection to that server on behalf of
the client.
|
 |
The AgeS server creates and returns the requested type of agent
to the registry, which then relays the agent object to the client.
|
 |
The client now has a direct connection to the server, allowing both
sensory data and effector commands to be transferred. The server
periodically contacts the registry to maintain its active status. More
servers can register as necessary, at which point additional clients
can use them.
|
In sum, AgeS provides a comprehensive environment for
research in autonomous robotics, both in simulation and using actual
robots. Some notable points:
- The entire system is written in Java, hence agent architectures
developed under AgeS run on all JAVA-supported platforms; furthermore,
the user has full access to Java API functionality, including graphics
support.
- Multiple types of robots are usable in a given environment.
- Distributed code that allows computationally expensive procedures
to be performed on their own host.
- Client (agent) code that will work both in simulation and on an
actual robot.
- Server code that need be written only once.
The main conceptual idea underlying the system is to provide a clearly
delineated division between agent control code (the client) and the
software that interacts with simulator software or the hardware of a
robot (the server).
This page is maintained by:
Matthias Scheutz
Copyright © Matthias Scheutz, 2003
University of Notre Dame
All rights reserved.
Last revised on January 29, 2003