like C++ or Common Lisp for describing various sys- tems because it was developed for designing a network of simpler and speci c units (AFSM's)[4]. In BL you.
Programming Environments for Developing Real Time Autonomous Agents based on a Functional Module Network Model 3
T.Oka
3
M.Inaba
+
Graduate School of Information Systems Univ. of Electro-Communications Chofu-shi, Tokyo
In this papaer, we present programming environments for developing real time autonomous agents on multi-processor systems based on a hardware independent description model. BeNet, our model is a network of functional modules that calculate elements of the internal representation of the brain with their own frequencies. A system that interacts with the physical world is modeled almost completely by a BeNet, because it consists of modules which interact with the external system at regular intervals. It is described much more easily than a common parallel program and its behavior is easy to understand. Since it is a parallel system and the description is not speci c to any hardware, it is possible to realize environments for programming BeNets on various multi-processor systems. We implemented environments in which the developer can program a BeNet in a generic programming language such as C++ and test it immediately on a multi-processor system. In our environments, the developer only needs to describe components as sequential programs, determine their intervals and connect the components in a simpli ed way and observe the behavior of the described system. The proposed environments will be of great bene t to designers and researchers of autonomous robots and real time agents.
1 Introduction
The behavior of an autonomous agent emerges from the dynamics of the brain and its environment. The developer of an agent must describe the brain that shows a desirable interaction with the dynamical environment. In order to verify the described agent, it is inevitable to realize the system with some physical apparatus and observe its behavior in the real world. Therefore, the designer has to repeat test and modi cation cycles and an environment for repeating such cycles in a short term is necessary. A programming environment on a multi-processor system can be a powerful tool for developing an autonomous agent, because it must be reactive and it needs a massive computation power. On such an environment, you usually can describe the system as a
+ Dpt.
of Mechano-Informatics Univ. of Tokyo
182
Abstract
+
H.Inoue
Bunkyo-ku, Tokyo
113
program and test it immediately. However, it is not easy to write a program of a multi-processor system that interacts desirably with a dynamic environment in a generic form. In this paper, we propose a functional module network model for describing a desirable real time autonomous agent completely in a hardware independent manner. BeNet, our model is suitable for various multiprocessor systems and it is possible to realize environments to describe a modular brain out of components designed independently and test it immediately. We realized environments for developing agents and robot brains based on BeNet description in generic programming languages. In these environments, it is easy to program and develop autonomous system. The model, the environments and an example for desingning are presented. 2
Describing an Autonmous Agent
The brain of an autonomous agent is a system that interacts with the dynamic physical environment. As the brain itself is also a dynamical system with external input and output, the description of it should include temporal constants to determine its behavior completely. If you develop an autonomous robot, you need to describe a brain completely that behaves desirably interacting with the real world. A computer program is a kind of system description. A system is realized by a computer that execute a program described by a programmer. If the program is written in a generic language, it may be executed by various computers. However, the behavior of a computer that is executing it is not described completely by the program itself, because it also depends on the hardware. Especially for a robot brain, the di erence of timing of execution has a great in uence on its behavior, because it interacts with the physical world. If the system is described as a parallel program, it is more complicated. In order to guarantee its completeness and correctness, the description will often be speci c to the computer that executes the program. In general, such a hardware speci c program is intricate, far from portable and hard to understand.
The best way to solve this problem is to divide the system description into speci c and non-speci c parts. Usually, the designer has to describe both the speci c and the non-speci c part. However, if the non-speci c part represents the behavior of the system completely, the hardware speci c part will be independent of the described system. Therefore, it is possible to realize an environment in which the designer only needs to describe the non-speci c part, by preparing all the necessary hardware speci c programs in advance. 3 Related Works
Rosenschein proposed to describe an embedded autonomous agent in terms of declarative expressions about the environment and the agent[10]. Such expressions are analyzed and compiled to generate a digital circuit that behaves as an autonomous agent interacting reactively with the environment. If the expressions include information for selecting an appropriate action in each situation the agent faces, the compiler can generate a reactive agent that behaves desirably in the environment. However, this approach has diculties when you apply it for designing autonomous robot brains that react with the physical world through real sensors and motors. One reason is that the dynamics of the physical world with which autonomous robot brains interact is too complex to describe completely (especially in a declarative way). It is dicult to describe a desirable dynamical system completely in this approach. Another is that it is often not appropriate to realize a functional module as a combination circuit. Brooks' BL(the Behavior Language[1][2]) is a language for describing systems that react to the real world. In BL, a system is described as a set of parallel processes. BL is not as powerful as generic languages like C++ or Common Lisp for describing various systems because it was developed for designing a network of simpler and speci c units (AFSM's)[4]. In BL you cannot de ne a function or complex data structures like ordinary programming languages. Therefore the developing environment in BL lacks a variety of describable systems. Furthermore, the BL programing environment was not based on an appropriate computational model for dynamical system. A network of AFSM's is a network of processes that often synchronize or communicate with the external system at an arbitary timing. In general, the behavior of such a network depends on the time to take for the calculation. Chapman's essential connectionist approach[6] has a similar drawback because the described system is a network of speci c units of limited size and structure. Brooks has developed a new environment for developing real time embedded control systems. In this environment, they describe systems in a language called L[3][5]. L is a downwardly compatible subset of Common Lisp with multiple-processing extension. Since L contains all of the main functionality of Common Lisp, it is much easier to describe a desirable system in L
than in BL. The L system supports parallel processing by regularly scheduled lightweight processes that share the Lisp heap. A language called MARS is built on top of L. In MARS, they can describe asynchronous parallel processes that communicate through bi-directional ports in a simpli ed manner. However, in this environment, you cannot describe a dynamical system completely in a simpli ed manner, because it is not based on an appropriate computational model. In our environments based on the BeNet model, the designer gives a hardware independent and complete description of a real time autonomous agent described in a generic programming language and the described system is simulated in real time by a parallel computer. As the BeNet model gives some constraints and the description is not speci c to any implementations, the description of a BeNet is simpler than a system description in MARS, but the variety of describable systems as autonmous agents is still sucient. In our environments, a description of a BeNet is more explicit and clearer than a system description in BL, and you can test systems of a broader range. 4
BeNet:a Model for Real Time Agent
4.1 Real Time Augmented Automaton
Before mentioning the BeNet model, we begin with showing the simplest model for describing an autonomous agent completely. Every system that interacts with the external system is described completely as a Real Time Augmented Automaton(RTAA) de ned below. ( ) = F (S (t 0 1t); I (t 0 1t))
(1)
( ) = F (S (t 0 1t); I (t 0 1t))
(2)
o
O t
s
S t
where O(t), I(t) and S(t) denote the output vector, the input vector and the internal state vector, respectively (see Fig.1). An RTAA reads the input and changes the state and output every 1t. The behavior is determined by F , F and 1t. Therefore, an autonomous agent is described completely as an RTAA. Note that 1t should be small enough in comparison with the changing rate of the external system both for completeness of the description and desirability of the behavior. The described agent can be realized by a hardware that calculates F (S(t); I (t)) and F (S(t); I (t)) every time step 1t. For example, a computer that calculates F and F in an in nite loop every 1t behaves like the described agent. The functions F and F can be described as a sequential program. Therefore, a pair of a sequential program and a description of interval 1t gives a complete description for an agent. o
o
s
s
s
o
s
o
External System
System I(t) &$#t
Fs Fo
system input
O(t) system output
S(t) internal memory
Figure 1: Real Time Augmented Automaton 4.2 Internal Representation and Network of Functional Modules S(t), the state vector of an agent or an RTAA is regarded as its internal representation. For a complete description, the designer should at least determine the size of S (t) and how to calculate each element of it at every time step. For a desirable behavior, it is necessary that S (t) includes useful information about the current state of the environment and the agent, that is not available directly from I (t). The designer should give a meaning to an element or a group of elements in order to design a desirable system. And the element(s) should always represent the intended information correctly. The designer describes how to calculate each element of S(t) from the given information I (t 0 1t) and S(t 0 1t). The value of the ith element S (t) is calculated by the following expression. S (t) = F (S (t 0 1t); I (t 0 1t)) (3) Note that not all the elements of the vectors S and I are necessary for the calculation and that it is not always necessary to update the value of S (t) every 1t. For this reason, the system may be described as a network of functional modules that calculate their own part of S (t) from their own input which consists of a part S (t) and I (t). There could be elements that are only necessary for the module that calculate them. Since such an element is written and read only by a single module, it is a internal state variable of the module. The other elements are calculated by a module and referred by other modules. Each module may have its own frequency of calculation. Consequently, every agent is completely described as a network of such functional modules that calculate a part of the internal representation with their own frequencies.
has an input vector i(t), a state vector s(t) and an output vector o(t). An element of i(t) is an element of either the input I (t) or the state S(t) of the agent. An element of s(t) is an element of S(t). An element of o(t) is an element of either S (t) or O(t). The value of the ith element of the state(output) vector of the kth BU at the time t is calculated as follows. s (t) = F (i (t 0 t ); s (t 0 t )) (4) o (t) = G (i (t 0 t ); s (t 0 t )) (5) Since the BU's in a BeNet run asynchronously with their own frequency, the behavior is not strictly the same as an RTAA that calculate S(t) and O(t) every 1t. However, the BeNet description is almost complete, because each BU is described completely with its functions and frequency. This means that the constraint on programming a parallel system as a BeNet is not too strong for an autonomous agent. The BeNet description includes additional information about the grouping of the calculation so that the system is simulated by a direct parallel processing. On the other hand a BeNet is easier to describe than a general parallel system. k i
k i
k
k
k
k
k i
k i
k
k
k
k
System &D#t#2 &D#t#4
I(t)
2
4
1 3
6
S(t)
i
i
O(t)
5
s i
BeNet 2
4
1
5 3
6
i
4.3 the BeNet Model
A BeNet is a network of asynchronous RTAA's called Behavior Units(BU's) that change their state and output with their own frequencies f (= 1=t ). Each BU k
k
i(t)
o(t) BU
F,G
&D#t
s(t)
Figure 2: describing a system as a BeNet 4.4 Merits of BeNet Programming for Autonmous Agents
A BeNet is easy to extend or modify, because it is a network of functional modules, of which the roles in the system are stipulated by the designer. A BU is a component of which the dynamics is determined by the two functions and the interval, t . The developer can design a BU independently, since the meanings of its input, output and state vectors are stipulated by the k
very developer. A BeNet can be simulated directly in parallel and it is not dicult to build an environment for programming BeNets in an appropriate language on a multi-processor system. And the most signi cant feature is that a BeNet description represents almost competely a system that interacts with the physical world. In theory, you can describe every dynamical system as a BeNet non-speci c to any hardware. 5 Programming BeNets
A BU is de ned by the interval t and two functions that map vectors, s (t 0 t ) and i (t 0 t ) into s (t) and o (t). These functions can be described by a sequential program of any generic programming language. If the functions are calculated within t and the interval is kept t by a computer, the described BU is realized in the physical world. A BU is simulated in the following manner. 1. receive the input vector 2. calculate the state vector and the output vector 3. send the output vector 4. adjust time 5. go to 1 The description speci c to a particular BU is 2 and the interval that is necessary to adjust time at 4. The other part of the program describes procedures that is not speci c to the BU. Therefore, a BU is described by a sequential calculation program and a simple binding of a variable. If the other part of the program is already written, the designer only needs writing the speci c part. For example, a simple BU is described completely by the following forms in Lisp. k
k
k
Autonomous agents can be described more eciently in an object oriented programming language. The input vector, the output vector, the length of interval, and information about the network con guration can also be kept in slots of a instance of a pre-de ned or user-de ned class and be changed or accessed by their methods(member functions). The programs are more readable and understandable. 5.3 Con guring a BeNet
5.1 Programming a BU
k
5.2 Object Oriented BeNet Programming
k
k
k
k
k
(defbehaviorunit bu1 1 1 2 (let ((x (get-input bu1 0)) (y (get-state bu1 0)) (z (get-state bu1 1))) (set-output bu1 0 (+ x y z)) (set-state bu1 0 (/ z 2)) (set-state bu1 1 (* x 2)) (set-result bu1 0 t))) (set-cycle bu1 10) (definitialize initbu1 bu1 (set-input bu1 0 0) (set-state bu1 0 1) (set-state bu1 1 1))
The form that begins with defbehaviorunit is describing bu1's functions F 1 and G1 . bu1 has one input, one output and two state variables. The initial values of the input and the state vector are described in the form that begins with de nitialize. The interval of the calculation of bu1 is de ned by set-cycle. set-cycle may be called in de nitialize or defbehaviorunit.
A BeNet is simply described as a network of BU's. There are two ways for de ning the network con guration. One is to connect an element of output vector of a BU directly to an element of input vector of another BU. The other is to connect all the elements of the input and output vector to the elements S(t). For example, the network con guration of a BeNet is described as below. (defmessage *mes1*) (defmessage *mes2*) (defmessage *mes3*) ... (defoutlist bu0 *mes1* *mes2* *mes6*) (defoutprio bu0 2 2 3) (definlist bu0 *mes4* *mes5* *mes7*) (defoutlist bu1 *mes3* *mes4* *mes5* *mes6*) (defoutprio bu1 1 1 1 1) (definlist bu1 *mes1* *mes2* *mes7*) ...
The messages(*mes1*, *mes2*,...) are elements of S(t) that are passed among the BU's(bu0, bu1,...). bu1's output elements, o11 (t), o12 (t) are connected to bu0's input elements, i12 (t), i13 (t), via *mes4* and *mes5*. Both bu0 and bu1 send messages to port *mes6*. If the two BU's send messages simultaneously, bu0's message will be the value of *mes6*, because bu0 has higher priority value 3 for *mes6* than bu1's priority value 1. Messages on *mes7* are sent to bu0 and bu1. The BeNet described above is shown in Fig.3. (A circle with an alphabet p is a node for arbitration.) The description of the network con guration is also non-speci c to the hardware that actualize the BeNet. *mes7*
bu0 *mes4*
*mes1*
*mes2*
*mes5* 3
*mes6*
1
p
2
bu1 *mes3*
Figure 3: Described BeNet
6 BeNet Programming Environments
6.1 Implementation on Transputer for Real Robots
We implemented a programming environment that enables real time simulation of BeNets on transputer networks. This environment is called BNRB/tp(BNRB stands for BeNet for Robot Brain). In BNRB/tp, the designer describes BU's in C and the network con guration in a C-like con guration language [11]. The programs written by the designer are linked with the system programs along with additional information on the hardware. The system program for the part of program speci c to BNRB/tp is written in C. Everything for process generation, communication, interval control is done within this program. The running interval of each BU is controlled by the local timer by 64sec. Asynchronous communication among BU's are realized using channels and bu er processes. A BU process tries to send the output vector to the output bu er processes in every cycle and receive the input vector from the input bu er processes. Since process switching and scheduling is done by hardware, context switching is executed within 1sec and a processor can simulate dozens of BU's that runs in milliseconds' cycle in real time. Each BU runs on its own memory space including its code, stack and heap. Programming a BU in C, the designer can utilize various library functions for image processing, motor control, planning or user interface. Using remote-brain interface[7][8] to sensors and motors of a remote real robot, we can test the behavior of a described BeNet immediately in the real world. We have built a brain for autonomous ballboy robot as a BeNet with a real time vision system, a hierarchical motion control system and a reactive decision making system[9]. 6.2 Implementations on Solaris 2.X
After developing BNRB/tp, we implemented environments for BeNet programming on Solaris 2.X using multithread library[12](BNRB/mt). In these environments you can simulate a BeNet on multi-processors making use of various software resources of Solaris 2.X. We also developed a lightweight interface between BNRB/mt and BNRB/tp, that enables us to build a BeNet that runs over a workstation and a transputer network. The system program for the rst BNRB/mt was written in C and it enables the designer to program a BeNet in C like in BNRB/tp. In BNRB/tp and BNRB/mt the designer can make use of the same BU program described in C. Afterwards, we rewrote the system program in C++ using class de nitions. In this environment, the designer can de ne classes of C++ to describe the internal representation s (t) as slot variables and the functions F and G with member functions of the classes. The system program does everything for thread creation, communication, scheduling and interval control. The messages are realized as static k
k
k
global variables in the shared memory space, and they are accessed exclusively (with mutex locks) by threads for BU's. Scheduling and interval control are done by our system program together with the kernel. A BU is dispatched to an available processor on run time by the kernel. In BNRB/mt, the designer only needs nonspeci c description of a BeNet: functions F and G , interval t and the con guration. k
k
k
6.3 Simulator in Common Lisp
We also realized an environment to simulate a BeNet written in Common Lisp. The system program is written with class de nition of CLOS, macros and functions of Common Lisp. Although our environment cannot simulate a BeNet in real time, we can verify the behavior of a reactive and modular system interacting with the external system. In this environment, BNS/cl, as all the BU's share the heap space, it is possible to pass symbols or lists as messages. However, it seems to be better to limit the data type of a message and prohibit sharing global variables for modularity and ease of description, taking a parallel implementation into account. 7
An Example of Real Time Agents
In this section, we show a simple autonomous agent that can communicate with a human. The agent is described in C++ completely as a BeNet made up of 5 BU's. The agent has a virtual body in the X Window system, an eye, a mouth, a mouse and a keyboard. It is simulated by a Sun SS20 and a transputer network. The video image from the camera is processed by two transputers with image memory at video rate. The agent can detect the existence and the motion of a human and send messages to him. The agent has memory of its experience, observes the external world and says \hello", " how do you do", "it is a long time since I met you" and so on to the user of the computer . Since the BeNet does not synchronize with the external world at all, the agent can behave autonomously without waiting for a message from a human and do urgent tasks if necessary. Being described in C++ using abstract data type de ned by the designer, the system is understandable and easy to modify or extend to realize a more complex agent. The description of the agent as a BeNet is not speci c to our computers. In the BL or L environments, you cannot describe the agent completely in this simple way, because they are not based on BeNet model. The main function of the BU greeting in Fig.4 is as follows. In BL, you cannot de ne functions or abstract data types like in this code. void rule_greeting(BehaviorUnit &bu,Greeting &grt) { int NEvent,Action,Message,Snap; int x,y,i;
int WordMess1[WORDMESSAGESIZE]; int WordMess2[WORDMESSAGESIZE2]; int KeyMess[KEYMESSAGESIZE]; char *km = (char *)KeyMess; NEvent = bu.get_reg(GREETING_EVENT); if(bu.get_newdata_nw(0) == NEW) { bu.copy_from_nwordreg(KeyMess,0); NEvent = EV_MESARRIVAL; cout
