A Programming Framework for Multi-Agent Coordination of Robotic Ecologies M. Dragone1 , S. Abdel-Naby1 , D. Swords1 , and M. Broxvall2 1
2
University College Dublin, Dublin, Ireland,
[email protected], ¨ ¨ Orebro University, Fakultetsgatan 1, SE-70182, Orebro, Sweden
Abstract. Building smart environments with robotic ecologies made up of distributed sensors, actuators and mobile robot devices extends the type of applications that can be considered, and reduces the complexity and cost of such solutions. While the potentials of such an approach makes robotic ecologies increasingly popular, many fundamental research questions remain open. One such question is how to make a robotic ecology self-adaptive, so as to adapt to changing conditions and evolving requirements, and consequently reduce the amount of preparation and pre-programming required for their deployment in real world applications. In this paper we present a framework for integrating an agent programming system with the traditional robotic and middleware approach to the development of robotic ecologies. We illustrate how these approaches can complement each other and how they provide an avenue where to pursue adaptive robotic ecologies. Keywords: robotic ecologies, multiagent systems, agent and component based software engineering
1
Introduction
This paper describes the integration between an agent programming system and a middleware supporting the development of Robotic Ecologies - networks of heterogeneous robotic devices pervasively embedded in everyday environments. Robotic ecologies is an emerging paradigm, which crosses the borders between the fields of robotics, sensor networks, and ambient intelligence (AmI). Central to the robotic ecology concept is that complex tasks are not performed by a single, very capable robot (e.g., a humanoid robot butler), instead they are performed through the collaboration and cooperation of many networked robotic devices (including mobile robots, static sensors or actuators, and automated home appliances) performing several steps in a coordinated and goal oriented fashion. One of the key strengths of such an approach is the possibility of using alternative means to accomplish application goals when multiple courses of actions are available. For instance, a robot seeking to reach the user in another room may decide to localize itself with its on-board sensors, or to avail itself of the more accurate location information from a ceiling localization system.
2
However, while having multiple options is a potential source of robustness and adaptability, the combinatorial growth of possible execution traces makes difficult to scale to complex ecologies. Adapting, within tractable time frames, to dynamically changing goals and environmental conditions is made more challenging when these conditions fall outside those envisioned by the system designer. In the EU FP7 project RUBICON (Robotic UBIquitous COgnitive Network) [1][2] we tackle these challenges by seeking to develop goal-oriented robotic ecologies that exhibit a tightly coupled, self-sustaining learning interaction among all of their participants. Specifically, we investigate how all the participants in the RUBICON ecology can cooperate in using their past experience to improve their performance by autonomously and proactively adjusting their behaviour and perception capabilities in response to a changing environment and user needs. An important pre-requisite of such an endeavour, which is addressed in this paper, is the necessary software infrastructure subtending the specification, integration, and the distributed management of the operations of robotic ecologies. Specifically, this work builds upon the Self -OSGi [3] [4], a modular and lightweight agent system built over Java technology from the Open Service Gateway Initiative (OSGi) [5], and extends it to operate across distributed platforms by integrating it with the PEIS middleware, previously developed as part of the Ecologies of Physically Embedded Intelligent Systems project [6]. The result described in this paper is a distributed programming framework for the specification and the development of robotic ecologies. The remainder of the paper is organized in the following manner: Section 2 provides an overview of the state of the art techniques for the coordination of robotic ecologies, with an emphasis on those pursued within the PEIS initiative - the starting point for the control of RUBICON robotic ecologies. Section 3 presents the Self -OSGi component & service-based agent framework, and the way it has been recently extended and integrated with PEIS. Section 4 illustrates the use of the resulting multi-agent framework with a robotic ecology experiment. Finally, Section 5 summarizes the contributions of this paper and points to some of the directions to be explored in future research.
2
PEIS
The PEIS kernel [7] and related middleware tools are a suite of software, previously developed as part of the PEIS project [6] in order to enable communication and collaboration between heterogeneous robotic devices. The PEIS kernel is written in pure C (with binding for Java and other languages) and with as few library and RAM/processing dependencies as possible in order to fit on a wide range of devices. PEIS includes a decentralized mechanism for collaboration between separate processes running on separate devices that allows for automatic discovery, highlevel communication and collaboration through subscription based connections. It also offers a shared, tuple space blackboard that allows for high level collaboration and dynamic self-configuration between different devices through the
3
exchange and storage of tuples (key-value pairs) used to associated any piece of data (and related meta-information, such as timestamps and MIME types), to a logical key. 2.1
Tuples and Meta-Tuples
A tuple’s key in PEIS consists of two parts: (name, owner) where name is a string key for the tuple, and owner is the address (id) of a PEIS responsible for the tuple. In the most simple scenario for executing a collaboration between components, producers create data in their own tuple space and consumers establish subscriptions to these tuples to access the data to be used. However, consuming components cannot know in advance from where to read the data to be used. Meta tuples are a mechanism addressing such a problem in a general way. By using these as inputs it is possible for consumers to read hard coded meta tuples from their own tuplespace. This corresponds to meta tuples acting as named input ports in other middleware. To configure such a consumer, a configuration writes the id and key of tuples produced by any producer. The consumer will then automatically subscribe to and read the data from the producer, as in the following (pseudo-code) example. Producer 42: while (true): setTuple "temperature"
8 GoalLocalization(?Agent) : true ← {achieve(GoalLaser(?Agent)); ...}
