Application of Mobile Code to Development of ... - Semantic Scholar

Application of Mobile Code to Development of Cooperative Multirobot Systems Francesco Amigoni and Marco Somalvico Politecnico di Milano Artificial Intelligence and Robotics Project Dipartimento di Elettronica e Informazione Politecnico di Milano, Milan, Italy [email protected], [email protected] Abstract. Multirobot systems address an increasing number of different applications. However, a general assessed methodology for designing and developing the cooperation structure of these systems is still lacking. In this paper we present one of such methodologies, called dynamic agency, which is strongly based on a novel distributed production system, called DCLIPS, that acts an infrastructure for inferential code mobility. The adoption of mobile code promotes ease and flexibility in developing and managing the cooperation structure of multirobot systems. We have experimentally tested our methodology by building a multirobot system that maps unknown environments.

1

Introduction

The present market and technology yield the possibility to build systems composed of several robots that cooperate in order to reach a global goal [4]. Usually, the cooperation structures of such systems are made in an ad-hoc fashion to uniquely address the particular applications at hand [6]. The modern technology of mobile code systems [8] can provide the required flexibility for building in a general way the cooperative components of multirobot systems. In mobile code systems, the code and possibly the state of an executing program can migrate over hosts at run-time. The purpose of this paper is to illustrate a novel distributed production system, called DCLIPS, that enables code mobility over robots. This code mobility supports dynamic agency [1]: an architecture and methodology for the development of a uniform cooperative framework among different specific operative robots, to drive them toward the solution of a global problem. The code that can be moved among robots by means of DCLIPS environment is composed of rules and facts, namely it is inferential code executable by the production systems located on robots. This paper is organized as follows. The next section illustrates DCLIPS both at the programmer’s level and at the implementation level. In Section 3, we outline the importance of DCLIPS for robotic applications by describing the experimental activities we have carried on with cooperating exploring mobile robots. In Section 4 we relate our work to the literature on distributed production systems and mobile code systems for robotic tasks. Finally, Section 5 concludes the paper. 2

The DCLIPS Environment

The DCLIPS environment is a collection of communicating independent production systems that are located on different nodes of a network and that exchange knowledge

by a global shared memory. Each production system is based on the well-known CLIPS [5] environment. DCLIPS is a distributed production system [10] that supports both the migration of inferential code (facts and rules) and the communication among the composing production systems. 2.1 Programming with DCLIPS From the programer’s point of view, DCLIPS is composed of a number of agent environments that exchange knowledge via a shared memory area called knowledge space (KS for short), as shown in Fig. 1(a). Each agent environment is a modified CLIPS environment composed of a facts base (also called working memory), a rules base (also called production memory), and an inference engine that matches through pattern matching the preconditions of the rules with facts, selects a rule to fire among those with satisfied preconditions, and executes the actions of the selected rule. An agent environment of DCLIPS extends a CLIPS environment by offering a number of new commands to exchange knowledge with other agent environments through KS. These commands are discussed below. AE1

node1 FB1

AE1

IE1

KSS1

RB1 AE2

node2 FB2

AE2

IE2

NA

KS

KSS2

RB2

...

... AEn

AEn

FBn IEn RBn

(a)

noden

KSSn

(b)

Figure 1: The structure of DCLIPS as it appears to the programmer (a): AE i are the agent environments, FBi are the facts bases, RBi are the rules bases, IEi are the inference engines, double arrows represent CLIPS communication, and single arrows represent DCLIPS communication. The internal architecture of DCLIPS (b): AEi are the agent environments, KSSi are the knowledge space servers, and NA is the network agent

Registration to knowledge space. na-join registers an agent environment to access the KS with a unique name. Conversely, na-leave un-registers the agent environment from accessing the KS. Knowledge insertion in knowledge space. ks-put inserts a fact in the KS; the fact can be ordered or unordered (in this case the corresponding descriptor, the deftemplate, must be specified). ks-share inserts a construct in the KS; constructs can be rules or functions (procedural knowledge is considered as a particular subclass of rules). Knowledge extraction from knowledge space. ks-read and ks-get retrieve the facts in the KS that match the specified pattern (when retrieving unordered facts, the corresponding deftemplate must be specified). The retrieved facts are inserted in the local facts base. ks-read leaves the retrieved fact in the KS, whereas ks-get removes the retrieved fact from KS. Command ks-use retrieves a construct in the KS and inserts it in the local rules base. The retrieved construct is left in the KS.

