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:
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.
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!
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.
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
Last update: 1.9.04.