Applying the ARTIS Agent Architecture to Mobile Robot Control

Lecture Notes in Computer Science 1 Applying the ARTIS Agent Architecture to Mobile Robot Control Jose Soler, Vicente Julián, Carlos Carrascosa and Vicente Botti Departamento de Sistemas Informáticos y Computación. Universidad Politécnica de Valencia Camino de Vera s/n E-46071 Valencia (ESPAÑA) email: {jsoler, vinglada, carrasco, vbotti}@dsic.upv.es Abstract. The agent/multi-agent system paradigm is an important field of Artificial Intelligence. The use of this paradigm in real-world problems is one of the main lines of interest in this area. To do this, it is necessary to make use of agent/multi-agent architectures and artefacts. This paper describes an architecture for real-time agents, an artefact (InSiDE) for the specification of agentbased systems and the application of this architecture for the control of an autonomous mobile robot. Keywords. Distributed AI and Multi-Agent Systems, Robotics, Agents, Real- Time Systems. Paper Track Submission

Lecture Notes in Computer Science 2 Applying the ARTIS Agent Architecture to Mobile Robot Control 1 Introduction Over the last few years the use of the agent/multi-agent system paradigm has increased sharply as an important field of research within the Artificial Intelligence area. Concurrently, Real-Time Systems, and, more specifically, Real-Time Artificial Intelligence Systems (RTAIS) have emerged as useful techniques for solving complex problems, which require intelligence and real-time response times. In new hard real-time systems, flexible, adaptive and intelligence behaviours are some of the most important ones [1]. Thus, the agent/multi-agent system paradigm seems especially appropriate for developing hard real-time systems in hard real-time environments. Previous approaches to RTAIS can be found in the literature. Anytime algorithms [2] and approximate processing [3] are the most promising. One line of research in RTAI has been in building large applications or architectures that embody real-time concerns in many components [3], such as Guardian [4], Phoenix [5], PRS [6] and CIRCA [7]. Recent work in this area has incorporated the CELLO agent model [8] presented as an integrative answer for reactive and deliberative capabilities of a RTAI system. Almost all the above architectures are designed for soft real-time systems (without critical temporal restrictions). The ARTIS Agent (AA) architecture [9] is an agent architecture for hard real-time systems whose critical timing requirements are 100% guaranteed by means of an offline schedulability analysis as detailed in [10]. The agent must control an environment through a set of sensors. After this, the system must compute and transmit a response to the environment using a set of effectors. The response can be obtained after a reflex process or a deliberative process. Furthermore, the agent must work with hard temporal restrictions in dynamic environments. On the other hand, the AA can be integrated into a multi-agent system. To do this, the agent architecture must be extended to at least include inter-agent communication. To model a system by means of an AA, there exists a toolkit named InSiDE (Integrated Simulation and Development Environment) which facilitates the design and debugging of an AA. In this paper, a brief description of the InSiDE toolkit is presented, along with a quick look at the application of the AA to the control of a mobile robot for delivering packets. The paper is structured as follows: section 2 presents an overview of the ARTIS agent architecture. Section 3 shows the InSiDE toolkit and section 4 applies the architecture to mobile robot control. Some conclusions are presented in section 5.

Lecture Notes in Computer Science 3 2 Overview of the ARTIS Agent Architecture The ARTIS Agent architecture [9, 10] is an extension of the blackboard model [11] which has been adapted to work in hard real-time environments. According to the usual classification of the agent architectures, the ARTIS Agent architecture could be labeled as a hybrid architecture [12] that works in a hard real-time environment. From a user point of view in the ARTIS Agent architecture it can be found two types of knowledge to represent: Domain Knowledge: information about the agent s environment. Problem Solving Knowledge: methods that represent the agent s behaviour. 2.1 Domain Knowledge Domain knowledge representation in AA is carried out using the belief concept. It is not possible to have a global vision of the environment in a specific time. The agent has a limited view of its environment. The beliefs include the information that the system is able to perceive and the information employed by the problem solving process. The AA beliefs are based on a temporal frame model [13]. 2.2 Problem Solving Knowledge The entity organisation in this architecture provides a hierarchy of abstractions which organise the problem solving knowledge in a modular and gradual way. So, it can be distinguished the following different entities: ARTIS Agent (AA), internal agent (in-agent), multiple knowledge source (MKS) and knowledge source (KS). A A In-agent 1 In-agent 2... In-agent n M KS 1.1 MKS 1.2... M KS 1.m... KS 1.1.1 KS 1.1.2... KS 1.1.p... Figure 1. AA Hierarchy. Figure 1 shows the AA entity hierarchy, where the AA is the root of the hierarchy, which is the highest level of abstraction. One of the main reasons to do this is to employ one of the advantages of modular programming (complexity split and code reusability).