Error handling. ks-errorp returns the symbol TRUE if any error occurred during the execution of last command. ks-error-msg returns a string that describes the last occurred error. 2.2 The Implementation of DCLIPS The main issue of the DCLIPS implementation is that the KS itself is distributed. At the implementation level, the DCLIPS architecture is composed of a set of distributed and communicating nodes (see Fig. 1(b)). Each node has two parts: the agent environment (illustrated in previous section) and the knowledge space server that manages the portion of KS assigned to the node. As better illustrated in Section 3, the nodes are located on robots. The DCLIPS architecture is completed by a network agent that can be considered as a special node that locates the other nodes (and thus the agent environments) on the network. It maintains a database in which, for each agent environment, the physical address of the corresponding node is registered. The database is kept consistent by dynamically updating it as agent environments (and the corresponding nodes) join and leave the system. In particular, the network agent offers two services. The first one is registration/un-registration to/from the system; it is exploited for executing ks-join and ks-leave commands. The second one is multiple (single) query: it returns all the registered nodes (the first node) that match a given criterion. The query services are not available to the programmer and are part of the implementation of the DCLIPS commands that access the KS. The network agent allows mutually exclusive access to its functions. The use of a centralized name server (the network agent) has the disadvantage of creating a bottleneck in the system, but it is the simplest solution for naming services. The agent environment of a node extends a CLIPS environment. It interprets in the usual way the standard commands of CLIPS and, for DCLIPS commands, it performs the following algorithm. (1) Gather the parameters of the command (e.g., gather the pattern that describes a fact for ks-read) (2) Query the network agent to obtain the list of currently registered nodes (3) Send to the knowledge space servers of registered nodes the requests to execute the operations connected to the command (in the case of ks-read, send requests to read a fact described by the pattern) (4) Collect the results (in the case of ks-read, collect the read facts) (5) Return the result of the execution of the command (in the case of ks-read, return the first read fact) The knowledge space server of the node i manages the local portion KSi of KS by offering the following services. – Allow the node i, and only node i, to write knowledge in KSi (exploited for executing ks-put and ks-share commands). – Allow every node to read or extract knowledge from KSi (exploited for executing ks-get, ks-read, and ks-use commands). When a request to read or extract a fact arrives, the knowledge space server of node i tries to match the requested pattern with the facts present in KSi . If a matching fact is retrieved, then it is

returned, otherwise a null element is returned. In a request to use a construct, both the name and the type of the searched construct are specified. In this case, the knowledge space server of node i searches KSi for an element with the key (name,type). – Ensure the atomicity of accesses (read and write operations) to KSi . The knowledge space server of node i gives exclusive access to KSi to a single requesting node at a time. It also maintains a queue of pending requests to access KSi . The union of the contents of the portions KSi of the KS constitutes the global knowledge shared by the whole system. The main disadvantage of our distributed solution for KS is that, when agent environment A wants to send knowledge k directly to agent environment B, A inserts k in KSA . Then, B has to search all KSi in order to find k. An alternative method (not yet experimentally tested) could be that A puts k in KS B and B looks first in its local portion of KS. In our solution, the combined activity of agent environments and of knowledge space servers results in the transparency of the distribution of KS for the programmer of DCLIPS applications. All the described modules have been coded according to a structure organized on several layers for ensuring the maximum flexibility in the use of DCLIPS. Apart from some interface modules between CLIPS and DCLIPS kernel that are written in C, the modules that form the DCLIPS kernel are written in Java. The integration of the two kinds of modules exploits JNI (Java Native Interface [11]). The interface modules have been developed in such a way that the KS can be accessed also by nodes that run procedural code, such as the perception units of robots, which can in this way access the KS for inserting knowledge about the perceived data. The pattern matching implementation in knowledge space servers exploits JESS [7]. The kernel of DCLIPS is a federation of distributed objects that are located in the nodes and that communicate via RMI. The main of these objects are the following ones. KSServer objects, the servers of knowledge space. KSClient objects, the clients of knowledge space that allow to interact with remote (i.e., located on other nodes) KSServer objects. NAServer object, the server that offers the services of network agent. NAClient objects, the clients of network agent that interact remotely with the network agent. The NAServer object implements the network agent previously described. A knowledge space server is implemented by a KSServer object. Finally, the implementation of an agent environment includes a KSClient object and a NAClient object that are connected with the modified CLIPS environment. As their names suggest, these objects interact together mainly in a clientserver fashion. 3

