atc --- which is the ATC server.
display --- which is a client to display the current
state of the ATC simulation.
keyagent --- which is a client to take keystroke
commands from the terminal and send them to the ATC server.
track --- which is a client that tracks the state of
the simulation (by reading fromthe ATC server) and also accepts
action commands from an automated agent and either responds to them
directly (for perceptual commands) or forwards them to the ATC
server (for action commands).
random-agent --- our first ATC agent. It chooses
commands randomly.
keytest --- an agent that is very similar to
keyagent, except that it interacts with the state tracker using the
agent protocol rather than interacting with the atc program via the
serial line protocol.
united --- a program that combines the functions of
atc and track (see below).
The three components atc, display, and
keyagent provide a UNIX replacement for the PC program
ATC.EXE. Together, they accept key-strokes from the user,
run the simulation, and display the results. Both the
ATC.EXE program and the atc program
implement the ascii serial line protocol for communicating between a
source of keystrokes and the simulation. For every significant event,
this protocol sends a message from the simulator back to the key
source telling it what has happened (e.g., a plane has successfully
landed, a plane has been moved, etc.).
To handle automated agents, we have introduced a program called the
State Tracker (track). The state tracker is a 2-way
filter. It provides an agent program with a set of actions including
perceptual actions and keystroke actions. It imposes realistic time
constraints on these actions (for example, each keystroke requires 80
milliseconds to complete). When it receives an action request from
the agent, it enqueues it and sets a timer alarm for the required
time. When the timer expires, it sends the keystroke onward to the
ATC server. If the action request is a perceptual request, then when
the timer expires, it sends a message back to the agent giving the
results of the perceptual request.
To compute those results, the State Tracker must maintain a model of the current state of the simulation. It uses three sources of information to maintain this model. First, the ascii protocol from the ATC server tells it about significant events. Second, the keystrokes that it sends to the ATC server allow it to determine the current location of the cursor and whether particular holding pattern positions (or the flight queue) are selected. Third, it uses its internal clock to determine---once a plane starts to land---where the plane is located on the runway. All of this information can be made available to the Agent in response to perceptual action requests.
We may also want to consider permitting perceptual interrupts. For example, when the weather changes, the State Tracker could send an unsolicited message to the agent to alert it. Some agent architectures could take advantage of this.
I have implemented one very simple automated agent:
random-agent. This program operates in the following
loop:
atc -d -t -r
The -d option tells the ATC server to wait for a
connection from the display client. The -t option tells
the ATC server to do a 10-minute timed trial and then quit and
announce the total score achieved. The -r
option tells the ATC server to run in real time rather than
simulated time.
You should then start up the other two clients on your own machine. They should be started using
display hostname
keyagent hostname
where hostname is the name of the host where the
ATC server is running (all three programs can probably share the same
host without much problem).
host1) and start
up the ATC server using the command
atc -d -t
The -d option tells the ATC server to wait for a
connection from the display client. The -t option tells
the ATC server to do a 10-minute timed trial and then quit and
announce the total score achieved. Note that we do not use the
-r option, since we want to run in simulated time.
You should then start up the following three programs on a second
machine (call it host2). They should be started
using
display host1
track host1
random-agent host2
At the end of the 10-minute period, atc reports the final
score, and the state tracker and random agent go into infinite loops,
so you'll need to kill them. (I'm trying to fix this.)
enums.h:
track.c
ATCAction::FullState for exact details.
In the simulated time setting, the clock advances should be completely deterministic with no race conditions.
To do this in real-time, do the following. On
host1, up the ATC server using the command
atc -d -t -r
You should then start up the following three programs on a second
machine (call it host2). They should be started
using
display host1
track -r host1
keytest host2
Note that we used the -r option on both the
atc and track commands. To run in simulated
time, you can omit this option from both programs.
Chandra Reddy has implemented a decomposition rule (DRULE) planner in
Common Lisp for this ATC domain. You can run it as follows. On
host1, start up the ATC server using the command
./atc -d -t
You should then start up the following three programs on a second
machine (call it host2). They should be started
using
./display host1 &
./track host1 &
lucid-full
You must be in the directory ~tgd/eg/atc/code. Now issue
the following commands to lucid:
(load "startup-atc")
(tracker "host2")
(run-atc)
united program
We have been experiencing continuing problems with using the
combination of the tracker and the atc simulator with automated
agents. The problems appear to be caused by delays in the
interprocess communication. To eliminate this, I've created a new
program called united that combines the functions of
atc and track. Use it as follows:
On Unix host host1 start up the following programs:
./united -d -t
./display host1
Then you can start the appropriate agent program (either
keytest, random-agent, or a lisp agent)
indicating to it that the tracker is running on host
host1.