This is a situation calculus- and Golog-based system written in Mercury. See this paper or these slides for more information.
Contact: Christoph Schwering (schwering at kbsg.rwth-aachen.de).
The following shortly describes what's in the different directories.
Contains the raw prGolog interpreter.
The interpreter closely follows the formal semantics in many ways.
It implements the paper's transition semantics which allows for
incremental program execution with the following programming constructs:
sequence, "nondeterministic" branch, loop and pick, concurrency by
interleaving, atomic complex actions (they cannot be interleaved with
concurrent programs), constant primitive actions, situation-dependent
primitive actions (allows for functional fluents in actions) and
procedure calls.
Nondeterminism is resolved decision-theoretically by opting for the
alternative that leads to the highest rewarded situation.
Two other features are not implemented: continuous time and stochastic
actions. The former can be easily and much more flexibly implemented in
the basic action theory (BAT). The latter can be implemented in the BAT
by sampling.
Domains need to implement the bat typeclass to use the prGolog
interpreter.
Contains interfaces (typeclasses obs_bat, pr_bat, obs_source)
that need to be implemented by modules that either implement a basic
action theory (BAT) for plan recognition or provide access to
observations, respectively.
Furthermore there are two implementations of obs_bat and pr_bat for
the automotive domain: The first one uses a simple but unrealistic
global-coordinate model and a linear constraint solver. The second is
based on a relative spatio-temporal calculus and simple searches to
solve the constraints.
Finally two implementations of obs_source are available: The first one
reads observations from stdin. The second one listens for observations
sent by our TORCS instance.
Using the aforementioned typeclasses bat, obs_bat, pr_bat and
obs_source, the plan recognition system incrementally executes a
hypothesis program and merges incoming observations into the program
to provide an online way of plan recognition.
Provides facilities to solve linear systems of equations. The
underlying solver is Coin Osi Clp. It is either linked dynamically
or access via the lp-server (recommended).
Provides a simple stand-alone server for solving linear programs. Communication (the objective, constraints, and solutions) is done either via TCP or UNIX sockets. The solver back-end is COIN Osi Clp.
Listens to a TCP socket, enqueues incoming observations and runs plan recognition on these observations. For the global-coordinate BAT, there's a nice visualization using NCurses.
Reads observations stdin and feeds them to the plan recognition system.
The results are simply printed to stdout.
Primarily for simple testing purposes when cars-server doesn't work
for some reason.
Contains a bunch general helper predicates and functions.
A simple maze scenario in which an agent starts at some cell and searches for a goal destination. This has actually nothing to do with plan recognition but serves as a comparison of Mercury and ECLiPSe-CLP implementation.
First install the Mercury compiler and then compile:
$ make depend
$ make
Now you should have some libaries in lib:
$ ls lib/mercury/lib/hlc.par.gc/*.so
lib/mercury/lib/hlc.par.gc/libdomain.so
lib/mercury/lib/hlc.par.gc/libplanrecog.so
lib/mercury/lib/hlc.par.gc/libutil.so
lib/mercury/lib/hlc.par.gc/libosi.so
lib/mercury/lib/hlc.par.gc/libprgolog.so
lib/mercury/lib/hlc.par.gc/libvisual.so
And four binaries:
$ ls cars-main/cars cars-server/cars_server lp-server/lp_server
cars-main/cars
cars-server/cars_server
cars-server/replay
lp-server/lp_server
The cars binary can be fed with observations from stdin.
You can simply pipe the observations from a text-file.
The cars_server binary is a bit harder to use, but the script server.sh
helps alot.
It starts an lp_server in the background (which is only needed if you
use the global-coordinate-based BAT).
Then it starts a cars_server process which connects to the lp_server
and listens for incoming connections from observation sources.
We have extended a the racing game TORCS (via a so-called robot)
to function as driving simulator and observation source.
The game sends all observations to the plan recognition system.
As these observations are logged, they can be replayed using the binary
cars-server/replay which imitates a TORCS instance and sends the logged
observations to the plan recognition system.
I'm sorry the system is currently more or less unusable without TORCS; I hope to fix that soon or at least publish our TORCS robot and the appropriate configuration.
- more plans, experiments and great results
- another simulator