Experimental Activity

We have defined a general methodology and architecture for developing multiagent systems, of which multirobot systems are a subclass, called dynamic agency [1]. The dynamic agency approach is based on the use of mobile code systems and on the conception of each agent of a multirobot system as composed of two parts (Fig. 2 left). The first part, called op semiagent, is a (usually preexisting) robot devoted to perform specific operative functions. The second part of an agent, called co semiagent, is a set of software modules designed to perform uniform cooperative functions. According to the dynamic agency approach, the co semiagents are the result of the evolutionary metamorphosis of a single mobile code that travels, visits, and evolves on the op semiagents. Hence, op semiagents host an incoming mobile code in order to put it into execution,

by decoding it and assigning it the required resources. The mobile code is called MIA (from Mobile Intelligent Agent). The op semiagent is composed of the robot, called FIA (from Fixed Intelligent Agent) and of the hosting component, called MFI (MIA-FIA Interface). The activities of MIA are designed to install the co semiagents on the op semiagents to control them in order to cooperatively reach a global goal. In this way, the operative functions provided by the op semiagents can be exploited in the high-level cooperation framework set up by the co semiagents that exchange knowledge, coordinate activities, and divide and assign goals. This means that MFI must be designed in such a way that a co semiagent and the corresponding FIA, which are usually developed by different designers, can communicate.

MODULES DERIVED FROM THE EVOLUTION OF A REPLICA OF MIA CO SEMIAGENT

HOST MODULE MFI OP SEMIAGENT

FACILITIES ACCESS MODULE

COMMUNICATION MODULE

SENSORS, PROCESSING, ACTUATORS

FIA

Figure 2: The architectural structure of an agent in a dynamic agency

DCLIPS provides the infrastructure for code mobility [2] required by dynamic agency: it assists the design, implementation, deployment, and execution of inferential mobile code. We have developed a system composed of mobile robots for mapping unknown environments. This application is recognized as very important for multirobot systems; however, to date our effort has been more on showing the role of DCLIPS as infrastructure for developing cooperative multirobot systems than on the quality of resulting map. For this reason, we have implemented very basic robotic solutions. The multirobot system has been composed starting from four FIAs: three mobile robots and a computer. The mobile robots have three-dimensional vision systems and encoders as sensors and with driving wheels as actuators. We now detail the structure of MFIs of the four FIAs of our system (refer to Fig. 2 right). Each MFI includes a communication module based on wireless IEEE 802.11 medium and protocol; the communication modules offer also a TCP/IP stack to send and receive messages to and from other op semiagents. The facilities access modules of robotic FIAs offer access to the following operative functions: moving the robot (forward, backward, and turn), getting the set of extracted segments from the images taken by the vision system, getting the robot position from the encoders, activating the path planning process (given a map, the starting, and the ending points), getting some information about the robot (e.g., its dimensions, the dimensions of its vision field, its battery level, its maximum moving velocity and precision, and so on). The host modules of (MFIs of) op semiagents are nodes of DCLIPS (see Section 2.2). The MIA that constructs the co semiagents is composed of facts and rules and it is initially sent in the KS from a connected computer by the designer of the multirobot system. From there, it is detected and locally copied by all the op semiagents, providing code mobility. In particular, the host module (recall it is DCLIPS node) of an op semiagent i has initial sets of facts Fi and rules Ri that monitor the KS to detect and copy a MIA (an example of rule in Ri is shown in Fig. 3 left). After this step, the facts

base and the rules base of the host module of op semiagent i are FBi = Fi ∪ FMIA and RBi = Ri ∪ RMIA , respectively. FMIA and RMIA are the facts and rules of MIA that are organized in several modules whose sequential activation carries on the metamorphic evolution that brings to the development of the cooperation structure of the multirobot system. The switching between a module and the following one is performed by the former by putting an activation fact in the local fact base. In what follows, due to space limitations, we only list the phases (each one performed by a module of MIA) without giving their full explanation (see [1] for a more detailed illustration).