Lecture Notes in Computer Science 4 2.2.1 Knowledge Source (KS) The KS is the minimum abstraction within the ARTIS Agent architecture with the knowledge (either procedural or rule-based) to solve some part of a problem. Therefore, the MKS will be formed by KS. 2.2.2 Multi-level Knowledge Source (MKS) A MKS implements the concept of anytime algorithm and multiple methods, providing different solutions to the same problem with different computation times and different levels of quality [14]. Each one of these different solutions is a level of the MKS, and these levels are ordered so that the first one is the least time consuming and the worst quality solution. The last level is the best quality solution but it may be temporally unbounded. A level consists of a KS. MKS KS level 0 KS level 1 KS level 2 KS level n Figure 2. MKS internal structure. 2.2.3 Internal Agent or In-Agent An in-agent is an ARTIS internal entity that has the necessary knowledge to solve a particular problem (this knowledge can incorporate IA techniques that provide intelligence for solving the problem). This entity periodically performs a specific task (which may or may not be complex). Perception Cognition R E F L E X R T D Action Figure 3. In-agent structure. To provide its desired behaviour, each in-agent consists of: A Perception level: get the environment data that the in-agent is interested in. A Cognition level: it is formed by two layers: 1. A Reflex layer: assures a minimum answer (low quality answer in a bounded time) to the particular problem it is applied to. 2. A Real-Time Deliberative (RTD) layer: calculates a reasoned answer through a deliberative process.

Lecture Notes in Computer Science 5 An Action level: carries out the corresponding answer to the environment, no matter what level it was calculated in. At each period, the in-agent must decide between a reflex answer (provided directly by the reflex layer that is always executed until completion) and a more detailed answer provided by the real-time deliberative layer. This decision depends first on the time available to improve the answer, that is, if it is possible to calculate a better answer before the deadline. An in-agent cooperates within a real-time system with other in-agents [9]. 2.2.4 ARTIS Agent (AA) An AA is anything that can be viewed as perceiving its environment through sensors and acting upon that environment through effectors [15]. Additionally, it has the properties of autonomy, reactivity, proactivity and temporal continuity. In an optional way, AA may include even more features [9]. Though the basic AA is designed to work properly under hard real-time restrictions, some of the optional features (such as communication with other agents or a social behaviour) may prevent this real-time behaviour due to the unpredictable actions they involve. Therefore, it is the agent designer s decision to choose which features (and therefore which behaviours) the agent is going to have. An AA is mainly formed by a set of in-agents. Therefore, the perception of an AA is provided by the union of all the in-agent perceptions. The cognition of an AA is provided by the union of all the in-agent cognitions. Finally, the action of an AA is provided by the union of all the in-agent actions. 3 THE INSIDE TOOLKIT InSiDE is a visual toolkit which was developed to allow for agent-oriented implementation and management of ARTIS agents. By means of this toolkit, a user can build a prototype of an ARTIS Agent, which is directly executable. InSiDE allows for extremely rapid development of agents. The toolkit can be seen as "an agentifier" [16] (as Shoham says), because it bridges the gap between the low-level machine processes and the abstract level of agent programs. InSiDE builds a low-level process which represents the agent definition made by the user. The main functionalities of InSiDE are: To define the in-agent set of an ARTIS agent in a visual mode. To specify the different resolution methods, which are incorporated by an inagent, using C language or a rule-based language. To specify the meta-knowledge to determine the Intelligent Server behaviour, using a control language. To incorporate the definition of the agent beliefs, through a class definition language. The InSiDE toolkit has been developed in Java, so it can be executed on a wide variety of computer platforms and operating systems. InSiDE provides sophisticated

