Apr 6/14: In this variant of the directory "gridworld-code-multiple-agents", there is code for running many random examples of Brenner & Nebel's multi-agent world, and computing average timing results. Again, the main difference from single-agent worlds is that we have an indexed array of agents, and various other agent-dependent parameters have been changed into arrays. Definition of the roadmap (in the sample world, a square grid), agent array, and related parameters is done in "multirun.lisp" rather than in "gridworld-world.lisp" (which now just contains the operator definitions). Likewise loading of various files is done in "multirun.lisp" (following various function definitions) rather than an "init.lisp" file. If you are planning to do runs for different variants of a multi-agent world separately (by manual initiation), refer to "gridworld-code-multiple-agents/"; i.e., instead of "multirun.lisp" you'll have an "init.lisp" file, and use something like 'run-multiple-agents'. The roadmap and agent and parameter definitions would then again be in "gridworld-world.lisp". Detailed differences from the single mobile agent environment are again listed below. As in the "gridworld-code-multiple-agents" directory, the sample worlds here are based on Brenner & Nebel (2009), "Continual planning and acting in dynamic multiagent environments", Journal of Autonomous Agents and Multiagent Systems 19 (3), pp. 297-331. (See http://www.informatik.uni-freiburg.de/~ki/people/brenner/publications.html) Again see the example on p.9 of the paper, for a 6 x 6 grid of squares, with 4 agents, and various random squares occupied by obstacles. The agents start at randomized initial positions and need to reach certain randomized goal locations. In their attempts to reach their goals, they can use look-ahead, but while they know the grid structure, they can't see the obstacles -- or other agents -- till they are adjacent to them (so for planning more than one step ahead, they assume that unseen squares are unoccupied). Running 'runRandomized' will display the outputs, time them and output the averages to files whose name starts with "OUT" and includes the input parameters (no. of agents, size of grid, etc.). The scripts ma.sh~, ma4.sh~, ma5.sh~, ..., ma10.sh~ specify randomized sets of example runs. (Actually, to run them you'd need to remove the final "~" on each of the files; I added these as the browser refuses to display script files -- it wants to run them.) For example, one of the runs in ma10.sh~, (runrandomized 7 10 15 1600 800) , specifies that 7 agents are to be run on a 10 x 10 grid, with 15 randomly positioned obstacles (occupied squares), with each agent allowed at most 1600 steps or 800 seconds (whichever comes first) to find its goal (otherwise it fails). Inside 'runrandomized' function there is a local variable howManyToRepeat, which has been set at 50, meaning to randomly generate and run 50 configurations of the problem size specified by the input parameters. Of course, you can change this to 1, if you want to run just 1 such configuration. [If you're looking for the definition of 'runrandomized', it's written as 'runRandomized' in file "multirun.lisp". But new multiagent worlds will require different files and functions anyway.] The OUT.txt file shows all output results for the Brenner & Nebel multiagent worlds concatenated. If you want to run other examples of the Brenner & Nebel worlds, then if you make any changes to *.lisp files, use (load "compile-all"). To run it all, use (load "multirun.lisp") -- which in turn loads all other compiled and uncompiled lisp files --, and then use (runrandomized ....), either directly or from a script. ================================================================== Operation: ; If changes have been made: rm *fasl acl (load "multirun.lisp") ; If changes have been made: (load "compile-all") :ex ;(exit from lisp) ./ma.sh (or run another one of the scripts). For the script to run, you must have given yourself the right permissions on the file. To see printout of state-node terms, uncomment the lines ; (format t "~%~%state-node terms: ~%~s~%" new-terms); DEBUG and ; (format t "~%~%Terms in state-node, within 'notice-new-local-facts':~%~s~%"; DEBUG ; new-terms); DEBUG in "gridworld-planning.lisp" ================================================================== Changes to gridworld code (LKS): - Changed various global parameters/variables to arrays of length = *n-agents*, to allow for multiple agents; - Designed operators so that they always include a first argument that specifies the agent; ensured that when one agent is planning, it doesn't consider instantiations of operators for *other* agents; - Made various functions (including 'go!') agent-dependent, to allow for multiple agents; in some functions, the agent index (I always use "j") is used to identify the agent, in others the name is used. I created a hash table that allows finding "j", given the agent name. - I changed 'graft-into-packet' to allow 'and'-ed antecedents in *world-knowledge* (even though this isn't needed here, this should definitely be allowed). - As noted above, this directory includes a multirun.lisp file (and in particular the 'runRandomized' function) and scripts for randomaized runs, written for the Brenner & Nebel world by Daphne Liu. - I've again included the CMU monitoring package, which can be useful for timing of various functions and debugging. (But the available monitoring functions in this file, which you can find by scanning for 'export ', are currently not used herein; see "gridworld-code-multiple-agents/" for example monitoring outputs.) - JUST FOR THIS MULTIAGENT WORLD: revised def-roadmap so that it creates adjacency info, but omits 'is_on' info, which isn't needed, and also creates initial 'is_occupied' facts as part of *world-facts* (but *not* as part of *roadmap-knowledge* -- the agents should not know in advance which locations are occupied. - JUST FOR THIS MULTIAGENT WORLD: revised place-object so that locations where agents are placed become occupied. - JUST FOR THIS MULTIAGENT WORLD: facts-evident-to requires not only objects colocated with an agent, but also neighboring locations (points) visible to an agent (so that it can tell whether or not the location is occupied); - NOT SURE IF FOR KEEPS: In 'go!', I reset the grandparent pointer to nil, to release storage; this sped things up in the colorballs world; - NOT SURE IF FOR KEEPS: In 'go!', I set unused children to nil in order to release storage; however, this didn't speed things up or reduce global garbage collection; - Deleted *is-actual*, which plays no role anywhere; - *node-now*, also isn't used anywhere, but was kept as it may play a role in other worlds.; ======================================================================