(defrule get-MIA "copies MIA from KS" (initial-fact) ?e (if (ks-get (str-cat "(FIA $?" ?*MIA-ID* ")" ) ) then [MIA is available in the KS] (retract ?e) … copy the MIA from KS … else (retract ?e) (assert (look-for-MIA) ) ) )

(defrule share-organizer "shares extraction result" (declare (salience 100)) (initial-fact) ?e (retract ?e) (bind ?*FIA-TYPE* ?type) (bind ?str (str-cat "(FIA-INFO " "(ID " ?name ")" "(FIA-type " ?type ")" "(FIA-width " ?width ")" "(FIA-length " ?length ")" "(FIA-vision-field-depth " ?vision_depth ")" "(FIA-vision-field-width " ?vision_width ")" ")" (ks-put ?str) …))

(defrule set-the-role "sets the role for the agent" (initial-fact) ?e (if (eq ?*FIA-TYPE* "ws") then [the FIA is a workstation] (retract ?e) … delete the modules of explorer agent … … instantiate the modules of coordinator agent … else [the FIA is a robot] (retract ?e) … delete the modules of coordinator agent … … instantiate the modules of explorer agent … )

Figure 3: Some of the rules of the MIA that builds an exploring multirobot system

Each copy of MIA extracts (from a file) the knowledge about the corresponding robot (op semiagent): how to activate its functions, its physical dimensions, and so on. A rule for sharing (through KS) the results of extraction is shown in Fig. 3 center. Then, a hierarchical structure is formed according to the extracted knowledge: the computer agent acts as coordinator and is the root of the hierarchical organization of which robotic agents, the explorers, are the leaves. A rule for assigning roles to agents is shown in Fig. 3 right. The robots are placed in an environment to be mapped and their initial positions are determined (by reading a file or by auto-localization techniques). The agents negotiate the areas worth to be explored until all explorers have been assigned a goal. All the required communication is performed via KS. Explorer agents extract segments, representing the map of the area to explore, from the images taken by vision system at the assigned location. Then the partial maps of the environment obtained by explorers (namely, sets of segments that are exchanged as facts through KS) are integrated (on the basis of robots’ positions) by the coordinator to obtain the final global map. At this point a new mapping step starts with negotiation of interesting areas. With the described system, we have been able to map part of the hall of our Department building. The travel of MIA on op semiagents takes some minutes, because of the dimensions of MIA code and of the limited bandwidth (up to 2M b/s) offered by wireless communication. However, the travel of MIA is performed only at the beginning of the construction of the system. A mapping step takes several minutes since the transfer of the sets of segments is very time consuming and, in the present version, the negotiation process lasts until every explorer has been assigned an area to explore. During the experimental activity, DCLIPS has proved to be a reliable infrastructure for multirobot systems. The main advantage of dynamic agency approach over other multirobot methodologies is the flexibility that promotes an easy reuse of existing robots for different purposes. For example, we employed the same robots used in exploration task for the task of sweeping a known environment by simply sending a new MIA that sets up a new cooperation framework exploiting in a different way the operative functions of robots.

Moreover, multirobot systems can be automatically reconfigured. For example, a supervisor component of our exploring multirobot system might decide to recruit a new small robot to map a newly discovered room accessible by a narrow doorway. As another example, we can conceive a multirobot system that automatically switches robots from the task of exploring to the task of sweeping the floor of an environment as it is more and more mapped. Work in currently undergoing to implement these possibilities. 4

Related Works

Distributed production systems [10] have been widely studied and employed to build expert systems and to implement sense-and-act models in cognitive science and in robotics. The KS of DCLIPS can be thought a tuple space (as defined in the Linda programming language [9]) with a pattern matching mechanism. The KS represents also an example of the well-known blackboard approach: a shared memory paradigm widely used in distributed artificial intelligence [3]. Another recent system based on a Linda-like tuple space is lime [14]. The investigation of the relations between robotics and mobile code systems has been addressed only by a very few papers. Mobile code is mainly used to implement teleoperation systems for robots [16]. For example, [13] describes a system in which a mobile robot moves in a museum according to the (asynchronous) commands issued by the user through a mobile agent (is a particular kind of mobile code that can autonomously decide when and where to move [15]). An unusual application of mobile code to mobile physical objects involves the tile-shaped computers called Tiles [12]. In conclusion, to the best of our knowledge, the dynamic agency approach represents the first attempt to spread a uniform cooperation structure over specific robots by means of mobile code systems. 5

Conclusions

In this paper we have presented a significant application of mobile code to the flexible development of the cooperation structure for multirobot systems. The proposed dynamic agency approach is based on the decoupling of operative and cooperative parts of each agent and on the implementation of the latter as an evolved mobile code. This promotes the possibility to easily change or modify the cooperative parts also during the activity of the multiagent system. The experimental activity has established the validity of the dynamic agency approach and the usefulness and reliability of the DCLIPS as an infrastructure for mobile code. Future research is required to improve DCLIPS environment to ease the development and the installation of MFI on robotic FIAs. We are planning to further test DCLIPS in multiagent systems involving both robotic agents and software agents. More generally, future work will address the refinement of the dynamic agency approach as a general methodology for multiagent systems. Acknowledgement The authors are glad to thank the contribution of Gianmarco Antonini, Dario De Palma, Emanuele Prina, and Luigi Spalla to carry on this research.

References [1] F. Amigoni and M. Somalvico. Dynamic agencies and multi-robot systems. In T. Lueth, R. Dillmann, P. Dario, and H. Worn, editors, Distributed Autonomous Robotic Systems 3, pages 215–224. Springer-Verlag, Berlin Heidelberg, Germany, 1998. [2] Y. Aridor and M. Oshima. Infrastructure for mobile agents: Requirements and design. In K. Rothermel and F. Hohl, editors, Mobile Agents, Second International Workshop, MA’98, Stuttgart, Germany, September 9-11, 1998, pages 38–49. Springer, 1998. [3] A. H. Bond and L. Gasser. Readings in Distributed Artificial Intelligence. Morgan Kaufmann, San Mateo, USA, 1988. [4] Y. U. Cao, A. S. Fukunaga, and A. B. Kahng. Cooperative mobile robotics: Antecedents and directions. Autonomous Robots, 4:1–23, 1997. [5] CLIPS. http://www.ghg.net/clips/clips.html. [6] G. Dudek, M. Jenkin, E. Milios, and D. Wilkes. A taxonomy for multiagent robotics. Autonomous Robots, 3:375–397, 1996. [7] E. Friedman-Hill. Java Expert System Shell. herzberg.ca.sandia.gov/jess/.

Sandia National Laboratories.

[8] A. Fuggetta, G. P. Picco, and G. Vigna. Understanding code mobility. IEEE Transactions on Software Engineering, 24(5):342–361, 1998. [9] D. Gelernter. Generative communication in linda. ACM Transactions on Programming Languages and Systems, 7(1):80–112, January 1985. [10] T. Ishida. Parallel, Distributed and Multiagent Production Systems. SpringerVerlag, 1994. Lecture Notes in Artificial Intelligence 878. [11] JavaSoft. Java Native Interface Specification, 1997. www.javasoft.com. [12] K. Kramer. Mit tiles project: Moveable objects, mobile code, 1998. MIT MS Thesis, http://el.www.media.mit.edu/projects/tiles/msthesis-formatted.html. [13] K. Matsubara, K. Kato, T. Maekawa, S. Maeyama, S. Yuta, and A. Harada. Asynchronous robot teleoperation via the internet: Mobile agent approach. In Proceedings of SSGRR International Conference on Advances in Infrastrucure for Electronic Business, Science, and Education on the Internet, 2000. [14] Amy L. Murphy, Gian Pietro Picco, and Gruia-Catalin Roman. Lime: A Middleware for Physical and Logical Mobility. In Forouzan Golshani, Partha Dasgupta, and Wei Zhao, editors, Proceedings of the 21st International Conference on Distributed Computing Systems (ICDCS-21), pages 524–533, May 2001. [15] G. P. Picco. Mobile agents: An introduction. Journal of Microprocessors and Microsystems, 25(2):65–74, April 2001. [16] J. Rning and K. Kangas. Interacting with personal robots and smart environments. In Proceedings of the SPIE Conference 3837: Intelligent Robots and Computer Vision XVIII: Algorithms, Techniques, and Active Vision, Boston, Massachusetts, September 19-22 1999.