University of Wales, Bangor, North Wales, LL57 1UT, UK. {hawick,heath}@bangor.ac. ... sign is a custom one with optimisations and design specific aspects that ...
Technical Report DHPC-123
Software Architecture and Programming Issues for Distributed Robots K.A.Hawick, H.A.James, R.G.Shepherd and J.E.Story Computer Science Division, School of Informatics University of Wales, Bangor, North Wales, LL57 1UT, UK {hawick,heath}@bangor.ac.uk Tel: +44 1248 38 2717, Fax: +44 1248 36 1429 Middleware is the software that typically sits between applications and the operating system in distributed computing systems. As robotics components become more sophisticated and more commodity priced many of the difficult but interesting problems in programming robotic behaviour can be located in a smart middleware. We discuss middleware programming models and issues for supporting distributed robots and our prototype software architecture which uses a multi threaded message oriented structure. We also discuss the fusion of non conventional robotics programming languages and environments such as that of Java, together with conventional AI languages such as Prolog. Keywords: software architecture; programming models; distributed robots; mobile computing; wireless communications.
1
Introduction
We have experimented with relatively cheap robot systems that can operate as part of a cooperating swarm [8]. This work has led us into considering scalable software architectures that can allow interoperability of software modules and support investigations into higher level behaviour and smart systems programming.
Advances in the technology and commodity pricing of microcontrollers and other electronics necessary for building robots has led to greater levels of activity and high expectations of what robots can do. We believe that a significant obstacle for further development is lack of standard architectures and modular interface designs for robot intelligence software. When computational resources are scarce or expensive it is understandable that each robot design is a custom one with optimisations and design specific aspects that make it difficult to share software developments. However we believe this situation is changing and that plentiful cheap (lightweight and low power consuming) control computer technology will be available for embedding in robots and that therefore it is timely to explore what software can be standardised and shared. There is still controversy about the high level artificial intelligence implementation approaches needed for smart mobile robot [2, 14, 15]. It is likely that there is still scope for a lot of research at that level of programming robots. At the low level, individual designs will continue to need special purpose drivers and control elements. We propose that there may be a common middle ground whereby a useful middleware layer can be investigated and which may find a role in integrating high level AI aspects to different hardware systems.
so it is interesting to consider an agent component model where the whole swarm or group of cooperating robots are somehow cross linked at the middleware layer so that interoperating services are available to as yet unwritten higher layers of control and behaviour specification. In section 2 we describe our high level vision for an agent component based model of cooperating services that constitutes a distributed robots middleware. In section 3 we describe some of the advantages and features of using a software glue such as Java for building such as a system and in section 4 we describe the issues in implementing a middleware and the status of our prototype. We are working on various tools and technologies for implementing trial experiments in higher intelligence and behavioural layers that can make use of our middleware services. In section 5 we consider the implications of fusing Java with an AI environment such as Prolog to allow experiments in policy control for specifying high level behaviours. Although the platform we are working on at present supports a relatively small Java Virtual Machine environment, we believe that our approach will find fruit in the small and lightweight full PCs that will be a valuable part of next generation robots.
Figure 1 shows this vision with a software stack of: primitives; then compound commands; and finally some as yet-to-be-specified higher level brain determining behaviours and goals. It may be that this naive vision is incomplete as drawn with an unspecified feedback mechanism between layers. It is still unclear how much learning from and access to the low level drivers the high level behaviour control aspects of a smart system really need. High Level Brain − Behaviours and Goals
Feedback ?
Medium Level Brain − Compounded Commands Low Level Brain Command Primitives Drive Layer Sensors
Communications Layer Wireless Antennae
Actuators
Figure 1: Software Stack model for layers of behavioural control Nevertheless, In this paper we describe our ideas for a smart middleware layer that can support other higher level behaviour control systems and which can form an agent based software infrastructure for experiments with robot systems. 5 4
2
1
15
14
2
13 9
8 10
Figure 3 illustrates our concept for a smart middleware that is capable of supporting behavioural control and higher level intelligence programs for a swarm of cooperating robots. We suspect the model is useful in its own right for implementing an agent based approach to programming even a single smart system. A maritime metaphor is used to denote some sort of hierarchical relationship amongst agent components. The figure is drawn without specific messages or relationships for simplicity. The model can be implemented in a number of different ways with either separate threads of control given to each component and thread scheduling management carried out by the Arbitrator, or alternatively different threads of control can be instantiated for specific tasks as launched from
16 17 11
7
Drive Layer Sensors
Actuators
Middleware Agent Model
3
6
12
Communications Layer Wireless Antennae
Figure 2: A cooperating society of agents each providing services to one another but having their own individual missions. This idea is shown in figure 2 where we envisage an alternative structure where a collection of cooperating agents are charged with separate tasks or missions and which act as peers of one another, temporarily acting in client-server relationships. We are particularly interested in distributed robots 2
Admiral of the Fleet Purser Resource Manager
Messenger Sparks Wireless Communications
Auditor Logs
well defined tasks, and can be set up in a process style model to respond to their inputs. The specific labelling of the agents in this model breaks down the responsibilities of a mobile robot control system considerably and allows experiment with specific implementations. It is possible to employ override ideas such as those of Brooks [1] by interposing extra interaction channels between agents. This model can be implemented using a visual environment such as Matlab, but our interest is in developing robust and scalable software components and the exchange protocols that allow different implementations to interoperate. We discuss implementation technologies in the remainder of this paper.
Skipper Special orders Standing Orders Helm Control Safety Procedures Arbitrator Priority rulebook Navigator Full or partial World Map
Mission Specialist Crane Hold Ram Weapons
Engineer Motors Look out Proximity Sensors
Figure 3: Agent based architectures for cooperating software components of a swarm node.
3 the Skipper. We employ a separate Admiral object although in a swarm or robots this might in fact just be one of the Skipper objects that has been designated the leader. The Messenger component acts as a broker for all inter agent traffic and can be interfaced to one of the operations of the Auditor agent whose job it is to log all transactions and messages for debugging or diagnostics purposes. Some objects have specific resources they control or guard such as the Engineer controlling the motors, which it will operate under the direction of the Helmsman. An interesting issue is how much and in what way can the navigator agent maintain a world map and to what extent it is useful. An alternate model requires a close coupling directly between the Lookout and the Helmsman. If a high level navigational goal has been set by the Skipper then it may be sufficient for the Navigator and Helmsman to implement it by trial and error, as it were. We have denoted other specialist resource managers by the Purser, Mission Specialist and Sparks. These may guard or control their own specialist resources or sensors directly and operate them or impart knowledge gleaned from them on request from another agent. Individual agents in this model can be given fairly
Java Software Glue
We have made use of Java components for distributed computing middleware for computational grid systems. A grid environment typically involves middleware of some description to enable sharing of resources such as expensive supercomputers or large capacity storage systems. We have employed the grid idea for implementing shared access to and exchange of services. This model lends itself well to both mobile computing [7] and distributed robotics control [6]. Java supports a mature and easy to use networking package with both TCP and UDP capabilities. We developed a lightweight message passing control system (know as Java Universal Message Passing JUMP) [13] using Java and which we have deployed on embedded control devices. The Messenger component in our architecture is based on our JUMP system. At present we are working with IEEE802.11b wireless ethernet communications devices and these operate directly using the existing IP stack available from Java. No special interfaces are needed. We are, however, having to develop our own interface specifications to work with Bluetooth wireless development modules. We anticipate these soon becoming supported widely by Java however. The object model that is at the very heart of Java is also useful for developing a component based mid3
4
dleware. We found the object serialisation and classloader and introspection features useful in developing our distributed computing middleware environment DISCWorld. Unfortunately these features are not always available in the KVM Java Virtual machines supported on embedded devices such as the Tini board that we used in our swarm robot. We expect this is a temporary problem as either we will use more powerful full PC type computers in the future and they will support full specification JVMs or full JVMs may well become available for embedded devices.
Middleware Implementation
The architecture shown in figure 3 can be implemented as a multi-threaded daemon. Some care is necessary to ensure appropriate fair scheduling of process time is given to threads since the Java Virtual Machine model does not guarantee any particular thread scheduling model be implemented for portability reasons. This can be done with appropriate care however using appropriate buffering and thread yielding models [12]. As discussed in section 3 the model has much in common with middleware for computational grids. Some issues in common with grids we have not properly addressed include those of security and global naming. We assume for now that in the confines of as closed environment that external influences are limited and object encryption and signature techniques are not necessary. Likewise we assume that no randomly imported objects are in use and so naming issues are not as severe as for a global grid. Although we believe these assumptions are adequate for now, it is likely that distributed robotics systems will go online and may be controlled using tele-operations across the Internet/grid or may interact with information sources and resources on the Internet. Our prototype architecture suggestion may therefore need to be “grid-proofed” in the near future. In this paper we have not described in detail all the implementation technologies that might be used to implement particular service agents. Instead we have concentrated on the middleware infrastructure and architecture issues. We have focussed on the advantages of using a Java based environment. This is not the only choice and we believe it is possible to implement our architecture design using a CORBA ORB based approach. It is likely that the interservice protocols may be more important than the agent implementation details. Another key consideration in the design and implementation of our robotics control middleware is the way in which invididual robots will be customised and given high-level instructions. We seek a method with which we can tell a robot, for example, “today you are the Navigator”, or “the robot who today is the
In the early days of deployable Java Virtual Machines, embedded devices did not generally have enough memory to run very large Java programs. This is changing with the latest version of the Tini board having 1 MByte of available memory and we expect the use of Flash memory cards and other commodity priced storage units will mean that this is no longer an obstacle to using Java widely for control systems software. In general we do not wish to have to develop new interfaces or protocols but in cases where this is necessary Java lends itself well to this work. We developed an XML based job specification protocol for our DISCWorld system [9]. We are presently working on a similar XML based cooperation protocol for our cooperating agents. One area for which pure Java is not well suited is that of real time scheduling and control. The Java Virtual Machine typically involves running a garbage collector thread that will tidy up memory and remove unreferenced objects. The Java specification does not guarantee any exact schedule for this activity and it is generally necessary to disable the collector and run it manually as on the Tini system or to devise some other means of guaranteeing performance. For development purposes we are not addressing this problem in our present middleware prototype but may need to incorporate an underpinning small real time operating systems component at or near the device driver level of our architecture. 4
Skipper also has knowledge that it learnt yesterday as the Engineer; if it requests Engineering information, give it verbose information instead of terse information”. We are also seeking a way in which we can implement what we call active preferences. Active preferences are the merger of normal static preference information, such as “when I am in a meeting I do not wish to receive telephone calls” with temporal and locality-based information; thus we add a new degree of autonomy into the system by allowing a software manager to decide whether I should be made aware of certain events. For example, in our robotics control middleware, one initial active perference may be Lookout may only be allowed to send messages to other entities that have registered an interest, except when there is an emergency or a target has been found.
bility.
5
6
Nevertheless, using a Java-based prolog engine allows us to have all the basic communications mechanisms implemented in Java, which does not tie us to a particular architecture, but also allows us to specify our policies and goals in a higher level that we could using Java only. In our current system we represent all policy information in a portable XML-based format, which can be stored in a textual database and also exchanged easily between software components. We are currently investigating an appropriate grammar with which we can write specific, yet generalisable policies to describe the behaviour of the individual robotic components.
Java and Prolog
The artifical intelligence community has for a long time used reasoning engines such as the Prolog engine for the emulation of artificial intelligence. Using this type is possible to construct predicates (known truths) and to be able to pose queries to the engine. The engine searches through its known fact database and, sometimes using inference engines (amongst others), gives the result(s) of the query. Unfortunately the use of such systems have not been widespread by researchers in other disciplines due to the difficulties in getting information into and out of the systems, and due to their lack of features that make other systems, like Java, appealing. We have implemented our policy manager using a Java-based prolog engine, such as JIProlog [3]. Programs like these provide us with the features of the Java language that have made it very popular: architecture-independent byte-code, threading, socket communications, an advanced GUI facility and distributed computing basics, and the powerful Prolog reasoning engine implemented in Java. One of the disadvantages to these programs is that they often do not implement the full Prolog specification; worse still, they often add their own constraints and requirements that forces programs to lose their porta-
Discussion and Conclusions
We have discussed our ideas for an agent component based middleware that will support experiments in behaviour specification in distributed robot systems. Our model can be implemented as a process model simulation in an environment such as Matlab but also lends itself to a deployable implemention using Java running directly on embedded hardware control systems. We have discussed some of the relative advantages (portability, easy exploitation of existing network and threading software) of using a Java based environment and some of the disadvantages (difficulties in controlling garbage collection and thread scheduling). We have outlined some recent ideas for fusing together Java with AI language systems to provide a high level mechanisms for specifying behavioural control policies. We intend to further devlop the inter agent cooperation protocols and to experiment with adding additional higher level cooperating agents to our middleware architecture. We believe this approach has some promise particularly if common inter agent protocols and interface specifications emerge. 5
Acknowledgements
[9] Heath A. James. “Scheduling in Metacomputing Systems,” PhD Thesis, Department of Computer Science, The University of Adelaide, 1999.
The Distributed and High Performance Computing Group is a collaborative venture between the University of Wales, Bangor and the University of Adelaide [10] Andrew H. Jones, Guilherme Nelson DeSouza and Avinash C. Kak, “A Multi-processing Softin South Australia. ware Infrastructure for Robotic Systems”, Proc 2001 IEEE Int Conf on Robotics and AutomaReferences tion, Seoul, Korea, May 21-26 2001.
[1] Rodney A. Brooks, “Cambrian Intelligence - The [11] Joseph L. Jones, Anita M. Flynn, Bruce A. Sieger, “Mobile Robots - Inspiration to ImpleEarly History of the New AI”, MIT Press 1999, mentation”, Pub A.K.Peters Ltd, 1999, ISBN ISBN 0-262-02468-3. 1-56881-097-0. [2] Rodney A. Brooks, “Robot - The Future of Flesh and Machines”, Pub Allen Lane The Penguin [12] Doug Lea, “Concurrent Programming in Java”, Addison-Wesley Longman, 1999. Press 2002, ISBN 0-713-995-017. [3] Ugo Chirico. Java Internet Prolog. Available [13] J.A. Mathew, H.A. James and K.A. Hawick, “Development Routes for Message Passing Parfrom http://www.egosweb.com/jiprolog Last allelism in Java,” Proc. ACM 2000 Java Grande visited September 2002. Conference, San Francisco, June 2000, pp 54-61. [4] Ian Foster and Carl Kesselman, eds, The Grid: Blueprint for a New Computing Infrastructure, [14] Hans Moravec “Robot - Mere Machine to Transcendent Mind”, Oxford Univ Press, 1999, ISBN Morgan Kaufmann Publishers, Inc., 1999. ISBN 0-19-513630-6. 1-55860-475-8. [5] K.A. Hawick, H.A. James, A.J. Silis, [15] Manfred Spitzer, “The Mind Within the Net Models of Learning, Thinking and Acting”, MIT D.A. Grove, K.E. Kerry, J.A. Mathew, Press 1999, ISBN 0-262-19406-6. P. D. Coddington, C.J. Patten, J.F. Hercus, and F.A. Vaughan, “DISCWorld: An Environment for Service-Based Metacomputing,” Future Generation Computing Systems (FGCS), 15:623–635, 1999. [6] K.A.Hawick, H.A.James, R.G.Shepherd and J.E.Story, “Distributed Computing for Robotics”, University of Wales, Bangor, Technical Note, DHPC-114, August 2002. [7] K.A. Hawick and H.A. James, “Middleware for Wireless Sensors and Robots”, Submitted to IEEE Int Conf on Wireless Communications and Networks (WCNC 2003). [8] K.A. Hawick, H.A. James, J.E. Story and R.G. Shepherd, “An Architecture for Swarm Robots”, Submitted to IEEE Int Conf on Robotics and Automation (ICRA 2003). 6
