Production Systems and Quagents

Intelligent Agent Control

How does a robot decide what to do next?

Read Chapter 2 and relevant sections of Chapter 7 to see a simple simulated robot world. Read Sections 9.3 and 25.7. Read the reserve articles by Brooks and by Maes and Brooks.

Mabel the (prize-winning) mobile table used a finite state machine (if you're rusty, look it up -- should have seen in 172, 173, 280, MTH 150, etc. etc.). Or you could just write a program, presumably with tests, decisions, branches, etc. in it. For example, here is the Quake Monster AI Program that controls all Quake monsters in the game. They all do exactly this, only with different parameters.

Lots (lots!) is known about mobile robot software architectures (CB, Amazon, and the Library all have books on it). At this point we are limiting our interest to the mechanism of production systems to write robot controllers.

This project has three goals:

  1. Get acquainted with production systems.
  2. Use a "professional" AI software package.
  3. Write a production system to control a Quagent.
Briefly: Production systems are a set of rules and an interpreter. Rules have a left-hand-side (LHS) describing a ``situation'' (``feel-breeze'' and ``hold-canary'' and ``can't-move-forward'') and an action you may (or should) perform in this situation (``throw-canary''). This is a forward-chaining (q.v.) formalism. Production Systems can be quite general with interesting possilities (lots of LHSs match -- which fires?), or can be used to build highly structured control like the following one you know from reading your Brooks papers (paragraph 2).

Subsumption Architecture: Robot behavior is structured into a hierarchy of ``behaviors'', with more important ones taking precedence over less. So ``explore'' might be a default action unless overridden by ``hungry'' which prompts ``find-food'' and ``eat'', which themselves could be interrupted by ``see enemy'' which prompts the highest priority ``run away'' action, say.


We'll be using Jess, a rather nice production system language. It has lots of features that address many of the traditional problems with productions (it's a rete system, which you are familiar with since you did the reading in paragraph 2. It can be used interactively like LISP but it also can call upon Java functions or it can be used as a library in Java code. There is extensive documentation on-line at The Main Jess Site . So while you're reading about robot control, the Jess documentation is something else you should be familiar with. It's big so you probably don't want to (or need to) print it all out. Your stalwart TAs have it up and running.

The Jess code lives in the /u/cs242/ directory, and Corey has posted instructions on BB. There is also a getting started guide, Jess Introduction that we hope will help. It points to Getting Started With Jess . As always, please start EARLY, try things out, and let us know about infelicities, lies, or other problems in the documentation or system ASAP. Thanks!


This is a team assignment. Teams of two or three are OK. Make sure you have enough work for three people. You might want to try to have a balance of talent, including somebody who has worked with unix sockets, asynchronous communication, or systems issues generally.

Production System Control

Write and demonstrate one or more production system controllers (using Jess and probably Java) for one or more Quagents. The production systems will use the Quagent Protocol to establish facts in the database and to issue commands to the quagent. The Quagent Page has information on the protocols and other documentation, code samples, etc.

Now the nice thing about doing more than one controller is that you can compare them. You can start simple, add features, and quantify or otherwise scientifically investigate the differences in capabilities that result.

You can also experiment by changing the environment. The bots interact with items in different ways, and you can change the experiment by using the configuration files to change situations. For instance, by adding more obstacles (BOXes).

You don't have to use all the bot's facilities. The STOPPED message is like a bump sensor and it's interesting to write rules to continue moving in a straight line despite bumping into and maneuvering around obstacles using only such a sensor.

Or, you could deny your bot use of the somewhat-magical RADIUS command. Then it might be good strategy to accumulate wisdom to improve your vision (with RAYS) if you were interested in accumulating wealth, or it might pay to start going for gold immediately with low-resolution vision and not bothering to improve it.

You might want to start with a subsumption architecture. You should have at least four behaviours. You could model a static subsumption architecture with fixed priorities or you could have varying priorities: e.g. your hunger or sex drive could lead you to take chances with predators, etc.

Then you can think of adding reasonable-sounding rules that should govern a quagent's behavior (possibly in the presence of other quagents) and seeing how they (the rules AND the quagents) interact.

The controller can be responsible for some interesting quagent-quagent interactions. For instance it can simulate a version of trading or selling. The controller would know that bot1 has an excess of a commodity (like HEADs) and not a lot of GOLD. If there were another bot with more gold than heads, then controller could arrange for them to meet and exchange goods with some pickups and drops.

Quagents can thus communicate directly with each other (through their controllers) even there is no mechanism for the bots to talk to each other. So don't let the bots' physical makeup limit you: remember that the quagent controllers can effectively implement broadcast or point-to-point communication between bots. Quagent controllers can engage in complex activities like negotiation, bluffing, whatever. Bots are just dumb machines with a few physical limitations and characteristics. The quagent controller does the real and interesting work.

Obvious sorts of primitive behaviors that come to mind are the following.

Start simply and add things incrementally, or you'll never be able to debug your simulation or have any confidence that it is working correctly.

What to Hand In

Send CB a (strictly private and confidential) review of the performance of each of your teammates. Thats brown@cs.

Here are some project Computing Resource and Project Grading Guidelines we all will be following.

Provide a thorough and thoughtful write-up of your work, including the justification for your design decisions, observations about the behavior of your robots, implementation details, experimental results, discussion, and references.

Create a PDF document of your writeup and upload it to BB. As an appendix it should have the JESS rules that implement your controller(s).

For instance, it's quite possible to write controllers that get you stuck in a loop, stuck bashing an obstacle, or even get you consistently killed. If you can prove that your controller doesn't get you in these sorts of troubles that'd be wonderful but this is very hard. Behavioral observations are probably good enough.

You should definitely be as precise and thorough as you can about comparisions and contrasts between your controllers. Quantification is nice: e.g. if your quagent's goal is to amass wealth, then use that as a success measure for different controllers. Data, charts, and graphs are nice if you can work them in.

Write in good scientific style in the form of a computer science technical report. You may find useful this set of advice on writing and homework. There are some example writeups of student projects on the Main Assignment Page .

242 Home Page

This page is maintained by Nature Lover

Last update: 1.9.04.