A CORBA Wrapper for Applications with Multiple Robots

—This paper presents a CORBA wrapper which encapsulates a generic anthropomorphic industrial robot. Since this wrapper abstracts the communications, building applications that require remote manipulation or coordination of several devices may be easily achieved by using it. This article describes an implementation of this wrapper over a real-time operating system (RTOS), namely RTAI. This type of OS ensures determinism in the movement operations of the robot. Also, a low resource consuming implementation of the CORBA specification, namely ORBit, has been used to wrap the robot and implement the communications with other devices. Finally, as a matter of example, we present how this wrapper is used to coordinate the operation of several robots in a typical 'pick & place' operation.


I. INTRODUCTION
Even though in the latest years there have been important advances in the integration and coordination of industrial control devices, quite often the creation of high scale applications is still a challenging task. This is mainly due to the complexity of connecting several heterogeneous devices provided by different vendors. Several trends try to minimize these difficulties.
Thus, there is an increasing trend in industrial environments to use open middleware technologies since they may be seen as a virtual bus that eases the connection of several software components. Some of the most widely used technologies, such as CORBA, can be executed over different heterogeneous platforms and allow tackling vendor-dependent issues to make communications transparent to the developers.
Also, a growing number of vendors are adopting truly Real Time Operating Systems (RTOS) like QNX or VxWorks, or modified versions of general purpose operating systems like Linux in order to be embedded in their devices. This second alternative is particularly interesting since it allows profiting some existing inexpensive tools while being able to react to device events in a timeliness manner.
This work describes how the combination of both types of technologies eases the development of complex robotic applications composed by several control devices. For this purpose, a CORBA wrapper that encapsulates a generic anthropomorphic industrial robot is presented. This wrapper has been implemented using ORBit [5], which is a very low profile implementation of the CORBA middleware specification [2]. This wrapping allows device hid-ing and segregating decisions likely to change, thus providing a stable interface.
From the controller point of view, handling the hardware of the robot (i.e. mechanical parts such as arms, grippers, joints or motors) is a time-critical issue. It is therefore important to have an operating system able to guarantee determinism in the robot operations. We have chosen RTAI [11] at the server, which is a real time extension for the Linux kernel developed by the community that lets writing applications with strict timing constraints.
This paper also describes an implementation of the proposed wrapper that has been carried out over a Lynx 5 robotic arm with 4 rotation axes and a gripper. In this case, for the sake of simplicity, the position of the robot has been calculated from the forward kinematics, since it has no position sensors. However, in real industrial robots its real position should be obtained from the readings of the encoders.
The results obtained for a single robot can be extrapolated to other types of robots or different devices like PLCs in a flexible manner.
Related work can be found in the work by Azad et al. [1]. They model and simulate with Simulink a single-link flexible robotic manipulator. Floroian et al.
[12] develop a multi-agent mini-robotic system. García et al. [8] utilize micro-servers to access and configure remote robots for the pharmaceutical sector.
The remaining of the paper is structured as follows. Section 2 describes the system architecture with Linux/ RTAI and the CORBA communications; in Section 3 we present the generic interface of the wrapper operations; Section 4 is dedicated to the implementation details and in particular to calculate the forward and inverse kinematics of the robot; Section 5 studies a pick and place example of use; the final section draws the conclusions of this work.

II. ARCHITECTURE DESCRIPTION
The basic architecture of our implementation is shown in Figure 1.
This simple architecture can be easily generalized to another architecture in which several robots are controlled by one single client from the Internet as depicted in Figure  2. In the Figure, each robot has been associated with a server which is the robot controller since in the most generic case robots require considerable computing power for the calculation of the inverse kinematics problem which must be solved with real-time constrains.
The logical layers at the client side are schematized in Figure 3. The application makes use of CORBA stubs to access remotely the CORBA wrapper, therefore controlling the movements of the robots.    Regarding the server side, the logical layers are schematized in Figure 4. This schema shows that only the RTAI kernel has straight access to the hardware. As a consequence, real-time tasks for sensing, acting and controlling the movements of the robot can meet their time constrains. Other activities, including the CORBA objects that encapsulate the robot communication with the client or other robots, are carried out through the Linux layer with not so stringent real-time restrictions.

