Data normalization and integration in Robotic Systems using Web Services Technologies

The robotics is one of the most active areas. We also need to join a large number of disciplines to create robots. With these premises, one problem is the management of information from multiple heterogeneous sources. Each component, hardware or software, produces data with different nature: temporal frequencies, processing needs, size, type, etc. Nowadays, technologies and software engineering paradigms such as service- oriented architectures are applied to solve this problem in other areas. This paper proposes the use of these technologies to implement a robotic control system based on services. This type of system will allow integration and collaborative work of different elements that make up a robotic system Keywords-SOA; robots architecture; web serices; management and integration.


INTRODUCTION
Robotics has become one of the most active emerging areas in which converge a large number of disciplines [1].One of the biggest changes has been the expansion of the environments where they are used, from industrial environments to service robots for professional use and or domestic environments [2].This implies that the variety of robots has grown, the number of devices integrated has increased and diversified, the scenarios are now unpredictable, dynamic and open, and therefore the complexity and heterogeneity of the underlying information has grown.To provide a solution to this problem are being implemented proposals related to service-oriented software applications and techniques of software distributed over the Internet [3].But because the elements that make a robot operate at different levels of technology (electro-mechanical elements, algorithms and software functions, neural networks, etc.), first standardization is required for all items, so you can see all and each of them from the same functional level.This paper presents the standardization of robotic elements as a service through a conceptual architecture based on ICT and widespread in E-Business, which enables the management of information flowing through various channels and sources of a robot.In addition to allowing homogenization of the devices involved in any robotic system also allows for standardized treatment of information, solving problems of integration of heterogeneous information, helping to define the information flows in a dynamic manner and allowing to overcome the problems caused by different frequencies and different processing requirements of work for those elements of a robotic system.
For the development of the proposal in the next section we make a brief tour of the background of major related work.Then the normalization of the components of a robotic system is presented and architecture for the transformation of elements in services is proposed.Afterwards an instantiation of the proposed architecture using Web Services to implement control systems of autonomous mobile robots are constructed, and finally the main conclusions and future lines of work are shown.

II. BACKGROUND
A robotic system consists of a set of elements that operate together to achieve a goal.The nature of these elements may be different (electro-mechanical components such as sensors or motors, software elements such as route tracing algorithms, integrated circuit or systems on chip (SoC) to implement neural networks or pattern recognizers, and so on).Moreover, these elements may vary over time to adapt to new circumstances, environments or requirements [4].However, from a functional point of view, each of these elements can be seen as an entity that receives information, performs an action and produces results (these results can be data or may be an action on the environment).This mode of operation is similar to what we observe in the distributed software components that make up distributed applications [5], and so we can use a similar conceptual base to define each of the pieces that form a robotic system rather than seeing the robot as a rigid set of devices than should communicate between them.A centralized implementation is robust and efficient, but these applications lack the properties necessary for their maintenance, modification, modernization, adaptation or flexibility to change in the medium to long term.These deficiencies greatly influence the management of information, because changing a source of information (for example an ultrasonic sensor for a laser sensor) usually involves reconsideration or rescheduling of part or even the entire system [6].
Several proposals have emerged to provide these features.These works provide a common framework for the development of heterogeneous robotic systems using frameworks or tools like BABEL [6], CLARAty [7], LAAS [8], DAMN [9], which generally provide those features found in software distributed applications like flexibility, modularity, code reuse, management of production cycles, low-cost development, adaptation to change, and so on.However, these works make different proposals that develop technologies or www.ijacsa.thesai.orgframeworks that require learning and produces that specialists in robotics are away from the world of software engineering, although the world of software engineering is which provides the desired characteristics.These characteristics are:  Control applications must be modular to allow code reuse and rapid development.
 The control logic must be independent of hardware.
The hardware provides the possibilities, but the software develops the skills.
 Support for communications should be provided by framework in which is developed the system and details should be hided for implementation of intelligence of the robot.
 Components must be able to communicate asynchronously transmitting values.If the components use references cannot be distributed independently.
 The components must be able to be linked dynamically, using modules that are necessary even in runtime.

 Reactive techniques exploit the characteristics of the real environment
 Deliberative techniques allow us to infer knowledge that is not implicit in the environment

