Layered multi agent architecture with dynamic ... - CiteSeerX

2 downloads 0 Views 334KB Size Report
to keep it simple. In addition to the above problem, there is another considerable problem due to the static configuration. The static configuration means that the.
Proceedings of the 1003 IEEE loternational Conference on Robotics & Automstion Taipei, Taiwan, September 14-19, 1003

Layered Multi Agent Architecture with Dynamic Reconfigurability Eiichi Inohira, Atsushi Konno and Masaru Uchiyama Department of Aeronautics and Space Engineering, Tohoku University Aoba-yama 01, Sendai 980-8579, Japan e-mail: {inohira, konno, uchiyama}@space.mech.tohoku.ac.jp

Abstract This paper presents the software system architecturr with the dynamic reconfigurability for highly autonomous systems. The proposed architecture is based on multi-agent model, which is suitable for autonomous, open and distributed systems. Since an agent is too sophisticated as the minimal component that we handle, we define a unit as a simple component of an agent. We present the advanced capability to dynamically reconfigure autonomous systems because their goals and enuiron,ments valy frequently. We determine the specification of units and agents in order to analyze the behavior of overall system and to implement the dynamic reconfiguration as easy and simple as possible. In this paper, we also discuss the method to guarantee the system behavior during the dynamic reconfiguration in order to operate the robotic system without a hitch at any time, especially while reconfiguring.

1 Introduction Enhancing autonomy of a robotic system is one of basic requests so that we would like to reduce the intervention in detail. In order to achieve the goal, an autonomous robotic system needs functions such as motion control, perception, planning, and learning. The software system becomes complex in structure since the above functions are implemented as the software. And so, it is very important that the architecture, which refers to specification of subsystems and underlying computational conccpts[l]. Until now, many styles of the software system architecture for robotic systems have been proposed. Those are roughly classified into three types: hierarchical, behavioral and hybrid. Either of these architectures has some defects. The hierarchical architecture, which relies on a topdown approach, has poor flexibility. On the other hand, the behavioral architecture, which is based on a bottom-up approached, has low scalability. Although it is well known that both hierarchization

0-7803-7736-2/03/$17.0002003 IEEE

and concurrent processing should he combined, it, is not easy to actually design the hybrid architecture and to keep it simple. In addition to the above problem, there is another considerable problem due to the static configuration. The static configuration means that the software must be shut down and restarted every time it is modified. Furthermore, A robot must evacuate into safe positions and poses before a shutdown and restart of the software. In such a system, it takes much time to modify the goal and the environment. This is a serious problem in the case of autonomous mobile robots because their goals and environments vary frequently, even while operating. A solution to the problem is the dynamic reconfiguration, which is to change the system behaviors at runtime. The dynamic reconfigurability not only simplifies all the work regarding a robotic system, but also provides an advanced capability, that is, self-adaptation. For instance, a robot itself can modify the control algorithm according to a situation. The dynamic reconfignrability is the key technology sirice it can boost up the autonomy of autonomous robotic systems. In this paper, we propose the software system architecture with dynamic reconfigurability. We also discuss the method to guarantee the system behavior while reconfiguring in order to operate autonomous robotic systems without a hitch at any time. The rest of this paper is organized as follows. Section 2 describes the layered multi agent architecture. Section 3 presents the underlying computational model. Section 4 discusses the method ta guarantee of a system during the dynamic reconfiguration. We consider related work in Section 5, and conclude this paper in Section 6.

2

Layered multi agent architecture

Multi agent architecture is suitable for autonomous, open, distributed systems. It excels at modularity because a system consists of cooperative agents, which

4060

System ,...Software ..

are independent concurrent processes. In multi-agent systems, we should consider the trade-off between the number of agents and the complexity of each agent[2]. However, this is hard work in the case of a large-scale system. The problem is that the conventional styles of multi agent architecture do not refer t o the layered structure explicitly. We define "the layered multi agent architecture" in order t o solve the above problem and t o target a t a large-scale robotic system such as a full-featured humanoid robot. The basic idea is t o incorporate multi agent architecture into a layered structure. In other words, a multi agent system is divided into an agent framework and components. In Fig. 1, the schematic view is shown. In our architecture, an agent consists of small and simple components in a uniform style. We define such components as "units." Although such an idea is very simple, there are the following benefits.

