The use of robotic applications in forestry or agriculture is widespread. This paper will deal with the agricultural robotic systems which work into orange groves. These systems should perform some general applications, such as navigation, and specific maintenance tasks. In orange groves, the robotic system can be used to collect oranges, detect illnesses, eliminate weeds, fertilize, or simply explore the grove to eliminate rests of trees by the pruning.

In the bibliography, the description of cooperative systems, composed by some different robots, for agricultural tasks is not common. In general, a single complex robot which performs specific actions on the environment is commonly suggested in the literature [1–5].

The control architecture is one of the most important parts to develop in a robotic system, especially if it is composed by some robots which must cooperate. This control architecture must give support for all the facilities of the system and forms the backbone of the robotic system. The right choice of the architecture can facilitate the specification, implementation and validation of the applications implemented for the system. In the literature, we can find some important architectures which are able to be used in our cooperative system.

Abstraction of the hardware, code reuse, scalability and other features are included in these three alternatives. Moreover, some of these architectures implement the capability to manage the possible coordination or cooperation among different entities that could be involved in the system to perform the different tasks. Additionally, the capacity of allowing communication, implicit or explicit, between the elements in the system is also implemented by some of them.

Table 1 introduces a comparison considering all these control architectures and the proposed Agriture. Important and relevant measurements have been included in this comparison.

The research described in this paper is focused on the development of a cooperative system to control a team of mobile robots. The intention is to use the proposed system in agricultural environments developing different maintenance tasks. As mentioned before, in any robotic system it is necessary to choose a control architecture to support the system. However, none of the architectures reviewed before fit well in our cooperative system requirements. In our case, including the capabilities of the other architectures, it is also desirable to have the architecture based on international standards and allow simulations of the elements in the system in order to deploy or debug the applications without the necessity to move to the outdoor scenario. These concepts are not present in the cited architectures. For this reason we introduce a new control architecture called “AGRIcultural architecTURE” (Agriture), which integrates three different systems (Player [9], JADE [10] and HLA [11–13]) that interact to provide a solid control architecture for developing cooperative robotic system. Figure 1 introduces the basic description of a distributed application for the proposed architecture.

The rest of the paper is organized as follows. Firstly, the design and implementation of the proposed architecture, Agriture, is introduced in Sections 2 and 3. In Section 4, some distributed applications which can use Agriture are detailed. Finally, the conclusions and some future research lines are presented.

As mentioned, the purpose of this work is to develop a system able to control a team of mobile robots in agricultural environments. This system is based on the Agriture architecture which is the backbone for the system. Agriture, as explained, is based in three subsystems: Player, JADE and HLA, each giving different features to the architecture.

The most interesting system added to the architecture is the HLA (High Level Architecture) subsystem. HLA provides a framework to create complex simulations using simple components and is defined under IEEE Standard 1516–2010. There following institutions use HLA for their applications:

NASA: This agency uses HLA for integrating numerous specialized simulators into larger overall space mission simulations [14]. It is also used for formation flying using multiple spacecraft and ground stations. Furthermore, some applications related to modeling natural Earth or planetary geophysical systems are based on HLA.

HLA simulations are divided into federates. “A HLA federate can be a computer simulation, a manned simulator, a supporting utility (such as a viewer or data collector), or even an interface to a live player or instrumented range” [19]. This property of the HLA systems opens a very big field of applications. It allows the use of both real and simulated entities at the same time, being these entities robots, environments, or any part of the system able to be simulated. This is specially useful when the system is optimized for a specific application, like the case of agricultural robotics. The relationship among the different parts is depicted in Figure 2.

In the previous figure, an example of abstraction of the mobile robot is used. Depending on the application, a real or simulated instance of the mobile robot (ATRV-2) is used to perform the corresponding tasks.

The new architecture, shown in Figure 1, is composed of three layers. The physical layer is related to all the real or simulated devices (robots, cameras, sensors, ...). They are the agents which interact with the real or simulated environment. One important feature is that each of these elements has its own specifications and communication protocols.

The architecture middleware implements: (1) the cooperation and coordination tasks, (2) communication between the elements, and (3) abstraction of the external devices (elements). This middleware involves three parts. One of them is in charge of implicit communication and establishes the links and data exchange format between the different elements; another part is related to explicit communication and takes charge of determining which information is transmitted and how the tasks are assigned to physical elements; the last one provides machine independence to the system because each robotic system is abstracted. The system does not work directly with the real robots, and their abstraction allows to use basic commands to control the robots. In this way, the robot can be easily replaced by a different robot without having to recode the middleware. Only the abstraction module related to the robot has to be replaced.

