Semantic Shared Spaces for Task Allocation in a Robotic Fleet for Precision Agriculture Domagoj Drenjanac1, Lukas Klausner2, Eva Kühn2, and Slobodanka Dana Kathrin Tomic1 1
The Telecommunications Research Center Vienna (FTW), Vienna, Austria {drenjanac,tomic}@ftw.at 2 Institute of Computer Languages, Vienna University of Technology, Vienna, Austria
[email protected],
[email protected]
Abstract. Task allocation is a fundamental problem in multi-robot systems where heterogeneous robots cooperate to perform a complex mission. A general requirement in a task allocation algorithm is to find an optimal set of robots to execute a certain task. This paper describes how coordination capabilities of the space-based middleware are extended with the semantic model of robot capabilities to improve the process of selection in terms of flexibility, scalability and reduced communication overhead during task allocation. We developed a framework that translates resources into a newly defined semantic model and performs automatic reasoning to assist the task allocation. We conducted performance tests in a specific precision agriculture use case based on the robotic fleet for weed control elaborated within European Project RHEARobot Fleets for Highly Effective Agriculture and Forestry Management. Keywords: Task Allocation, Space-Based Computing, Semantics, Robotic Fleet.
1
Introduction
Today cooperating robots are commonly used in controlled and structured environments, such as factories, where they are managed from a central place that supervises mission execution. Due to the advances in the perception and locomotion technology there is a great potential to use multiple cooperating robots in heterogeneous and unstructured environments. This however imposes new requirements on communication and coordination of actions in teams, and the well-established centralized coordination approach needs to either be enhanced or replaced with a distributed approach. Task allocation is a fundamental problem in multi-robot systems where the core requirement is to find an optimal set of heterogeneous robots that have to cooperate in order to execute a complex mission [1]. Critical enabler for distributed task allocation is an efficient coordination. The shared space-based coordination model defines a centralized tuple space as a shared message repository exploiting generative communication among processes. This work extends coordination capabilities of the spacebased middleware XVSM (eXtensible Virtual Shared Memory) [2], [3], particular its E. Garoufallou and J. Greenberg (Eds.): MTSR 2013, CCIS 390, pp. 440–446, 2013. © Springer International Publishing Switzerland 2013
Semantic Shared Spaces for Task Allocation in a Robotic Fleet
441
Java-based implementation MozartSpaces. XVSM is based on a Linda [4] tuple space model. Our framework, Semantic MozartSpaces [5] introduces a new data model based on RDF and SPARQL where RDF is used to construct nested blank nodes in a triple store and SPARQL facilitates query and update interactions with the triple store. The remainder of this paper is structured as follows: Section 2 introduces motivating use-case while section 3 summarizes related work. Section 4 presents developed approach, section 5 evaluates the framework, and finally section 6 concludes the paper and presents future work.
2
Precision Farming as a Motivating Scenario
Precise management of agricultural land is aimed to diminish the use of chemical inputs and improve crop quality, humans’ safety, and reduce production costs by using a fleet of heterogeneous robots equipped with advanced sensors and actuators. Precision farming scenario introduced in the RHEA project [6] provides motivation for presented work. The scenario starts with the field inspection facilitated by two aerial mobile units equipped with high-resolution cameras taking the field photos to elicit growth stage of a crop and the diffusion of the weed. After that, the centralized fleet management system assists the system operator in choosing a suitable strategy for field treatment taking into account weed infestation map and available field robots, their implements and sensors. The selection of the treatment strategy takes into account many parameters, e.g., the type of tasks to be performed, the number and features of available robots and field information. The treatment strategy can be applied in two use cases: (1) when a weed infestation map is known in advance and all tasks are defined before a mission starts (e.g., spraying in a wheat field), and (2) when there is no weed infestation map and weed patches (tasks) are identified (using a camera mounted on a tractor) during a mission execution (corn field).
3
Related Work
The use of semantics in task and resource modeling in robotics systems is an emergent research field. In [7] authors explore a novel usage of semantic information for an improvement of a task planning in complex scenarios, e.g., robots operating in unstructured environments with a great number of objects. In [8] authors study joint collaboration of Web Service paradigm and ontology for a service discovery, composition and a task allocation. In their solution all entities expose their functionalities as Web Services allowing their discovery and composition. Our work differs from the reviewed work as we use semantic approach for both the resource and task modeling. Rational for using semantic is twofold: (1) it provides the basis for policy-based automatic mapping between task requirements and available resources and thus makes the whole process more flexible and (2) it provides a general task description language that most of the reviewed frameworks lack. Several research projects as well as commercial products have adopted the spacebased model to construct robust coordination platforms. Linda made the shared
442
D. Drenjanac et al.
space-based coordination model popular, where the tuple space consists of tuples that can be concurrently accessed by several processes. Semantic Tuple Spaces [9] (sTuples) use a web ontology language OWL for describing and matching resources. Semantic Web Spaces [10] are based on a Linda-inspired coordination model integrated with core semantic technologies such as RDF and it is utilized for coordination between agents sharing semantic data. Our work is based on an open source implementation of the Space Container [11] approach called MozartSpaces. The comparative advantage of the MozartsSpaces over the other space-based implementations is that it structures the space into containers that store entries (tuples) using different coordination patterns. Our semantic extension of the MozartSpaces borrows some concepts from the Semantic Tuple Centres [12], which treats a semantic tuple as an object of an application domain. However, while Sematic Tuple Centres has its own data format for exchanging semantic tuples and queries, we use Turtle and SPARQL. In contrast, in our solution tuples do not have a mandatory public reference.
4
Semantic Extension for MozartSpaces
This section gives an architecture overview of the Semantic MozartSpaces. The core part of the architecture is the data model that exposes a mapping process between MozartSpaces and semantic entries. The basic concept is a container hosted in a single runtime instance of the space where a container is addressable by its URL and therefore can be accessed as any other resource on the Internet. A container hosts different entries where the value of an entry is an object with several properties. Fig. 1 illustrates the usage of the Semantic MozartSpaces. On client-side the instances of Java classes (e.g., class Task) are created and the resource mapper, a component that maps a Java object to nested blank nodes, translates them into their Turtle representations (nested blank nodes), and writes them into the container. When the entry is written in the container, it is assigned an internal ID. This ID is used to generate a URI that identifies the entry. Vice versa, at client-side the nested blank node can be taken from the container and translated into the Java class instance. MozartSpaces Core take
[a :Task]
[a :Task; :needsSkill :CuttingSkill ] write [a :Task; :needsSkill :CuttingSkill , :SprayingSkill ]
Container :value [ a :Task; :needsSkill :CuttingSkill] . :value [ a :Task; :needsSkill :CuttingSkill , :SprayingSkill] .
Cont.
Cont.
Fig. 1. Take and write semantic entries from Semantic MozartSpaces
The advantage of Semantic MozartSpaces is that SPARQL queries can be used for entry selection (take operation in Fig. 1). Additionally, such queries enable the
Semantic Shared Spaces for Task Allocation in a Robotic Fleet
443
context that can be added at client-side, or it can be achieved via a pre-aspect of the container (server-side). Context entries can be used as a parameter for SPARQL queries, so that more general and flexible queries are supported, e.g., in our use case a context entry can describe the state of a robot.
5
Experimental Environment and Results
The described implementation has been tested to acquire initial efficiency measurements, i.e., to determine the expected performances and scalability of the Semantic MozartSpaces and to identify potential optimization areas. A simple experimental setup resembles the RHEA scenario: we simulate a user that generates tasks for the mission. The tasks require some skills, e.g., a spraying, a flaming or a cutting skill or their combination. Robots (executors) select tasks for execution based on matching between their skills and task requirements. We evaluated performance of the spaces in two scenarios: (1) when tasks are simultaneously produced and executed and (2) when first all tasks are produced and then executed. After that, we tested system scalability by adding more executors, from 3 to 14, for the same number of tasks, and evaluated system performances. One simplification of the evaluation scenario as compared to the real world is related to the task duration which is 2500 ms (correspond to approximately 4 meters trajectory of a robot moving at 6km/h). Fig. 2 shows how the number of executors and tasks influences execution time in the scenario where tasks are simultaneously produced and executed. The results show that the execution time increases when the number of tasks increases. Conversely, it decreases when new executors are added. Execution time decreases by approximately 30% when two executors are added, 5 in total, and is decreased by additional 40% when 3 more executors are added, 8 in total. Adding 6 more executors, reduces the execution time by approximately additional 40%. 14 executors perform 5 times faster than 3 executors (they finish 600 tasks in 130 s and 3 executors in 650 s).
Execution time [s]
1000 100
3 executors 5 executors 8 executors 14 executors
10 1 10
50
150 Number of tasks
300
600
Fig. 2. Simultaneously producing and executing tasks
In the scenario where the tasks are first produced and then executed, specific amount of a time is needed to generate a desired number of tasks. Fig. 3 shows how the production time behaves when a number of produced tasks increases. The production time slowly increases, stays around 1 s, when the number of tasks is less than 100
444
D. Drenjanac et al.
and increases faster when the number of produced tasks is higher than 100, e.g., it is around 1 s for 5 tasks, and around 5 s for 600 tasks. Fig. 4 shows how the number of executors and tasks influences execution time in the scenario where tasks are first produced and then executed. Execution times, when multiple executors are deployed, converge when there are more than 300 tasks. E.g., 8 executors perform 50 tasks in 18 s and 600 in 410 s where 14 perform 50 tasks in 10 s and 600 in 380 s. We detected that 14 executors don’t outperform 8 executors, especially when there are more than 300 tasks. This is due to complex scheduling mechanisms in the MozartSpaces and Jena. Moreover, the scenario where tasks are produced and then executed scales worse than the one where tasks are simultaneously produced and executed. E.g., in the later scenario 14 executors perform 600 tasks in 130 s, and in the former in 380 s.
Production time [s]
6 5 4 3 2 1 0 5
10
25
50 150 Number of tasks
300
600
Fig. 3. Producing tasks
Execution time [s]
1000 100 3 executors 5 executors 8 executors 14 executors
10 1 10
50
150
Number of tasks
300
600
Fig. 4. Executing tasks from a triple store
In the RHEA scenario, tasks that build a mission are defined in advance and their number is less than 100. In terms of estimating performance, we can use presented results to estimate the mission execution time. Due to the fact that all tasks are produced in advance, we choose simulation results from Fig. 3 and Fig. 4 to predict the execution time. First, we estimate a time to produce 100 tasks to 1,5 s (Fig. 3) and then use Fig. 4 to select the optimal number of executors. Logical choice would be to select 14 executors since they have lowest execution time. However, for real robots utilized in RHEA it is expensive to add new units. Therefore, we choose to execute the mission using 3 available executors where the time to complete the mission is
Semantic Shared Spaces for Task Allocation in a Robotic Fleet
445
around 90 s (corresponds to 150 m trajectory), in total 91,5 s (1,5 s for production and the rest for execution). It is worth to notice that the execution time depends on a time that executor needs to perform a task, 2500 ms. Extending the awareness of the robots in the RHEA scenario adds flexibility in task selection; however quantification of this benefit requires more elaborate task model which is out of the scope of this paper and is part of our future work.
6
Conclusion and Future Work
The integration of the space-based paradigm with underlying semantics provided a robust and scalable middleware for a task allocation in multi-robot systems. Developed data model automatically translates annotated java classes, i.e., tasks and resources, to RDF nested blank nodes and stores them to underlying triple store. Furthermore, we have demonstrated how the framework behaves in the RHEA scenario where a set of robots execute specific tasks and how the execution time depends on an insertion of new resources. To conclude, simulations we did can serve as a starting point for predicting mission duration in various scenarios. Future work will mainly focus on modeling a more elaborate task model that we expect to simplify coordination and task allocation issues in more complex scenarios. Tasks will define location parameters that correspond to geographical representation of an area in a field where a task has to be performed. Additionally, we will study how geographical distribution of a central task repository influences mission duration, communication and coordination patterns between robots.
References 1. Brahmi, Z., Gammoudi, M.M.: Semantic shared space-based complex tasks allocation method for massive MAS. In: Proc. of 2nd Int. Conf. on Computer Science and Information Tech., Beijing (2009) 2. Craß, S.: A formal model of the Extensible Virtual Shared Memory (XVSM) and its implementation in Haskell:Design and specification. Vienna University of Technology (2010) 3. Craß, S., Kühn, E., Salzer, G.: Algebraic Foundation of a Data Model for an Extensible Space-Based Collaboration Protocol. In: 13th Int. Database Engineering and Application Sym., Calabria, Italy (2009) 4. Gelernter, D.: Generative Communication in Linda. ACM Computing Survey (1985) 5. Klausner, L.: Semantic XVSM – design and implementation. Master Thesis, Vienna University of Technology (in progress) 6. RHEA project, http://www.rhea-project.eu/ 7. Galindo, C., Fernandez-Madrigal, J.A., Gonzalez, J., Saffiotti, A.: Using Semantic Information for Improving Efficiency of Robot Task Planning. In: Proc. of ICRA Workshop on Semantic Information in Robotics, Rome, Italy (2007) 8. Mokarizadeh, S., Grosso, A., Matskin, M., Kungas, P., Haseeb, A.: Applying Semantic Web Service Composition for Action Planning in Multi-Robot Systems. In: 4th Int. Conf. on Internet and Web Application Services, Venice, Italy (2009)
446
D. Drenjanac et al.
9. Khushraj, D., Lassila, O., Finin, T.: sTuples: Semantic Tuple Spaces. In: Proc. of 1st Int. Conf. on Mobile and Ubiquitous Systems: Networking and Service, Boston, USA (2004) 10. Nixon, L., Simperl, E.P.B., Antonechko, O., Tolksdorf, R.: Towards Semantic Tuplespace Computing: The Semantic Web Spaces System. In: Symposium on Applied Computing, Seoul, Korea (2007) 11. Kühn, E., Mordinyi, R., Keszthelyi, L., Schreiber, C.: Introducing the Concept of Customizable Structured Spaces for Agent Coordination in the Production Automation Domain. In: Proc. 8th Int. Conf. Autonomous AgentsMultiagent Systems, Budapest, Hungary (2009) 12. Nardini, E., Omicini, A., Viroli, M.: Semantic tuple centres. J. Sci. Comput. Program. 78 (2013)