Lecture Notes in Computer Science 6 graphical tools for development. Its use is very intuitive. It incorporates a debugging environment during the specification process and it simulates the critical part of the ARTIS agent (in real-time). This option allows the user to detect failures in the specification. InSiDE also includes the necessary functions to analyse the schedulability of the ARTIS agent being developed (fulfilment of real-time timelines) based on a preemptive fixed priority scheduling policy [10]. Entity definition in InSiDE The entities of an ARTIS Agent are defined in InSiDE through visual forms (see Figure 4). Nevertheless, this definition can be translated to a lower level descriptive language [17]. In this language the user must include all the parameters needed by the toolkit in order to build the system. The entity definition language allows the user to be abstracted from the architecture and its implementation, during the domain knowledge definition. Figure 4. InSiDE toolkit: Entity Specification view Class Specification The ARTIS agent beliefs are defined by a class-specification language. The language allows us to develop a hierarchy of classes and instances to store in the temporal blackboard. A class is formed by a set of slots. A slot can be static (it only stores the current information) or temporal (slot with a history buffer). 4 A ROBOT CONTROL EXAMPLE A control software for a mobile robot based on the ARTIS agent architecture is presented in this section. The function of this robot is to transport light objects from one

Lecture Notes in Computer Science 7 office to another office on the same floor. To do this, the robot receives petitions by radio Ethernet, including the initial and final locations of the objects to move. The robot can receive requests at any moment and, in accordance with these requests and its current location, it should schedule the order to serve these requests. The scheduling process is based on user-defined priorities with the objective of minimising the delivery time. This system has been developed for the mobile robot Mobile Pioneer 2. The robot contains all the basic components for sensing and navigation in a real-world environment, including battery power, drive motors and wheels, position/speed encoders and integrated sensors and accessories. They are managed via onboard microcontroller and mobile-robot server software. The robot has a ring of 16 sonars. The sonar positions are fixed in two arrays (front and rear): one on each side and six facing outward at 20-degree intervals providing more than 180 degrees of nearly seamless sensing, and all-around sensing when using both forward and rear arrays. The server software has an internal localization mechanism which provides an approximate estimation of its location. All this information is sent through the RS-232 serial port. The AA is executed in a notebook over the RT-Linux operating system. The notebook has a radio Ethernet which allows the connection to the request senders (see figure 5). Figure 5. Pioneer 2 with a notebook 4.1 Robot AA Specification The robot s global behaviour has been modelled into a in-agent set. Each one of these in-agent (see Figure 6) is described below: Avoid_obstacles. It is necessary to ensure the safety of the robot and the office furniture. This in-agent takes all the necessary actions to avoid any collisions. This is the highest priority in-agent in the system, because the robot s environment can change due to unexpected events like the movement of objects or new static elements, which are not defined in the initial world description. Principally, this inagent should adapt the initially planned robot trajectory, in order to avoid all of these unexpected events. Malfunction monitoring. This in-agent must control the system to keep the robot in good working order. It must detect all malfunction problems. It specially has to assure the serial port communication state, detecting communications faults and doing the necessary actions in order to reconnect the system or to bring the robot to a safe state. It must also control the battery power status, running the alert mechanisms that allow us to lead the robot to the battery charge position in time.

