rprocess

Definition of complex operations

Contents

Last date of modification : 2010/10/18

Syntax

Sequential operations

PID = rprocess( ... , HANDLE , ARGUMENT, ...)|
PID = rprocess( ... , HANDLE , { ARGUMENTLIST } , ... )|

Concurrent operations

PID =  rprocess( ... , { ...
                       HANDLE , ARGUMENT, ...
                       HANDLE , { ARGUMENTLIST }, ...
                       HANDLE , ARGUMENT, ...
                       } , ... )

Including other sub-processes

PID = rprocess( ...,  OTHER-PID , ... )

Including a function-call

PID =  rprocess( ..., @MYFUNC , ... )
 function MYFUNC( PID, PARG )
 ...
 rprocess( PARG{:} );
PID = rprocess( ..., { @MYFUNC, ARGUMENTLIST } )
 function MYFUNC( PID, PARG, ARGUMENTLIST, ...)
 ...
 rprocess( PARG{:} );

Inputs Description VALUE
HANDLE robot-identifier integer > 0 given by robot
PID and OTHER-PID a subprocess identification handle a string given by rprocess
ARGUMENT a single argument all parameters usable with rmove
ARGUMENTLIST a list of arguments, separated by comma all parameters usable with rmove
@MYFUNC Handle of the to be executed function @-operator+functionname
PARG internal data for handling the process ---

Description

rprocess defines complex operations with coordinated robots. The function returns a process-ID to identify the created (sub)process in the further program-execution.

The definition of operations starts with a robot-handle followed by a single argument or a argument-list in curly brackets. These arguments can be all parameters and values used with the rmove-function.

There are sequential operations. That means the execution of the commands happens from left to right. A second motion(right) only starts, if the first motion(left) finished.

Concurrent operations a complete defined in curly brackets. Concurrent means that all defined motions of the different robots start at the same time. Are all these motions finished, the next command outside the brackets is executed.

To ensure complex operation-processes the returned process-ID can be used as argument in the rprocess-function. In this case this argument is a condition, that the sub-process, symbolized by this ID, has to be finished before the superior process continues.

It's also possible to include function-calls in the processes. This is shown in the examples below.

Examples

Sequential operations of one robot

%The robot moves to all positions P, after that
%it moves back with a waiting time of 1 second at each positions
%After that it moves to its homeposition
load Points P
rprocess( h, P, ...
          h, { P(end:-1:1), 'wait', 1 }, ...
          h, 'home' );

Concurrent operations with 2 robots

%Kuka und Kawasaki are the handle of the robots.
%The Kuka and Kawasaki move at the same time to the positions P1 and P2.
%After both finished their motions, both start to move to their homepositions.
load Points P
rprocess( { ...
            Kuka, P1, ...
            Kawasaki, { P2, 'speed', 50 },...
          }, ...
          {
            Kuka, 'home',...
            Kawasaki, 'home2' , ...
          } );

Including a function-call

%After the robot reaches its homeposition 1, 'Reached Homeposition 1!'
%is displayed. After reaching homeposition 2, 'Process finished !' is
%displayed.
rprocess( h, 'home', ...
          { @print, 'Reached Homeposition 1!' }, ...
          h, 'home2', ...
          @pend );
...
function print( PID, PARG, Text )
          disp(Text);
          rprocess(PARG{:});
function pend( PID, PARG )
          disp('Process finished !');
          rprocess(PARG{:});

Including other sub-processes

%Robot 1 and 2 start their motion to the homepositions at the same time.
%Is that finished(TP1), robot 1 moves to the positions P1.
%Is that finished(TP2), robot 2 moves to the positions P2.
TP1 = rprocess( {...
                 R1, 'home', ...
                 R2, 'home', ...
                });
TP2 = rprocess( TP1, ...
                R1, P1 ) ;
      rprocess( TP2, ...
                R2, P2 ) ;

Complex example