A. RTAI
Some existing general-purpose operating systems (e.g. Linux [4]) can be improved in order to support real-time applications by using an intermediate layer responsible for reacting to critical operations (see Figure 4). The new intermediate layer, which is preemptive, encapsulates all hardware interruptions by means of a hardware abstraction layer (HAL) and provides a programmers' interface to be used by application tasks. Thus, those tasks that require real-time guarantees, such as those interacting with the sensors or actuators, may access directly this new layer without the interferences of a general purpose kernel. But the programmers' interface provided by the new layer is not compatible with legacy applications that are typically executed over the selected general purpose kernel. This problem may be solved by adapting the general purpose kernel (Linux in Figure 4) in order to be executed on top of the new preemptive layer so any application that runs on top of the general purpose kernel may use directly its programmer interface and services without being recompiled, obviously, without real-time guarantees.
There are two main solutions for Linux that follow this approach: RTAI and RTLinux. Both of them have the same roots and their performance has been compared by Ripoll [4] obtaining similar results. For this work RTAI (Real Time Application Interface) has been selected to execute the critical operations related with the control of the robot. RTAI is a real-time microkernel supported by the Polytechnic Institute of Milan in Italy. This GNU/Linux distribution is widely used in the academic environment.
An adapted kernel of Linux is executed on top of the RTAI microkernel in order to execute non-real time tasks and legacy applications.