Lecture Notes in Computer Science 8 Localization. At any time, the robot must know an estimation of its position within its work stage. To do this, a mechanism is needed to get this estimation and to continuously validate it. The system has a topological map of the environment allowing it to locate the different offices and the paths between them. For each office, there is a reticular map detailing its internal distribution. To verify the localization estimated by the Pioneer robot, it is necessary to contrast the sonar inputs with the predicted values from the reticular map of each office. Trajectory Planner. This in-agent is in charge of calculating the robot s trajectory and determining the actions to control the robot engines, in order to achieve the planned objectives. These trajectories can be modified by either mistakes in the robot s movements or by trajectory modifications to avoid obstacles. For this reason, it must assure the fulfillment of the goals by recalculating trajectories according to new changes in the robot movements. To carry out these tasks, the in-agent will share information with the above mentioned in-agents. Job planning. This in-agent must fulfill the global objectives of the robot. It analyses the requests received and it schedules the different actions to carry out, that is, what to do next. To do so, it uses the topological map of the environment to obtain the new objectives which will be communicated to the Trajectory planner in-agent. Radio communication. It implements the communication between the robot and the users via radio Ethernet. It will send the received requests to the Job Planning in-agent. The in-agent structure obtained is shown in Figure 6. Robot Avoid Obstacles Radiocommunication Malfunction Monitoring Job Planning Localization Trajectory Planner Figure 6. AA structure In-agent definition Due to the limits of this paper, only one of the in-agents is defined. The in-agent described is the one in charge of avoiding obstacles, which is the highest priority, and which is formed by two MKSs (one of perception and one of cognition) and one KS (action). The perception MKS must obtain the information from the robot sensors that allow it to detect any obstacle. The cognition MKS will calculate the actions to do when the probability of colliding with an object is very high. The action KS will