Finally, the highest part of our architecture is composed by the distributed applications. These distributed applications are controlled by the middleware layer, which is in charge of assigning the different tasks to each specific element or device. When an application is tested and it correctly works, it can be added to the middleware as a part of the whole system. This is a feature of Software Scalability.

The whole system, with the three layers detailed, can be seen in Figure 3.

The diagram shown in Figure 4 represents how the signals flow in the proposed architecture. In this chart, an instance of device (Camera, LASER, GPS or Robot) is directly linked to a real or a simulated element.

The proposed architecture, Agriture, can interact with real and simulated devices. Depending on the final application, a concrete device (real or simulated) can be used. This can be useful in the procedure used to set or optimize some parameters of the whole system.

As an example, this system can be run in a real orange where a classifier processes the images obtained by the vision system in order to identify the elements of the grove as depicted in Figure 13. The sequence of images captured can be stored for further research or debugging tasks. Although the classifier used can be good enough, its performance can be improved by setting better its parameters. In this case, an off-line simulation can be run using the stored data. It means that all the elements and devices of the system are simulated but they provide real data from the previous real run. In the figure, it can be seen that the virtual camera provides a capture done in the real orange grove to the simulated environment. In the simulation, other classification alternatives (using the same classifier with different parameter or choosing different base classifiers) can be tested and the original classifier (the one used in the real runs) can be replaced if it is outperformed by another alternative.

In the previous image, it can be seen that the classification obtained in the real run is good. However, there are some misclassifications. Some of them are near the boundaries between the sky (white in classification image) and orange crowns (denoted with green pixels). In the experiments done off-line, a better classifier has been used with the same purpose and it provides slightly better results. Although both classifications are similar (close to 95% of correctly classified elements), the second one is better because the misclassifications near the boundaries tend to disappear.

Although the use of off-line runs have been introduced to optimize a task of the real system (a classification task in the example), it can be used to evaluate a new task (not implemented in the real system) which uses the information provided by the sensors used in the real system. This application involves using a completely simulated environment with virtual devices to test it. These simulations with real data can be useful when the number of alternatives considered for a new task are high because they can be tested under the same experimental framework (the same real data) without using the real devices.

Furthermore, the use of Agriture can be considered for hybrid applications in which real and simulated elements are used together. In hybrid applications, both kinds of elements (real and virtual) must be present.

In a first hybrid application, the real robots move in a free-obstacle environment (an example is shown in Figure 14). The orange grove can be simulated but the interaction and navigation of the different robots can be real. For instance, the robots can be located into a warehouse but the information provided by the camera and GPS can be simulated to make the robot believe it is navigating in a real grove. In this application, the robot’s behavior in an orange grove can be tested without the robot being there. In this case, the real robots will navigate in the simulated grove without the risk of damaging the environment. Moreover, the economical costs of optimizing the system (testing different algorithms for a task) are reduced because the outdoor field experiments are avoided.

The second hybrid application considered is depicted in Figure 15. This application consists in using both real and virtual devices in a real environment (orange grove). In this system, a real robot could perform a virtual task in parallel with other real tasks. For instance, the orange trees can be virtually sprayed or the weeds located in the path can be virtually removed while the robot is navigating through the grove. In this way, some different algorithms to perform a new task can be tested while the robot is running another real application. The real devices, such as cameras and other sensors can provide real information to the new virtual element, so the simulation can be more realistic. It can be also useful in the case in which the availability for executions of the real devices (robots and sensors) into a simulated environment (such as the warehouse previously mentioned) is low, because the resources are required to perform a real application. In this case, the new virtual applications can be tested in situ while the required real task is being done.

In this paper, Agriture, a new architecture to implement an agricultural multirobotic system has been introduced. In Agriture, Player/Stage is in charge of the hardware (real or simulated) abstraction. The coordination and cooperation tasks rely on JADE whereas the implicit communication is assigned to HLA. They have been selected to improve the reusability, scalability and interoperability of system.

Furthermore, the use of Agriture has been introduced either in real or simulated environments. It can be used in real applications or it can be applied to simulate experiments. In addition, the proposed architecture can be used in hybrid systems in which real and simulated elements (devices and environments) can interact.