rl Robot

It is easy to integrate a system We can classify the components in detail for the purpose of reuse and portability.

Figure 1: An generic diagram of the layer multi agent architecture

An agent can have the various and advanced faculties by combining units. It is important to he separate into the system integration and the implementation of functions by an agent framework and units. The separation facilitates designing the architecture and realizing of the dynamic reconfiguration.

any memory area except output buffers. Also, we define that a normal unit does only calculation and is platform-independent. An interface unit can interact with t h e following subsystems. Sensors and actuators File systems

Computational model

3

The other agents

3.1 Unit A unit is a minimal element in our architecture and is a component of an agent. In order t o separate units into platform-dependent and platform-independent components, the two typcs of a unit are defined a normal unit and an interface unit. A normal unit consists of the following components. e

A data processing function

0

An output buffer

Inputs of a unit function are output buffers of specified units as shown in Fig. 2. When a unit function is invoked, the output correspond t o the inputs is calculated and then is written into the output buffer. In order to assnme that the state of units is saved in only output buffers, we define that a unit must not access

For instance, an interface unit is allowed t o read from a file, or write into a file as shown in Fig. 3. In this case of Fig. 4, the communication between agents is done via the interface unit that shares the output buffer with that of a unit of another agent. This is how the communication between existing normal units is realized without modification of them. An interface unit is platform-dependent so that it depends on the accessed subsystems. Next, we discuss the unit structure with dynamic reconfigurability. In our architecture, we cannot decide the unit configuration a t the stage of the design and development, that is, the static configuration. At this time, only data types of inputs and output of a unit can be determined. As shown in Fig. 5, we can first determine which unit the intended one is connected with after loading an agent with it. At this time, the agent must check the data types of the input

4061

Interface unit A

Interface unit B

Figure 3: Examples of interface units Figure 2: A generic diagram of the data flow between normal units

and output to prevent an error. Moreover, the following states of a unit are defined as shown in Fig. 6 . Uninitialized Ready Terminated

Also, We should define the three functions correspond to the transition between these states.

3.2

Agent

In our architecture, the structure of an agent frame work is shown in Fig. 7. The agent framework has the two faculties: the management of the units and ex+ cution of the unit functions. We define that an agent consists of the agent framework and units. An operator can interacts with an agent via a user interface and manage the unit configuration by a command at any time. The behavior of an agent depends on the unit configuration. Generally, an agent receives given inputs and then calculates an output according to a given algorithm. Each agent is independent and prm cessed concurrently. But we define that unit functions of an agent are processed sequentially because of the simplification. The directed graph in Fig. 8 shows that the interrelation between the units. An agent invokes the unit functions in the user-defined sequence as the number in Fig. 8 indicates.

4

Dynamic reconfiguration

We present the method to implement the dynamic r e configuration. In our architecture, there are the two cases of the reconfiguration: the agent reconfiguration and the unit reconfiguration. The former is to reconfigure a system by changing the agent configuration. The latter is to reconfigure an agent by changing the unit configuration. The system reconfiguration means all the above. As mentioned in Section 3.2, an agent only invokes the unit functions, and there is no direct effect of the agent configuration on the system. An agent gives us the distributed computing environment. Therefore, a system behavior depends only on the unit configurations. Now, we discuss the problem regarding the dynamic reconfiguration. It is that the system guarantees the correct response of an autonomous robotic system at any time, especially during the dynamic reconfiguration. The correctness of the system behavior before the reconfiguration is responsible for an operator, who decides the system configuration. It applies to the correctness after the reconfiguration. However, it does not apply to the correctness during the reconfiguration because the operator cannot control it at runtime. For example, the process of the reconfiguration may preempt that of each agent. It means that the motion control of the robot is lost until the reconfiguration is completed. The system behavior cannot be guaranteed only by implementing the dynamic reconfiguration of the software. Therefore, we should design the architecture to prevent the process of the reconfiguration from interrupting that of each agent at least. The simple solution is to process the unit recon-