Lecture Notes in Computer Science 9 send the actions calculated by the cognition MKS to the serial port. The definition of this in-agent according to the ARTIS entity definition language [17] is 1 : (defagent avoid_obstacles ( period 100 ) // 100 ms ( deadline 8 ) // 8 ms ( importance 1 ) //the most important ( perception (read_sensors) ) ( cognition (avoid) ) ( action (act_avoid) ) ( precedence (nil) ) ) The MKS definitions are the following: Read_sensors. This MKS has only one level with a KS that is mandatory, because the perception phase is always critical on an in-agent. ( defmks read_sensors () ( read_sensor_serial ) ( type Mandatory) ( importance 1 ) ( method Multiple) ) Avoid: It is formed by two levels. The first one is mandatory and gets a basic first solution to keep the system safe. The second level will search for a better solution to avoid the obstacle. This solution will attempt to minimize the changes in the trajectory that the robot follows to get its objective. ( defmks avoid () ( save) (alternative_trajectory) ( type Mandatory) ( importance 1 ) ( method Multiple) ) The KS definitions are the following: read_sensor_serial: It is implemented in C language, and it reads the information packets from the serial port sent by the robot with the different sensor values. ( defks read_sensor_serial () ( wcet 2) // ms ( codefile.\read_sensor_serie.c ) ) save: It is implemented in C language, and it proposes basic actions such as reducing the velocity, stopping the robot, or escaping if the collision is with a moving object. ( defks save () ( wcet 1) // ms ( codefile.\save.c ) ) alternative_trajectoy: It is based on rules, and it searches a change in the robot s trajectory such that the impact over the initial trajectory will be the least possible. ( defks alternative_path () RTOS ( wcet 2) // ms ( codefile.\alternative_paht.arl ) ) 1 All the time measures are in milliseconds (ms).

Lecture Notes in Computer Science 10 act_avoid: It acts over the robot engines and executes the actions obtained by the avoid MKS. To do this, it builds and sends the different packets with the actions that the robot must execute through the serial port. ( defks act_avoid () ( wcet 1) // ms ( codefile.\act_avoid.c ) ) Class Definition Next, some of the classes and objects that are part of the AA domain knowledge are shown in Figure 7. In particular, the ones referring to the robot s physical structure are defined. (defclass ROBOT // robot serial output { (slot pos (type position)) (slot bump (type bumper)) (slot status (type int)) (slot vel_rigth (type int)) (slot vel_left (type int)) (slot front_sonar_bat[8] (type sonar)) (slot rear_sonar_bat[8] (type sonar)) (slot serial_status (type int)) } ) Figure 7 Class specification in InSiDE The ROBOT class has all the attributes obtained from the port readings that are of interest to any of the different in-agents of the AA. 5 CONCLUSIONS This paper shows how the ARTIS agent architecture can be applied to solve a real world problem (autonomous mobile robot control). By extension, it shows how agent-oriented methodology can be applied to solve real-time complex problems. To do so, software architecture along with development artefacts are needed. The paper briefly describes the ARTIS agent architecture and the development tool. This new tool allows the programmer to do the off-line schedulability analysis of the hard temporal restrictions of the new AA, which is necessary when a real-time system is de-

Lecture Notes in Computer Science 11 signed. Further investigation is needed to add new behaviour features to the AA. Initial work has begun on inter-agent communication as a social behaviour of an AA References 1. Stankovic, J. A.: Misconceptions About Real-Time Computing. IEEE Computer, vol. 12, no. 10 (1988) 10-19. 2. Dean, T., Boddy, M.: An analysis of time-dependent planning. Proceedings of the seventh National Conference on Artificial Intelligence, 49-54, St. Paul, Minessota, August (1988). 3. Garvey, A., Lesser, V.: A survey of research in deliberative Real-Time Artificial Intelligence. The Journal of Real-Time Systems, 6, 317-347, (1994). 4. Hayes-Roth, B., Washington, R., Ash, D., Collinot, A., Vina, A., and Seiver, A.: Guardian: A prototype intensive-care monitoring agent. Artificial Intelligence in Medicine, 4:165-185, (1992). 5. Howe, A. E., Hart, D. M., and Cohen, P. R.: Addressing real-time constraints in the design of autonomous agents. The Journal of Real-Time Systems, 2: 81-97, (1990). 6. Ingrand, F., Georgeff, M. P., and Rao, A.: An architecture for real-time reasoning and system control. IEEE Expert, 34-44, December (1992). 7. Musliner, D., Durfee, E., Shin, K.: CIRCA: a cooperative intelligent real-time control architecture. IEEE Transactions on Systems, Man and Cybernetics, 23(6), (1993). 8. Occello, M., Demazeau, Y.: Modelling decision making systems using agents satisfying real time constraints, IFAC Proceedings of 3rd IFAC Symposium on Intelligent Autonomous Vehicles, 51-56, Vol. 1, March (1998). 9. V. Botti, C. Carrascosa, V. Julian, J. Soler. Modelling Agents in Hard Real-Time Environments. Proceedings of the MAAMAW'99. Lecture Notes In Computer Science, vol. 1647. Springer - Verlag (pag. 63-76), Valencia 1999. ISBN 3-540-66281-2. 10. García-Fornes, A., Terrasa, A., Botti, V., Crespo, A.: Analyzing the Schedulability of Hard Real-Time Artificial Intelligence Systems. Engineering Applications of Artificial Intelligence. Pregamon Press Ltd. (1997) 369-377. 11. Nii, H.P. (1986) Blackboard Systems: The Blackboard Model of Problem Solving and the Evolution of Blackboard Architectures. THE AI MAGAZINE Summer(1986), pp. 38-53. 12. Muller, J. P.: A conceptual model for agent interaction. In Deen, S. M. Editor, Proceedings of the second International Working Conference on Cooperating Knowledge Base Systems, pages 213-234, DAKE Centre, University of Keel. (1994) 13. Barber, F., Botti, V., Onaindía, E. and Crespo, A. (1994) Temporal Reasoning in REAKT: An environment for Real-Time Knowledge-Based Systems. AICOMM 7 (3), pp. 175-202. 14. Botti, V., Hernández, L.: Control in Real-Time Multiagent Systems. In: Garijo, F., Lemaitre, C. (eds.): Proceedings of the Second Iberoamerican Workshop on DAI and MAS. Toledo, Spain (1998) 137-148. 15. Russell, S., Norvig, P.: Artificial Intelligence: A Modern Approach. Prentice Hall International Editions (1995) chapter 2, 31-50. 16. Shoham, Y. Agent-Oriented Programming. Readings in Agents. ISBN 1-55860-495-2. (1997), 329-349. 17. Carrascosa, C., Julian, V. J., García-Fornes, A., Espinosa, A.: Un lenguaje para el desarrollo y prototipado rápido de sistemas de tiempo real inteligentes. Actas de la CAEPIA97, 685-694 (1997).