B. ORBit
CORBA is a well established OMG standard to develop distributed applications. It makes use of an ORB (Object Request Broker), a software component to easy object communications hiding object location, implementation (including language, operating system and hardware) and state.
Since manufacturing devices typically require real-time communications, RT-CORBA [3] was one alternative for developing the robot wrapper. Unfortunately, RT-CORBA is a relatively complex technology that requires advanced programming skills. In addition, the RT-CORBA implementation should be adapted to be used with the RTAI microkernel, reducing the number of implementations available. So, the authors adopted a simpler solution based on the use of a low resource consuming implementation of CORBA, that it is executed over the Linux kernel. This choice was justified by the fact that the duration of the robot movements takes much more time (up to several seconds) than the time typically used in the communication tasks.
The CORBA implementation used, ORBit2 [5], is known for its outstanding performance. As a matter of example, ORBit2 was used for communication tasks in the GNOME project. This implementation was considered sufficiently stable and well documented.
In this architecture, the communications at the server side are carried out as CORBA objects that execute at the Linux level, i.e. with no Real Time guarantees as shown in Figure 4. However, as commented above, this will not jeopardize the operation as communications are relatively fast when compared to the movement of the axes.
It is also interesting to point out that several authors and vendors have ported some CORBA products to be used within RTAI and RT-Linux. One example may be found in Pérez et al. [10] where a distributed architecture for embedded systems is proposed based on the use of RTAI and ORBit.
iJOE -Volume 7, Issue 4, November 2011 PAPER A CORBA WRAPPER FOR APPLICATIONS WITH MULTIPLE ROBOTS III. WRAPPER INTERFACE This section presents a generic wrapper for anthropomorphic industrial robots of up to 6 Degrees of Freedom (DoF). This wrapper, which is provided as a distributed object, may be easily included in distributed applications that require the use of robots. The interface implements most typical operations of this type of robots consisting of:  Initialize the robot to the initial position  Move the robot from one point to another  Move the robot in a linear trajectory  Move the robot an arc of a circular trajectory  Open and close the gripper The robot interface also has attributes to:  Know the state of the robot and the gripper  Set the approaching and moving speed More specifically, Figure 5 shows the attributes and methods proposed for the generic Robot class. These will be described in the next paragraphs.
Some of the attributes are private, represented in Figure  5 with their names preceded by a minus (-), such as Arti-Coord, CartCoord, GripperStatus and Status, which keep internal information. In particular, ArtiCoord and CartCoord keep the location of the robot using its joint and Cartesian coordinates respectively. ArtiCoord is a vector with as many components as Degrees of Freedom that define each articulation in degrees in the case of a joint rotation or meters if it is a translational joint (θ 0 , θ 1 , θ 2 , θ 3 , θ 4 , θ 5 ). CartCoord is a 6 element vector (x, y, z, a, b, c) that defines the position and orientation of the gripper with respect to a coordinate system located in the base, being a, b, c, the Euler angles for representing the orientation of the gripper. All robot movements and approaches change these values. GripperStatus defines the status of the gripper which may be Open or Close according to the homonymous methods described below. Finally, Status is a more general attribute that supplies the status of the robot. The values considered so far are Error, Waiting and Standby.
Other attributes such as RobotType, DoF, MovRange and Reach are public. These attributes, are represented in Figure 5 with their name preceded by a plus (+).
In particular, RobotType allows the configuration of the robot type to be used (Anthropomorphic, Cartesian, Cylindrical, Polar, Scara or Other). This attribute is related to the DoF attribute which describes the Degrees of Freedom of the robot. MovRange is an array that defines the maximum movement per articulation. Finally, Reach defines the maximum reach of the robot as a whole.
The proposed wrapper provides some methods that allow consulting the value of these attributes (not represented in Figure 5). The wrapper also proposes eleven additional methods that allow using the robot in distributed applications. These methods are distinguished in different categories: Movement operations and configuration operations.  MoveS is similar to the previous method but combines the movement of all joints in order to achieve a linear trajectory of the end effector. Both methods receive as a parameter the coordinates of the destination point (P x , P y , P z ), a distance (d) which provides the vertical position in Z axe of point P as well as a time interval (t) to reach the destination from which the movement speed will be calculated. Finally, MoveC produces a circular movement by interpolation of the three points whose Cartesian coordinates are provided in the method. There are other movement operations provided by the wrapper such as Drive, which allows moving a single articulation a given increment or decrement of degrees at a given speed and Ready, which sets the robot to its initial position.
Other operations include, Delay which makes the robot wait during a certain time interval. It is typically before carrying out a movement in order to synchronize the robot movements. Also, some actions such as Open and Close are aimed at manipulating the gripper. Both of them affect the GripStatus private attribute. And the Speed method which defines the speed limit as a percentile of the real maximum speed of the end effector, to prevent from precision loose or damage. ArtSpeed is a similar operation but aimed at one articulation. Finally, AllSpeed configures the maximum speed for all articulations.  IV. ROBOT DESCRIPTION The previous interface has been validated over a robotic arm. Namely, it has been implemented over a Lynx 5, which is a robotic arm with 4 rotation axes created by Lynxmotion. Even though this is an economical and compact robot no generality is lost since it reproduces most of the characteristics of more advanced and expensive industrial robots. In fact, this robot has become a very interesting alternative for educational environments. Figure 6 shows a picture where its 4 axis have been depicted. This section describes the main issues related to the description of the robot including the resolution of the Forward Kinematics and Inverse Kinematics problem which are used by the real-time tasks to produce the movements described in the previous section. Table I describes the characteristics of these axes, which are shown in Figure 7. Note that except for the first axis of rotation (Base), which is on the 'Z' absolute axis, the other axes are over the 'Y' axis (see Figure 7 below). Also note that all axis turn rightwards except the elbow that turns leftwards. The robot can move in a fast, accurate and repetitive way on behalf to a set of embedded servo drives.
Since an origin of coordinates must be chosen for the movements of the robot, Figure 8 shows the initial position of the robot from which the movements will be executed.

A. Forward Kinematics (FK)
The solution of the Forward Kinematics problem (FK) of the robot is given by the Transformation Matrix T (1). This matrix T relates the Cartesian position (P x , P y , P z ) of the gripper or end effector respect to the reference coordinate system at the base of the robot: {X 0 , Y 0 , Z 0 } with the input values of every joint (θ 0 , θ 1 , θ 2 , θ 3 ).
In order to obtain this matrix, the Denavit and Hartenberg (D-H) convention is followed. This convention involves the use of an algorithm that allows building the resulting matrix, T, from the multiplication of a sequence of matrixes like (2) that represent the transformations of coordinates for every axis of the robot.
Thus, matrix (2) describes the coordinate transformation from the previous coordinate system (i-1) to the next coordinate system (i). This matrix requires the calculation of four parameters, known as Denavit-Hartenberg parameters which are represent by θ i , d i , a i and α i . These parameters depend on the geometry of the robot. Table II shows the values of these parameters for each of transformations of coordinates for every axis of the Lynx 5 robot used in the case of study.  Figure 9 shows the length of each robot component taking into account the geometry of the Lynx 5 robot. By multiplying the individual matrixes of each system in a noncommutative way the solution of the Forward Kinematic problem is reached, i.e. the Cartesian position of the end-effector with (θ 0 , θ 1 , θ 2 , θ 3 ) known.