The picture 1 and 2 show operations of 3 robots :

To create a product robot 3 has to lift up a blank to a special position. There it has to stay until the sequential or concurrent drill-operations of robot 1 and robot 2 have finished. After that the finished part has to be moved to a setting-position. The declarations 'LeftDrilling', 'RightDrilling' and so on are the position-data-structures (see rpoint).

By programming with rprocess first of all the whole process has to be separated into sub-processes. The process has to be observed from left to right along the time-line, to extract all operations, which are sequential or concurrent. Furthermore concurrent operations can be figured as one operation in a sequential operation.

In this case a operation is a motion-part, e.g. the setting of the finished part or the left-drilling.

After analysing picture 1 there is only 1 process. So there is also only one line of code to define this process.

The first operation is the lifting of the blank, the second operation is the concurrent left-drilling, right-drilling and holding. If that is finished the third operation follows. That is the setting-down of the finished part.

rprocess(   R3, Lifting,...
            { R1, LeftDrilling, R2, RightDrilling, R3, Holding },...
            R3, SettingDown ) ;

The operation in picture 2 is different. Here the left-drilling and right-drilling happens sequential. In this case the drilling operations can not build a single operation with the holding-operation. So there are more sub-processes needed to define this process.

The first subprocess is the lifting of the blank.

LiftingProcess = rprocess( R3, Lifting);

The second subprocess is the left-drilling followed by the right-drilling, which starts after the lifting-process is finished. So the process-ID of the lifting-process has to be used as argument.

DrillingProcess = rprocess( LiftingProcess , R1, LeftDrilling, R2, RightDrilling);

The last subprocess starts with the holding-operation, after the lifting-process is finished. The following setting-operation starts at the end of the drilling-process. So the process-IDs of the lifting-process an the drilling-process have to be used as arguments.

rprocess( LiftingProcess, R3, Holding, DrillingProcess, R3, SettingDown)

A complete program could look like this :

function demo(PID, PARG, R1, R2, R3)
%If there is no argument : Open a connection to the robots
%and then call demo again
if nargin == 0
   disp('Press ENTER to open a connection to the robots'); pause;
   R1 = robot( 'open', 'Kawasaki',  'tcpip', '192.168.0.2' , 40000);
   R2 = robot( 'open', 'Kawasaki',  'tcpip', '192.168.0.3' , 40000);
   R3 = robot( 'open', 'Kuka',  'serial', 'COM3');
   %If opening failed the handle would be zero
        if R1 && R2 && R3 == 0
 			disp('Opening connection to the robots failed !');
        else
            %Calling demo with the robot-handles
 			demo( '0', 0, R1, R2, R3);
        end
%If there are more arguments than zero, the process has to be started
%After the process is finished, the process can be started again
else
   %Process-definition:
   if str2num(PID) == 0 % the PID is always 'char'. That's why we use str2num
                        % if PID == 0, the process has to be defined
      load Points;
      LiftingProcess   = rprocess( R3, Lifting);
      DrillingProcess  = rprocess( LiftingProcess, R1, LeftDrilling, ...
                                                   R2, RightDrilling);
                         rprocess( LiftingProcess, R3, Holding, ...
                                   DrillingProcess,   R3, SettingDown, ...
                                   {@demo, R1, R2, R3} );

     %If PID is not 0, the process is at the end
     else
       rprocess( PARG{:} ); 	%End the process correctly
       rkill; 		 	        %Setting up the original state of all robots
        switch input( 'Do you wish to produce another product (y/n) :', 's')
            case 'y'
                demo( '0', 0, R1, R2, R3); % Start process again
            case 'n'
                robot('close', R1, R2, R3); % Close connection
        end
   end
end

Back to the Robotic-Toolbox-Index

Robotic-Toolbox (w) by Michael Christern & Artur Schmidt / Research Group Computational Engineering and Automation / University of Applied Sciences Wismar / Germany 2010