III. NORMALIZATION OF ROBOTICS ELEMENTS
In our work we propose to rely on widely available technologies and paradigms in the development of distributed software applications, specifically service-oriented architectures.For this it is necessary that each of the elements of a robotic system is provided as a service, and each service needs a support in the form of services container.A service container provides the suitable software infrastructure to deploy high-level functions on the devices.In this manner is the service that determines what function is developed and not the element or device in which is carried out.An architectural model widely used in the development of E-Business applications will be the basis for defining our services container, the architectural model of n-levels [5].In Fig. 1 we can see the architecture of n-Levels which reflects the elements that incorporate the service container.Fig. 1-a we can see all the software elements that make up the service container.At the user level is allowed access as services (consumers) as well as from other external systems using a view controller.At the access level, SOA and working drivers are responsible for controlling the security aspects of access.At the business level drivers and business orchestration give proper access to specific functions to be deployed on devices (calculate a path, detecting obstacles, store information from the environment, convert the movements of each system element in the current position, and so on.),and finally at the level of resources, appropriate adapters will provide access to resources such as storage, possibility of simulation on various platforms, and so on.These components are based on a common middleware services that provide common support in a generic way, as security services, service orchestration, service notification or discovery services.Fig. 1-b shows a simplified view of architecture, where you can more easily observe that the container will comprise a series of application components that define the specific functionality provided by the container, the middleware services layer common to all components and below the layer formed by the OS and the hardware specific to each device.Through this transformation, a motor is not a physical device with which the system has to communicate in specific and concrete way, but it becomes a service that can be consulted, to which we can transmit orders and can make decisions as launch an alert to another element of control when circumstances require.
The concept of service container is easily applicable to those robotic elements of computer nature, such as pattern recognition algorithms running on a computer to identify objects in an image.However, the electro-mechanical devices of a robot (such as motors or sensors) have no basis for processing, in other words, usually have no computational or transmission elements that allow communication with other To make these devices capable of computation and communication is necessary to convert the physical devices on smart devices.To do this it is possible to incorporate the hardware necessary to bring any physical device can become a service [10].
In recent years, advances in electronics and communications have given us a range of new devices that can provide such capabilities, so-called embedded devices.These devices are characterized by their small size and low cost, allowing its integration into other devices.Through these devices we can provide advanced functionalities to electromechanical devices that form a robot and introduce distributed computing paradigms.
Figure 2 describes the general structure of the embedded hardware.These items can transform a passive device like a motor on a device with computing capabilities.To do this, the unit requires embedded processing unit, AC / DC converter device to communicate with actuators or sensors, internal memory and a communications module that allows to interact with a network of devices.
In fig. 3 shows the embedded device selected for our proposal, the XPort device.XPort is a compact solution which includes a 16 bit processor, RAM, Ethernet port 10/100 and serial interface that allows communication with devices such as motors or sensors.This device has already been the subject of other studies in our laboratory [11] demonstrating that the physical characteristics are sufficient for the deployment of network services.