B. Inverse Kinematics (IK)
The Inverse Kinematics (IK) problem allows to calculate the values of each joint (θ 0 , θ 1 , θ 2 , θ 3 ) in order to locate the end effector of the robot at a specific point given in Cartesian coordinates (P x , P y , P z ), respect to the reference c }.
In order to solve the IK problem an algorithm must be provided. Unfortunately, solving the IK problem for a robot is usually a more complex task than solving its FK problem since there are no general algorithms to solve it. In addition, a robot with 4 DoF like the Lynx 5 has several solutions to reac bow bellow). Frequently, iterative numerical methods or algebraic methods are used to solve the IK problem. However, in this case it is possible to find the solution in a closed form using geometric methods. This is a simple way to solve the IK by relating the coordinates of the end effector and the joint angles. This has been the approach followed in this case study due to its lower proces mpared with other types of algorithms.
For the sake of simplicity due to the 'pick and place' nature of the robot operation described in the next section, it has been considered that the last articulation will always move in parallel to the base plain. Thus, the inclination of the last joint is 0 degrees, because of its parallel position with the base plain. This fact simplifies large tion of a simple algorithm to solve the IK. The closed form for each joint (with P x , P Where P is obtained from expression (10): bots need to cooperate in or s could even be exchanged without too much tro V. CASE STUDY In this section a simple pick and place operation is described in order to illustrate how to use the wrapper proposed in section 3. This case study aims at demonstrating a scenario in which several ro der to execute an operation. In this case study, two Lynx 5 robots identical to the robot described in Section Fehler! Verweisquelle konnte nicht gefunden werden. were involved. Note that one of the advantages of using the proposed wrapper is that different robots can be used as long as they support the generic wrapper described in Section 3. Different robot configuration uble. Operation in both arms is similar and it is based on the operations of the wrapper described above. This approach PAPER A CORBA WRAPPER FOR APPLICATIONS WITH MULTIPLE ROBOTS nodes that recognize th ynchronize sequences of movements am one piece is present in a producerconsumer fashion.
requires either using a central coordinator that implements applications with multiple robots in an easy way or that the operations are triggered by the e images acquired by the cameras. More specifically, pick and place operations at every robot require the use of the commands Move, MoveS or MoveC to execute the rough and approaching movements of the robots, as well as the Open and Close methods in order to get and leave the pieces. Also the Delay operation is used to s ong the robots. A diagram for this operation is provided in Figure 10. Basically, a node with a camera starts the Pick & Place operation in Robot 1 by calculating the coordinates of the piece at the origin point of the 'Pick' operation in the Pallet 1 and then coordinates at the destination of the 'Place' operation in the Store 1. These coordinates are used to trigger the movement of the robots with the central coordinator (or directly by the camera node). In parallel, Robot 2 picks a piece from Store 1 and places it on Pallet 2 provided that at least Currently, the authors are working on a graphical user interface from where the robot could execute different operations in an easy way. movements of the robot as well as to operate th t of one robot by using this wrapper m s with multiple robots by using the proposed wrapper. VI. CONCLUSIONS AND FUTURE WORK This article presents a generic CORBA wrapper to encapsulate industrial robots. This wrapper can be used to create distributed applications with multiple robots in an easy way either by coordinating nodes of the robotic applications or by triggering the operations from other nodes of the distributed application. The proposed wrapper is generic enough to be used with different types of industrial robots and provides operations to execute rough and approaching e gripper. This wrapper has been implemented to demonstrate its viability for an economical and compact robot suitable for educational environments. It has been implemented over a Real-Time Operating System, namely Linux-RTAI which ensures determinism in the local operations of the robot, and a low resource consuming implementation of the CORBA specification, namely ORBit. Video demonstrations of the movemen ay be found in [9]. One of the main advantages of this wrapper is its flexibility since it allows creating applications with multiple robots in an easy way. As a matter of example, a simple 'Pick&Place' operation that involves two robots is presented. This approach allows that students could create application