Theoretical Framework
The purpose of this section is to explain the analysis of the proposed cooperative robot system. First the proposed architecture of this system will be defined, then the same will be done with the operative/communication system, which is basically the same as in [1].
Architecture.
Figure 2 shows the proposed physical architecture of the system. As seen, in difference to [1], the system is based on a car-like robot instead of an hexapod. The robot will use a force analysis similar to the one shown in [3], based upon the new body sensor technology. The control system will be based on an autonomous robot configuration system rather than a leader-follower system. This is why we will use SSA, which consists on the division of tasks to perform control of the system. In general, there will be 2 main control layers:
1. For the trajectory when both robots are carrying the object.
2. For the cooperative lifting of the object.
Fig. 2. Car-like robot with body force sensor [3]
For the first one, we have only got to program the trajectory into both systems, since the proposal does not involve automated navigation systems.
However, the second one is the real challenge of the present work. The cooperative lifting of the object will be based upon a force analysis as follows:
The object in consideration is an undeformable and regular box (paralelepiped). The robots will grasp the object as shown in figure 3.
Fig. 3. Gripper Force Analysis [1]
So the mathematical model of this configurations goes:
Sum(Fi, from i=0 to 3) = 0
Now, this defines the forces on the horizontal plane. As to the direction of the vertical axis, the only variable taken on account will be the resultant force applied in that direction by the robots. This is possible if we assume that both robots are on a completely horizontal plane and that there is no sliding in the object with respect to the gripper.
All this motions and forces will be measured by the Body Sensor and used as control variables. Since this is a very important portion of the project, it is necessary to give a brief description of the way in which the body sensor works. This relatively new configuration of this sensor, shown in figure 1, will calculate the total force applied to the robot. This is possible because the sensor is located beneath the body of the robot and over the drive mechanism. The sensor consists of two plates, the one in the upper portion is known as the sensor, and the other is the base. These are joined by links which act like strain gauges so that the sum of the forces reported by the links will be used to calculate the total force in the center of the sensor plate.
The force is calculated by:
Fbody = transpose(J) * Flink
where Flink is the vector that represents the forces applied to the links, Fbody is the resulting vector of forces in the 3D space (the 3 first elements) and the resulting moment in the sensor (the other 3 elements of the vector). J is the Jacobian matrix of the parallel link mechanism defined by a vector of the link lenght (8 elements) and the generalized coordinate vector representing the position and orientation of the sensor plate (x) as:
J = dl/dx
Since the Jacobian represents the link model, it will determine the sensitivity of the sensor.
Communication System (Operative System)
The operative system proposed for this project will be based upon the ICRoS developed by Fujita and Kimura in [1]. This system has several characteristics that allow it to accomplish with the necessities of the communication between and inside the robot. As said in the State-of-the-Art section, there are four characteristics to have a robust cooperative system, which can basically be summarized in integration of systems (software and hardware), so that the same operative system used for communication between robots can be used by the emitter robot to send data to its own systems and that the communication is transparent to the user, which implies that the user does not have to worry about specific commands for communications, he will just have to worry about programming the path in the robots, since the task of lifting an object will be done autonomously by the robots. Another characteristic is that data has to be accessible at any point.
The Operative System is based in an Object oriented language and uses the principles of SmallTalk protocol, which allows the characteristic of accesibility to data and integration. This is because when the object is created or sent by a robot, every level of the robot will have access to the data, from a simple joint actuator to the main logic of the robot, of course, each of these layers of the system will have the ability to identify which data belongs to them and which doesn't.
There are two kinds of operations supported by this OS, ParOperations and SeqOperations. These two are defined to subdivide a task. A ParOperation is an opperation that can be realized by two units (actuators or two complete robots) at the same time, and SeqOperation, as its name implies, is a sequential task. As to communication, since both robots are autonomous, and each has its control logic, any of them will be able to start the communication interchange. This interchange can be defined as a Half-duplex communication, since the channel is defined for transmision and reception, but not at the same time. This means that when robot 1 gives a messagge to robot 2, robot2 will not be able to "talk" until the messagge is received, then when the channel is free, it can send a reply (an acknowledge, a "task complete messagge" or an error).
Fig. 4. Execution of a cooperative operation using ICRoS [1]
As seen in figure 4, the OS initializes communication between robot 1 and 2, and takes care of dividing the main instruction into a set of different ParOperations and SeqOperations, but it also allows communication inside robot 1 using the same data. This is why we call this an integrated system, since the same operative system is capable of transmitting commands and makes sure that they are executed correctly.
Back to main
Research Proposal