IV. TESTING AND VALIDATING
For the instantiation of our architecture we rely on autonomous mobile robots.Mobile robots are particularly interesting when used in open environments because in these environments the quantity, quality and accuracy of information is uncertain.Other reasons to tackle this type of systems is that can be highly variable: legs, wheels, chains, several sensory systems or multiple algorithms for estimation of position, which means involving a greater or lesser number of computational processes.
In our work we have tried two behaviors: Behavior1 (B1)navigating through the environment from a source point to a target point, and Behavior2 (B2)navigating through the environment from a source point to a target point with obstacle avoidance.B2 will be implemented by adding new services in B1.For our system we used a generic robot equipped with two actuators (right wheel and left wheel) from which we get the current position of the wheel (shaft encoder sensor), a digital compass that indicates the current direction and a front-sensor obstacle detection (fig.4).
In the functional analysis of behavior we have divided each of the functions of a robot in a service, isolating each function in an independent entity [12].Each service is executed independently (fig.5).B1 analysis produces the following services: Sensing, services responsible for monitoring the sensing devices; Interpretation, service responsible for translating the values obtained by the sensing to consistent data  Each of the services that integrate the control system develops a simple function, for example, Situation estimates the current position using techniques of odometry, Interpretation services translate the encoding axis of wheels into distances depending on the diameter of the wheels, and so on.Separate each system function in a service allows you to change services without changes influence the rest of the system.
For the implementation we used Microsoft Robotics Developer Studio (MRDS) because this environment provides us with an integrated development environment.NET for the design, execution and debugging robot applications scalable, concurrent and distributed, in addition to providing features such as service coordination, monitoring, configuration, deployment and reuse.RDS is built on two basic components: the Concurrency and Coordination Runtime (CCR) and the Decentralized Software Services (DSS).The CCR provides a programming model to handle multi-threaded applications and synchronization between tasks while the DSS allows to build applications based on a model of loose coupling.In addition DSS provides a lightweight model of state-oriented service that combines the concept of Representational State Transfer (REST) with a system-level approach for building high performance scalable applications [13].
In our experiments we used the simulator MRDS, a Lego robots and a homemade root, because it demonstrates the adaptability of the control systems based on web services to any type of robot, although its components are not the most accurate.Fig. 7-a show a view of the simulated robot composed of the elements described above, and fig.7-b show a Lego robot equipped with the same real elements and fig.7-c show the homemade robot with the same elements.
After deploying Web services and compose the control system according to the diagram in fig. 5 and fig.6, we get the complete control system.For both B1 and B2, the system behaves as expected.Fig. 8-a shows the simulated robot's behavior and Fig. 8-b shows the Lego robot's behavior.Both systems use the behavior B2.
When we indicate a destination, the robotic system starts and progresses to reach the end point.Using B1, if there are obstacles in the path, the robot collides with them.Using B2, the system detects obstacles and modifies the path to avoid them.Both the simulated system as the real robot, behaviors are those specified.Most services remain common to all systems.Pass from a simulated robot to a real robot only involves modifying the services of Sensing and Actuator to connect to the appropriate resource.To use the behavior B2 only have to add the services specified in Fig. 2 .a) Simulated robot.b) Lego Robot.c) Homemade robot www.ijacsa.thesai.orgcapabilities and robotic devices, the ability to reuse code, and so on.
The system has the peculiarity that each Web service operates at the frequency that requires its own characteristics.For example, the services responsible for monitoring each wheel require 50ms per cycle to obtain the state of the encoder.This data is transferred to the superior services but if this information does not imply changes (for example, the robot has not moved), Interpretation services will not produce new results.Similarly, the reasoning service starts the system when the current and desired position is not equal (not reached the destination) but during the execution will not release more orders to planning services until it reaches the destination.Each service is independent, uses its own working frequency and its execution can influence whether or not the execution of other services and the communication is done homogeneously through message passing.

V. ANALYSIS OF RESULTS
The experiments allow us to observe a number of features in the control system arising from the use of Web services:  Each functional element of the robotic system has the same internal structure, all are equal.
 Each physical element of the robot is treated by the system in the same way, everyone is equal.
 The system is very flexible, can add and delete services even at runtime.
 The system is highly scalable, we can place each item in a different network node to run.
 We can reuse services or even share their implementation.For example, the obstacle detection services (Rc) may be used by other systems that require such information.
Each service can isolate units of information and its complexity, while enabling adapt each and every one of the types of information to a common message exchange.That is, and this is one of the most important feature, different and very different information / data is shared by the system, for example, information coming from different sensing devices, with different data types and different frequency.The system allows you to isolate each unit of data, adapt it and treat it without causing other negative effects on the system.All elements of the robot, now, run a common language of communication between them.

VI. CONCLUSIONS AND FUTURE WORK
This paper has proposed the development of robotic control systems based on Web Services.This proposal allows us to standardize the elements of a robotic system and enables the exchange and processing of the information produced by each of the elements.It has also shown the implementation of this system for behaviors such as autonomous navigation without/with obstacle avoidance.The resulting system performs with the requirements and desirable features such as flexibility, adaptability, short development cycles, dynamics and absorption of problems of operating frequencies and integration and management of diverse information, regardless of the source and nature of the devices.Self-adaptation of the communication provides the perfect link between the computer functions and the physical system it controls.

Figure 1 .
Figure 1.Full view of the elements that make up the service container architecture.b) Simplified view of the service container.

Figure 3 .
Figure 3. Physical structure of the control hardware device.

Figure 6 .
Figure 6.Decomposition of behavior 2 in services.The new services change the behavior B1.