4062

Agent

Unit 1

Unit Data type A match

Unit X

Unit 2 Data rype B

Data 'ypc 8 ~

Unit 3

DatatypeC

Figure 5: Type checking between units

Figure 4 Communication between agents by using an interface unit

Uninilialized

P"ocesso

figuration in the background of the agents, that is, with a lower priority than theirs. The process of the reconfiguration is decomposed into the two stages as follows. 1. Calculate the new unit configuration from a com-

Figure 6: The state transition diagram of a unit

mand.

2. Switch to the new unit configuration from the old one. The first stage may take much time when the number of the involved units is large. Thus there must he such a process in the background. This is no problem as long as the new configuration is not replaced with the old one. On the other hand, in the second stage, an agent must modify the unit configuration by itself before the unit functions are invoked. In this case, there is no trouble because it takes very short time to switch it. In our architecture, the aforementioned s e lutions can he easily implemented. The reason is that an agent has the two threads and invokes the unit functions sequentially as described in Section 3.2. For instance, the task transition during the unit reconfiguration is shown in Fig. 9. It may take much time to complete the reconfiguration in the above method. However, the process of an agent is not interrupted and the latency derived from switching is very short. Thus we can ignore the side effect of the dynamic reconfiguration of the software.

5

Related work

The robot architecture from some aspects is discussed in 111. Here, we focus attention on particular types of the architecture that is targeted at robotic systems and has the dynamic reconfigurability. First, D. B. Stewart et al. propose the dynamically reconfigurable real-time software framework [3] that based on the Chimera Methodology [4] . The software framework is a spin-off of a project to develop reconfigurable robots. The methodology and the RTOS mechanisms necessary to realize it are described in [3]. The dynamic reconfiguration of distributed robot controllers is also shown. Moreover, T. Q. Pbam et al. present the self-adaptive control software systems [SI following the above research. It is based on a multi-agent model and also implemented mobile code by JavaTM. Second, OPEN-RTM, which is used for AIBOTM, SDR-3X[6], etc., is presented in 171. OPEN-RTM is the standard architecture and interface for a re-

4063

%gent

Execution of unit functions

0

= Unit

I

I

Figure 7 A block diagram of an agent framework

Figure 8: The unit configuration of an agent: the interconnection between the units and the sequence to invoke the unit functions

Modified configuration

,. .................

Former configuration

Priority

A

3..

......

I .

......

Time Figure 9: The task transition during t,he dynamic reconfiguration configurable robot platform. It employs AperiosT" (a.k.a. Apertos) as the embedded operating system. AperiosTMsupports dynamic updating of overall softw a e . But there is little detail information about it. Finally, S.Wang and K. G. Shin describe the reconfigurable software based on a Nested Finite State Machine[8] (NFSM) in [9]. The NFSM supports control logic reconfiguration at runtime and hierarchical composition of FSM's, which are the basic compe nents. The dynamic reconfiguration of the motion control system for a milling machine is demonstrated. The above researches refer to the software reconfiguration, but do not refer to the system behavior

while reconfiguring at runtime. As mentioned in Section 4, only implementing the software reconfiguration cannot guarantee the system behavior during the reconfiguration. It is necessary to control the system behavior at that time. And so, this paper presents the method to solve the above problem. There are the other recent studies on the robot architecture as follows: BeNet[lO], Plugin architecture[ll] and PredN[l2]. But either study does not refer to the dynamic reconfigurability.

4064

6

Conclusions

We proposed the layered multi agent architecture with dynamic reconfigurability. Our architecture is based on the multi-agent model, which is suitable to model dynamically reconfigurable software. A unit, which is a simple and small component of a n agent, was defined since an agent is sophisticated. Thus our architecture consists of an agent framework and units, and combines openness with a layer structure. We presented the underlying compntational model. In our architecture, the roles of a unit and an agent are explicitly distinguished. A unit is a dynamically reconfigurable component to provide a function, and an agent sets up the distributed computing environment. Each agent only invokes the unit function sequentially. This policy facilitates analyzing the behavior of overall system and implementing the dynamic reconfiguration. We discussed a system behavior during the dynamic reconfiguration. It is insufficient to implement the dynamic reconfiguration of the software in regard to guarantee the system behavior a t any time. The reason is that the process of the reconfiguration may disturb the system behavior unless there is a particular mechanism to avoid such a situation. Thus we decomposed the process of the reconfiguration into the two stages. The new configuration is calculated in the background of agents, and an agent switches to the new one not while processing but before doing it. As remarked above, the proposed architecture in this paper targets at autonomous robots, supports the dynamic reconfiguration, and guarantees the system behavior even during the reconfiguration. Now we apply this architecture to the software system of a humanoid robot.

References [I] Eve Coste-Manibre and Reid Simmons: Architecture, the Backbone of Robotic Systems, Proceedings of the ZOO0 IEEE International Conference on Robotics and Automation, pp. 67-72, 2000. [2] Michael Wooldridge and Nicholas R. Jennings: Pitfalls of Agent-Oriented Development, Proceedings of the 2nd International Conference on Autonomous Agents, pp. 385-391, 1998. [3] David B. Stewart, Richard A. Volpe, and Pradeep K. Khosla: Design of Dynamically Reconfigurable Real-Time Software Using Portbased Objects. IEEE Transactions on Software Engineering, Vol. 23, No. 12, pp. 759-776, 1997.

4065

David B. Stewart and Pradeep K. Khosla: The Chimera Methodo1ogy:Designing Dynamically Reconfigurable and Reusable Real-Time Software Using Port-based Objects. International Journal of Software Engineering and Knowledge Engineering, Vol. 6, No. 2, pp. 249-277, 1996. Theodore Q. Pham, Kevin R. Dixon, Jonathan R. Jackson, and Pradeep K. Khosla: Software Systems Facilitating Self-Adaptive Control Software,

Proceedings of the 2000 IEEE/RSJ International Conference on Intelligent Robots and Systems, pp. 1094-1100, 2000. Tatsuzo Ishida, Yoshihiro Kuroki, Jinichi Yamaguchi, Masahiro Fujita, and Toshi T. Doi, Motion Entertainment by a Small Humanoid Robot Based on OPEN-R. Proceedings of the 2001

IEEE/RSJ International Conference on Intelligent Robots and Systems, pp. 1079-1086, 2001. Masahiro Fbjita, Hiroaki Kitano, and Koji Kageyama: A reconfignrable robot platform, Robotics and Autonomous Systems, Vol. 29, pp. 199-132, 1999. Orest Storoshchuk, Shige Wang, and Kang G. Shin: Modelling Manufacturing Control Software, Proceedings of the 2001 IEEE hternational Conference on Robotics and Automation, pp. 4072-4077, 2001. Shige Wang and Kang G. Shin: Reconfigurable Software for Open Architecture Controller, Proceedings of the 2001 IEEE International Conference on Robotics and Automation, pp. 4090-4095,

2001. Tetsushi Oka, Junya Tashiro, and Kunikatsu T a k e : Object-Oriented BeNet Programming for Data-Focused Bottom-Up Design of Autononious Agents. Robotics and Autonomous Systems, Vol. 28, pp. 127-138, 1999. Fumio Kanehiro, Masayuki Inaba, and Hirochika Inoue: Developmental Software Environment that is applicable to Small-Size Humanoids and Life-size Humanoids. Proceedings of the 2001

IEEE International Conference on Robotics and Automation, pp. 4084-4089, 2001. Oliver Stasse and Tasuo Knniyoshi: PredN : Achiving efficiency and code re-usability in a programming syst.em for complex robotic applications. Proceedings of the 2000 IEEE International Conference on Robotics and Automation, pp. 8187, 2000.

Suggest Documents