ARTICLE

International Journal of Advanced Robotic Systems

Off-Line Programming Techniques

for Multirobot Cooperation System
Regular Paper

Yahui Gan1,2,*, Xianzhong Dai1,2 and Dongwei Li1,2

1 School of Automation, Southeast University, Nanjing, P.R. China
2 Key Lab of Measurement and Control of Complex Systems of Engineering, Ministry of Education, Nanjing, P.R. China
* Corresponding author E-mail: [email protected]
 
Received 30 Oct 2012; Accepted 4 Apr 2013

DOI: 10.5772/56506

© 2013 Gan et al.; licensee InTech. This is an open access article distributed under the terms of the Creative
Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use,
distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract  An  off‐line  programming  software  designed  for  result of the robot simulation phase, and generating the 

multiple  robots  cooperation  system  is  presented  in  this  robot  program  in  the  native  language  of  the  robot 
paper. At the beginning of the paper, current technologies  manufacturer  (ABB,  KUKA,  REIS,  COMAU,  Motoman, 
of  robot  off‐line  programming  are  reviewed  and  FANUC,  etc).  The  OLPs  which  have  been  so  generated 
summarized. Then, present status of cooperative functions  can  be  downloaded  directly  to  the  robot  controller  and 
tested.  Robot  OLP  software  plays  an  important  role  in 
and  cooperative  motion  instructions  defined  by 
the field of robotics, because it permits experimentation 
predominant  robot  manufacturers  are  introduced. 
that  would  otherwise  be  expensive  and  time‐
Thereafter,  principles  of  robot  path  planning  for 
consuming. OLP software permits engineers to try ideas 
cooperative motions are presented. Based on such analysis,  and  construct  production  scenarios  in  a  dynamic, 
software architecture of the off‐line programming software  synthetic environment while  collecting  virtual  response 
designed  for  general  multirobot  cooperation  system  is  data  to  determine  the  physical  responses  of  the  control 
presented. At last, an off‐line programming software with  system.  OLP  software  also  allows  the  evolution  of 
high  detailed  3  dimension  visualization  is  achieved.  robotics  control  systems,  which  depends  on  random 
Simulation  graphs  and  snapshots  of  typical  cooperative  permutations  of  the  control  system  over  many 
motions  are  presented  at  the  end  of  the  paper,  which  generations.  To  summarize,  the  OLP  softwares  benefit 
proved the effectiveness of our proposed method.  customers by reducing the onsite programming time and 
  freeing up the robot to be used for production rather than 
Keywords  Off‐Line  Programming,  Multiple  Robots,  programming,  by  reducing  the  downtime  of  equipment 
Cooperative Motion Instructions, Simulation, Visualization  when  programming  new  workpieces/variants,  and  by 
programming  complex  paths  (for  example,  deburring, 
  welding  in  tight  spaces,  grinding,  polishing,  etc). 
1. Introduction  Therefore,  OLP  software  is  indeed  a  good  alternative 
solution  to  show  the  performance  and  testing  of  robots 
Robot  Off‐Line  Programming  (OLP)  is  the  process  of  in real life through computer programs.  
converting  the  “sequence  of  operations”,  which  is  the   

www.intechopen.com Yahui Gan, Xianzhong Dai and Dongwei Li: Off-Line ProgrammingInt. j. adv. robot.
Techniques syst., 2013,
for Multirobot Vol. 10, 282:2013
Cooperation System 1
 Nowadays,  rapid  change  and  high  competition  of  global  are  available  to  provide  a  programmer  with  numerous 
markets  are  forcing  complex  product  (e.g.  automotive,  functions  which  are  useful  to  the  various  specific  areas  of 
plastic,  electronics)  manufacturing  companies  to  robotic  OLP,  such  as  robot  target  definition,  reachability 
implement more flexible and higher quality manufacturing  analysis,  clash  testing,  path  planning/augmentation  etc. 
systems. In order to hit the market window with the right  CimStation  Robotics  (CSR)  [3]  is  powerful  3  Dimensional 
product  at  the  right  time,  companies  must  have  simulation and off‐line programming software that enables 
manufacturing  operations  that  are  flexible,  agile,  and  able  manufacturers to quickly and easily simulate and evaluate 
to  launch  a  quality  product  on  time  and  cost  effectively.  alternative  methods  for  automating  the  manufacturing 
One  of  the  evolving  and  emerging  technologies  that  will  process and programming the robots. The CSR software is 
enable  companies  to  achieve  the  business  imperative  of  modular  in  fashion  to  suit  even  the  most  modest  budgets 
timely and cost effective product launches is multiple robot  and  covers  applications  including  non‐destructive 
system. Multirobot cooperation system offers one solution  inspection,  welding,  painting,  assembly,  press  and 
to  the  depicted  issue  because  of  its  incredible  flexibility.  polishing. A range of utilities are available to build up cells 
Once the manufacturing workcell been setup, little change  of varying complexity.  
is  need  for  different  initial  conditions  and  process   
variations.  This  greatly  curtails  economy  cost  for  Robot  OLP  softwares  coming  from  robot  manufacturers 
production  variations  and  make  it  possible  to  deliver  include  Robotstudio  (ABB),  KUKA.Sim  Pro  (KUKA), 
innovative  products  to  the  market  in  timely  manner  and  MotoSIM EG‐VRC (Yaskawa), RoboGuide (FANUC), etc. 
typically at reduced costs.   RobotStudio  [4]  is  ABB’s  simulation  and  off‐line 
  programming  software,  which  allows  robot 
Although both the OLP software development for single  programming  to  be  done  on  a  PC  platform  in  the  office 
robot  and  mutirobot  cooperation  control  problem  have  without  shutting  down  production.  It  also  enables  robot 
been  extensively  explored,  seldom  literatures  have  programs  to  be  prepared  in  advance,  increasing  overall 
touched  the  problem  of  devising  an  OLP  software  for  productivity.  RobotStudio  provides  the  tools  to  increase 
mutirobot  systems.  Therefore,  aim  of  this  paper  is  to  the profitability of robot system by letting manufacturers 
investigate  the  feasibility  of  providing  current  OLP  perform  tasks  such  as  training,  programming,  and 
softwares  with  augmented  function  of  multirobot  optimization  without  disturbing  production.  This 
cooperation.  At  the  outset  of  the  project,  a  literature  provides  numerous  benefits  including  risk  reduction, 
review  of  current  OLP  software  has  been  conducted.  quicker  start‐up,  shorter  change‐over  and  increased 
Present  robot  OLP  softwares  mainly  comes  from  3  productivity.  KUKA.Sim  Pro  [5]  is  developed  for  the 
sources:  from  generic  robotics  software  producers,  from  offline  programming  of  KUKA  robots.  The  product  is 
robot  manufacturers  and  finally  from  research  connected  in  real  time  to  KUKA.OfficeLite,  the  virtual 
institutions  that  produce  their  own  programming  and  KUKA  controller,  thus  allowing  cycle  time  analysis  and 
simulation  software,  usually  developed  around  existing  the  generation  of  robot  programs.  KUKA.Sim  Pro  uses 
CAD  software  such  as  AutoCAD  or  SolidWorks  or  from  the  build‐in  tools  to  load  CAD  data  from  other  systems 
scratch using OpenGL, VRML and Java3D technology.   into KUKA.Sim Pro or build models using the CAD tools 
  in  the  system.  It  also  allows  to  build  grippers,  welding 
Typical  examples  of  robot  OLP  softwares  coming  from  guns and other kinematical structures. MotoSim EG‐VRC 
generic  robotics  software  producers  are  Tecnomatix  (Motoman  Simulator  Enhanced  Graphics‐  Virtual  Robot 
RobCAD  ,  Delmia  D5/V5,  and  CimStation  Robotics.  Control)  [6]  is  a  comprehensive  software  package  that 
Tecnomatix  RobCAD  software  [1]  enables  the  design,  provides  accurate  3D  simulation  of  robot  cells.  This 
simulation,  optimization,  analysis  and  off‐line  powerful  simulation  software  can  be  used  to  optimize 
programming  of  multi‐device  robotic  and  automated  robot  and  equipment  placement,  as  well  as  to  perform 
manufacturing  processes  in  the  context  of  product  and  collision detection, reach modeling and cycle calculations. 
production resources. It provides a concurrent engineering  It  also  provides  accurate  off‐line  programming  of 
platform  to  optimize  processes  and  calculate  cycle  times.  complex  systems.  Virtual  Robot  Controller  capability 
With  RobCAD,  customers  can  design  life‐like,  full‐action  means  that  the  simulation  software  now  operates  and 
mockups  of  complete  manufacturing  cells  and  systems.  displays  the  actual  programming  pendant  interface  for 
RobCAD  enables  manufacturers  to  flawlessly  introduce  the  DX100  and  NX100  controllers.  The  VRC  supports 
automated processes by allowing manufacturing engineers  standard INFORM (robot language) instructions, and can 
to  virtually  validate  automation  concepts  upfront.  completely  simulate  the  DX100  and  NX100  controller 
DELMIA  [2]  is  a  robotics  and  manufacturing  based  OLP  software  in  the  PC  environment,  including  system 
package  that  is  utilized  widely  within  various  respective  configuration functions and condition file editing.  
manufacturing  industries  today.  DELMIA  utilizes  a  3D   
simulation  environment  to  test  and  optimize  robot  As  for  the  robot  OLP  softwares  coming  from  research 
programs  before  implementation  into  real  world  institutions,  they  are  usually  open  source  robotics 
applications.  DELMIA  features  assorted  “toolboxes”  that  software  for  academic  purpose  and  developed  around 

2 Int. j. adv. robot. syst., 2013, Vol. 10, 282:2013 www.intechopen.com

existing  CAD  software  or  from  scratch  using  OpenGL,  work positioners or other devices, to work in cooperation 
VRML  and  Java3D  technology.  Reference  [7]  presents  a  including  fully  coordinated  operation.  The  purpose  of 
simulation  system  where  a  relatively  low  cost  and  MultiMove  is  to  let  one  controller  handle  several  robots. 
commercially  available  3D  CAD  package,  Autodesk  This does not only save on hardware costs, it also allows 
Inventor,  is  used  as  an  interface  to  visualize  advanced  coordination  between  different  robots  and 
preprogrammed  robot  paths.  It  can  be  useful  for  small  other  mechanical  units.  This  advanced  functionality  has 
and  medium  sized  enterprizes  and  for  educational  been  made  possible  by  the  processing  power  and 
purposes.  Similar  approaches  exist  in  reference  [8]  by  modularity of the IRC5 control module that is capable of 
SolidWorks  SDK  package.  A  robot  simulation  system  calculating  the  paths  of  up  to  36  servo  axes.  Only  one 
based on OpenGL with VC++6.0 is presented in reference  control  module  is  required  whether  it  is  a  single  or  a 
[9].  In  reference  [10],  a  graphical  3D  simulation  multiple  robot  cell  and  expansion  only  requires  the 
environment  has  been  realized  based  on  VRML  to  help  addition  of  a  drive  module  for  each  robot  up  to  the 
facilitate  analyzing  and  previewing  kinematics  of  PA10‐ maximum  four.  Also,  the  number  of  I/Os  and 
7C robot arm.   communication links are significantly reduced compared 
  to the more common multiple controller solution.  
Even  though  there  are  numerous  robot  simulation  and   
OLP  softwares  developed,  almost  none  of  them  have  The principle of MultiMove is an expansion of that used 
equipped  the  simulation  function  for  multiple  robots  in  coordinating  a  robot  with  a  work  positioner  but,  now 
cooperation.  However,  multirobot  cooperation  functions  more  than  one  robot  can  be  coordinated  with  another 
have emerged in manufacturing plants. That means a gap  robot  or  other  device.  The  work  handling  device,  which 
existed  between  current  status  of  OLP  software  and  the  can  be  a  robot  or  work  positioner,  controls  the  work 
real robot systems. As we stated above, aim of this paper  object  and  all  the  other  devices  are  coordinated  to  move 
is  to  investigate  such  a  problem  that  providing  current  relative  to  the  work  object  when  it  moves.  It  is  achieved 
OLP  software  with  multirobot  cooperative  functions.  In  by  defining  the  object  coordinate  systems  of  each  of  the 
this  paper,  we  describe  our  approaches  of  devising  a  coordinating  devices  as  fixed  to  the  work  object  held  in 
robot  OLP  software  with  emphasis  on  multiple  robot  the handling device, so that when the work object moves 
cooperation  functions.  To  this  aim,  path  planning  the other devices move in coordination.  
strategies  for  basic  cooperative  motions  of  multirobot   
system  and  their  corresponding  prototype  instructions  MultiMove is totally flexible through the ability to switch 
are  firstly  proposed  here.  The  developed  system  is  an  between  coordinated  and  independent  operation  of  the 
integrated  environment  which  can  be  used  as  a  testbed  robots  in  the  cell.  There  are  3  movement  options  with 
for  automatic  planning  and  simulation  of  robotic  MultiMove  function:  Independent  movements,  Semi 
motions. Remainder of this paper is organized as follows.  coordinated  movements  and  Coordinated  synchronized 
Section  2  presents  a  general  introduction  of  cooperative  movements. In semi coordinated operation, the robots in 
instructions  and  cooperative  motions  from  predominant  the  cell  work  on  the  same  stationary  object  that  requires 
robot  manufacturers.  Section  3  provides  strategies  for  some time synchronization of the sequence of operations 
cooperative path planning of typical cooperative motions  but  not  any  coordinated  movements.  For  instance,  a 
in  industrial  process.  Architecture  for  this  multirobot  positioner  moves  the  work  object  while  the  robots  are 
OLP  software  is  presented  in  Section  4  and  realization  stationary, but the robots only work on the object while it 
examples are presented in Section 5. Concluding remarks  is  stationary.  An  example  would  be  two  robots  welding 
comes up in Section 6 at the end of the paper.   the  same  workpiece  in  different  areas  and  on  two 
different  sides.  The  positioner  first  moves  the  work  to 
2. Introduction of current multirobot cooperative function   present  its  upper  side  while  the  robots  wait.  Then  the 
robots  perform  their  welds  while  the  positioner  waits. 
Recently,  the  capability  of  industrial  control  units  to  Next, the positioner indexes the work to present its lower 
handle multirobot system has evolved. Notable examples 
side  to  the  waiting  robots.  Finally,  the  robots  perform 
include MultiMove function by ABB Robotics, RoboTeam 
their  welds  on  the  lower  side.  In  fully  coordinated 
function  by  KUKA  Roboter  GmbH,  and 
movement,  several  robots  operate  on  the  same  moving 
Independent/Coordinated  function  by  Yaskawa 
work object. So, the positioner or robot holding the work 
Motoman  Robotics.  All  these  functions  allow 
and  the  robots  operating  on  that  work,  move  in 
programming  of  cooperative  tasks  for  multiple  robots 
synchronism.  Therefore,  the  coordinated  robots  must 
and  positioning  devices.  General  introductions  of 
start  and  stop  their  movements  at  the  same  time  and 
cooperative  instructions  and  cooperative  motion  defined 
must  execute  the  same  number  of  move  instructions 
by these functions are provided here.  
simultaneously.  An  example  of  fully  coordinated 
2.1 Introduction of MultiMove function for ABB robot   movement  is  a  spot  welding  task  in  which  the  work  is 
continually  moved  along  an  arc  by  one  robot  during 
MultiMove  is  a  function  embedded  into  the  ABB  IRC5  which  two  spots  are  applied  by  a  weld  gun  held  by 
software  [11]  that  allows  up  to  4  robots  together  with  another robot coordinated to the handling robot.  

www.intechopen.com Yahui Gan, Xianzhong Dai and Dongwei Li: Off-Line Programming Techniques for Multirobot Cooperation System 3
 A  brief  description  of  each  instruction  in  MultiMove  enables precisely coordinated teamwork between up to 
function  for  ABB  robots  is  presented  in  Table  1.  These  15  robots  through  fast  synchronization  of  the  path 
instructions  are  all  included  in  RAPID  (robot  motions.  This  allows  the  robots  to  work  faster,  and 
programming  language  for  ABB  robot)  instructions  for  with  greater  precision  and  versatility  than  before. 
ABB IRC5 robot controller. For more information, see the  Cooperating  robots  allow  totally  new  plant  and  cell 
respective  instruction  in  Technical  reference  manual  ‐  layouts  with  shorter  production  lines  and  simpler 
RAPID Instructions, Functions and Data types.   installations.  In  this  way,  load  sharing  makes  it 
  possible  to  flexibly  multiply  the  payload  capacity  of 
Instruction   Description  standard  robots.  Or  workpieces  can  be  processed 
WaitSyncTask   WaitSyncTask  is  used  to  synchronize  during  transfer  to  the  next  assembly  station,  thereby 
several task programs at a special point in  reducing  the  nonproductive  transfer  time.  A  further 
the program.   advantage  of  the  KUKA.RoboTeam  function  is  that 
A  WaitSyncTask  instruction  will  wait  for 
each  robot  keeps  its  standard  controller.  This  is 
the  other  task  programs.  When  all  task 
connected to a high‐speed local network (Ethernet) via 
programs  have  reached  the  WaitSyncTask 
instruction,  they  will  continue  their  which  the  controllers  communicate  with  one  another 
execution.   and  synchronize  themselves.  RoboTeam  groups  are 
SyncMoveOn   SyncMoveOn is used to start synchronized  programmed  conveniently  and  transparently  using 
movement mode.   inline  forms  that  contain  all  the  command  parameters 
A  SyncMoveOn  instruction  will  wait  for  and exclude the possibility of incorrect entries.  
the  other  task  programs.  When  all  task   
programs  have  reached  the  SyncMoveOn, 
Forms  of  cooperation  for  KUKA  RoboTeam  function 
they  will  continue  their  execution  in 
synchronized movement mode. The move 
include  4  types:  load  sharing,  process‐dependent 
instructions in the different task programs  procedure,  combined  procedure  and  extended  master‐
are  executed  simultaneously,  until  the  slave  principle.  Load  sharing  consists  of  geometrically 
instruction SyncMoveOff is executed.   coupled  robots,  whose  motions  are  identical  and 
A stop point  must be  programmed before  synchronized  once  the  workpiece  has  been  picked  up. 
the SyncMoveOn instruction.   The  kinematic  systems  are  combined  to  form  a  self‐
SyncMoveOff   SyncMoveOff is used to end synchronized 
contained  chain.  The  slave  follows  the  motions  of  the 
movement mode.  
master  directly.  It  is  programmed  in  the  base 
A  SyncMoveOff  instruction  will  wait  for 
the  other  task  programs.  When  all  task  coordinate system of the master. In process‐dependent 
programs have reached the SyncMoveOff,  procedure,  the  slave  processes  the  workpiece  while  it 
they  will  continue  their  execution  in  is  being  transferred  from  one  place  to  another  by  the 
unsynchronized mode.   master  robot.  In  such  a  case,  the  master  acts  as  a 
A stop point  must be  programmed before  transfer  and  positioning  robot,  while  the  slave  is  used 
the SyncMoveOff instruction.   as  a  process  robot.  The  base  coordinate  system  of  the 
SyncMoveUndo   SyncMoveUndo  is  used  to  turn  off 
slave  is  relative  to  the  flange  coordinate  system  of  the 
synchronized  movements,  even  if  not  all 
the  other  task  programs  execute  the  master  robot.  In  this  way,  the  relative  positioning  of 
SyncMoveUndo instruction.   the  workpiece  and  tool  is  retained  during  motions  of 
SyncMoveUndo  is  intended  for  UNDO  the  workpiece.  Geometric  coupling  of  several  slaves 
handlers.  When  the  program  pointer  is  with  the  master  is  also  possible.  Combined  procedure 
moved  from  the  procedure,  indicates  that  the  load  sharing  is  combined  with 
SyncMoveUndo  is  used  to  turn  off  the  process‐dependent  variants.  The  extended  master‐
synchronization.  
slave  principle  refers  to  the  cooperation  between  two 
MoveExtJ   MoveExtJ  (Move  External  Joints)  moves 
or more robots and an external axis (e.g. linear unit or 
one  or  several  mechanical  units  without 
TCP.   turntable).  The  master  is  linked  to  a  mobile  external 
MoveExtJ is used to move additional axes,  axis  and  performs  geometrically  coupled  tasks 
in a task without any robot.   together  with  a  second  robot  mounted  on  the  external 
Table 1. Each instruction in MultiMove function for ABB robots  axis.  
 
2.2 Introduction of RoboTeam function for KUKA robot   A  general  introduction  of  programming  instructions  in 
RoboTeam  function  for  KUKA  robots  is  presented  in 
As  the  aforementioned  MultiMove  function  of  ABB  Table 2. These instructions are all included in KRL (robot 
robot,  RoboTeam  function  [12]  is  the  similar  function  programming language for KUKA robot) instructions for 
for  KUKA  robots.  The  RoboTeam  application  package   KUKA KRC2 robot controller.  
   
   

4 Int. j. adv. robot. syst., 2013, Vol. 10, 282:2013 www.intechopen.com

 Instruction  Description   Instruction  Function  Example 
PROGSYNC   PROGSYNC  makes  it  possible  to  start  the  SMOVL   While coordinating the slave  SMOVL 
continuous  path  motions  of  cooperating  side with the master side,  V=150  
robots  simultaneously.  Irrespective  of  what  SMOVL moves the slave side  + MOVL  
motions  they  have  been  executing  before,  manipulator to teaching 
program  synchronization  forces  a  position with linear 
simultaneous  motion  start  for  all  involved  interpolation. This is a 
robots  at  synchronization  point  t x .   The  coordinated move instruction 
controllers  then  resume  execution  of  their  to the slave side manipulator.  
programs.   SMOVC   While coordinating the slave  SMOVC 
ENTERSPACE   ENTERSPACE  permits  the  robot  that  is  side with the master side,  V=150 
approaching  the  workspace  most  quickly  to  SMOVC moves the slave side  NWAIT  
enter it. Slower robots are stopped.   manipulator to teaching  + MOVJ  
EXITSPACE   EXITSPACE  orders  the  robot  that  is  in  the  position with circular 
workspace  to  leave  it  and  enables  the  interpolation. This is a 
workspace.  The  next  robot  in  a  defined  coordinated move instruction 
sequence is granted permission to enter.   to the slave side manipulator.  
GEOLINK   The  GEOLINK  command  couples  a  robot  SIMOV   While coordinating the slave  SIMOV P000 
(slave) with the base system of another robot  side with the master side,  V=138 PL=1 
(master).  When  the  master  is  jogged,  the  SIMOV moves the slave side  +IMOV P001 
slave  follows  its  motions.  A  geometric  manipulator to teaching 
coupling  can  be  canceled  by  selecting  any  position by only the specified 
base reference that is not linked to the master  increments with linear 
(e.g. NULLFRAME).   interpolation.  
SYNC   The  command  SYNC  is  used  to  synchronize  SREFP   During coordinated  SREFP 1  
individual  motion  blocks  of  cooperating  movement, SREFP specifies a 
controllers  (MotionSync).  Motions  of  several  reference point such as wall 
robots can be synchronized so that each robot  point for weaving. This is a 
requires  the  same  amount  of  time  for  these  reference point instruction to 
motions.   the slave side manipulator.  
The  command  SYNC  is  a  supplementary  +MOVJ   +MOVJ moves the master side  MOVL=138 
component that can be called and added to a  manipulator to the teaching  PL=0  
LIN or CIRC motion block.   position with joint  + MOVJ  
SyncCmd()   SyncCmd  enables  program  and  motion  interpolation. This instruction 
synchronization.   should always be placed after a 
RemoteCmd()   RemoteCmd  makes  it  possible  to  send  coordinated move instruction 
commands  to  other  controllers.  Command  (individual interpolation). This 
execution  on  the  local  controller  is  is a coordinated move 
interrupted  for  the  duration  of  execution  on  instruction to the master side 
the remote controller.   manipulator.  
LK()   The LK function (“Linked Kinematic”) allows  +MOVL   +MOVL moves the master side  MOVL V=276
the geometric coupling of separate kinematic  manipulator to the teaching  + MOVL  
systems  (robots).  Motions  of  external  robots  position with linear 
are adapted to those of the local robot.   interpolation. This instruction 
should always be placed after a 
Table 2. Instructions in RoboTeam function for KUKA robots 
coordinated move instruction, 
coordinated interpolation, 
2.3 Introduction of Independent/Coordinated function for 
individual interpolation. This is 
Motoman robot   a coordinated move instruction 
to the master side manipulator.  
Reasons  for  using  multi‐robot  technology  include  +IMOV   IMOV  P000 
+IMOV moves the master side 
reduced  cycle  time,  compact  systems,  jigless  production  V=138  PL=1 
manipulator by only the  
and  more  flexible  manufacturing.  Also,  programming  is  specified increment with linear  RF  
simplified  and  is  made  in  shorter  time  as  compared  to  interpolation.   +IMOV P001 
programming  clusters  of  single‐robot  systems.  A  single  PSTART   This instruction starts a job.   PSTART  JOB: 
cell  with  multiple  robots  and  a  single  controller  is  ideal  TEST‐1 SUB1 
for  symmetrical  workpieces,  multiple  circular  welds  or  PWAIT   This instruction waits for  PWAIT SUB1 
completion of subtask.  
distortion‐critical  parts.  In  such  applications,  multi‐robot 
TSYNC   This instruction synchronizes  TSYNC 1 
technology  not  only  greatly  increases  efficiency  but  also  different tasks.   SNUM=3  
improves  quality,  particularly  in  cases  where  multiple 
Table 3. Instructions in Independent/Coordinated function for 
welds  must  be  performed  and  temperature,  gas  and  YASKAWA Motoman robots 
metal flow must be exactly regulated.  

www.intechopen.com Yahui Gan, Xianzhong Dai and Dongwei Li: Off-Line Programming Techniques for Multirobot Cooperation System 5
 A  single  NX100/DX100  controller  can  control  up  to  8  need  in  their  cooperation  control.  Such  a  centralized 
robots,  up  to  72  axes  in  total  including  robots  and  control  structure  of  ABB  robot  has  limited  ability  and 
external  axes,  providing  unmatched  ability  to  handle  only  4  robots  can  be  involved  in  1  cooperative  motion 
multiple  tasks  and  synchronous  coordination.  maximally.  The  Independent/Coordinated  function  of 
Consequently  a  robot  in  the  multi‐system  knows  the  Motoman robot are most flexible in system structure. This 
positions  of  the  other  robots.  This  means  that  costly  flexibility  has  a  direct  impact  on  their  instruction  format 
downtime  and  production  fall‐outs  caused  by  colliding  and numbers of controller for their cooperative function.  
robots could be substantially reduced.  
  3. Path planning principle of basic cooperative motion  
Two  or  more  robots  with  a  single  controller  can  be 
Since  aim  of  this  paper  is  to  investigate  the  OLP 
programmed  to  work  independently  or  synchronously. 
techniques  for  multirobot  cooperation  system,  only  the 
Various  control  combinations  are  possible  so  that 
cooperation  functions  that  currently  have  been  provided 
multiple robots perform completely different tasks at the 
by  robot  manufacturers  are  considered  in  this  paper.  To 
same  time,  the  same  task  simultaneously  or  are 
summarize  the  functions  introduced  in  Section  2,  there 
coordinated  to  perform  different  steps  of  the  same  task. 
are  only  3  cooperative  motions  considered  here, 
Multi‐robot  technology  is  ideal  for  jigless  manufacturing 
concurrent  cooperation,  coupled  synchronous 
in  which  one  robot  holds  the  workpiece  while  another 
cooperation  and  combined  synchronous  cooperation.  In 
performs a welding or machining operation.  
  addition,  the  discussions  here  for  robot  path  planning 
Table  3  presents  a  general  introduction  of  the  only  involve  the  kinematic  aspects.  Incorporating 
programming  instructions  in  Independent/Coordinated  dynamics  into  motion  planning  still  requires  further 
function  for  YASKAWA  Motoman  robots.  These  investigation and not mentioned here.  
instructions  are  all  included  in  INFORM  (robot 
3.1 Classification of basic cooperative motions  
programming  language  for  Motoman  robot)  instructions 
for Motoman NX100/DX100 robot controller.   In  reference  [14],  cooperative  motions  for  multiple  robot 
systems have been classified into three types according to 
2.4 Comparison of the aforementioned multirobot functions  
relative motions between end‐effectors of individual robot, 
In  order  to  make  a  comparison  of  advantages  and  which  is  concurrent  cooperation,  coupled  synchronous 
disadvantages  of  the  aforementioned  multirobot  cooperation and combined synchronous cooperation. Since 
cooperative functions, Table 4 is listed here to show their  cartesian  trajectory  of  cooperative  motion  in  robot  joint 
detailed specifications.   space is hard to imagine, only cooperations between robots 
  in cartesian space is considered here.  
Item  ABB  KUKA  Motoman 
Independent A. Concurrent cooperation  
Function Name  MultiMove  RoboTeam 
/Coordinated
Appearance time  2004  2005  2004  Irrespective  of  what  motions  they  have  been  executing 
Max number of  before,  a  simultaneous  motion  start  time  is forced  for  all 
4  15  8 
robota  robots  at  synchronization  point t 0 . No  position  or 
Number of  orientation constraints exist in this type of cooperation.  
1  n  b  1 or n 
controller 
Ethernet &  Windows  B. Coupled synchronous cooperation  
Communication 
Safety signal  &  IEEE 1394 
interface 
cable  VxWorks  Irrespective  of  what  motions  they  have  been  executing 
Instruction format  1‐1c  1‐1  1‐n d  before,  a  simultaneous  motion  start  time  is forced  for  all 
robots  at  synchronization  point t 0 . All  robots  are 
a Max number of robot involved in 1 cooperative motion process  

b Number of the robot involved in the cooperative process  
synchronized  and  perform  identical  line  or  circle  arc 
c 1 cooperative instruction for 1 robot cooperative motion  
motions  and  no  relative  motion  exists  between  master 
d 1 cooperative instruction for n robot cooperative motion  
and slave end‐effectors.  
Table 4. Comparison of specifications for different multirobot   
cooperative function  The  slave  robot  follows  the  motions  of  the  master  robot, 
without executing motion blocks of its own. This form of 
In  Table  4,  it  is  clear  that  the  RoboTeam  function  of 
cooperation is mostly used in load sharing task. Figure 1 
KUKA  robot  has  the  biggest  ability  to  control  up  to  15 
illustrates  a  typical  two  robots  cooperative  system 
robot.  Meanwhile,  its  control  structure  is  the  most 
performing the coupled synchronous cooperation in load‐
complicated  because n controllers  are  needed  for 
sharing  mode.  In  such  a  cooperation  motion,  the  slave 
RoboTeam  function.  The  MultiMove  function  of  ABB 
robot  requires  no  separate  motion  commands  of  its  own 
robot  has  the  simplest  structure  and  only  1  controller  is 
because it follows the motion of the master directly.  

6 Int. j. adv. robot. syst., 2013, Vol. 10, 282:2013 www.intechopen.com

 Therefore, path planning problem for a single robot is to 
identify two robot positions for line motion and three for 
circle  arc  motion  in  robot  base  frame.  However,  when  it 
comes  to  multiple  robots  cooperation  system,  things 
become much more complex.  
 

 
Figure 1. Two robots cooperating for transportation in coupled 
synchronous motion.  

C. Combined synchronous cooperation 

Irrespective  of  what  motions  they  have  been  executing 

before, an identical motion time is forced for all robots in 
the synchronization period t. The master robot performs 
basic  line  or  circle  arc  motion,  while  the  slaves  perform   
Figure 2. Two robots cooperating for welding in combined 
different  motion  blocks  relative  to  end‐effector  frame  of 
synchronous motion.  
master,  producing  a  superposed  motion  on  the  basic 
motion of master robot.   A  typical  two  robots  cooperative  system  for  welding  is 
  shown  in  Figure  3.  For  such  a  cooperation  system,  the 
The  slave  robot  follows  the  basic  motions  of  the  master  path planning problem has many differences with single 
robot,  but  also  executes  motion  blocks  of  its  own.  This  robot  system.  First,  many  cartesian  frames  exist,  such  as 
form  of  motion  is  used  in  process‐dependent  mode.  the  absolute  world  frame,  each  robot  base  frame,  robot 
Figure  2  shows  a  typical  combined  synchronous  tool  frame  and  some  user  defined  frame.  Second, 
cooperation of two robots for welding. In such a case, the  trajectory  description  for  welding  robot  only  distinctly 
slave  robot  processes  the  workpiece  while  it  is  being  exist  relative  to  workpiece  frame,  which  is  a  moving 
transferred from one station to another by the master. The  dynamic  frame.  The  trajectory  description  for  welding 
master  acts  as  a  transportation  and  positioning  robot,  robot  in  its  base  frame  or  absolute  world  frame  is 
while the slave is used as a processing robot. During the  unobvious, which makes the trajectory planning problem 
transferring  process,  the  master  keeps  the  workpiece  beyond  capabilities  of  conventional  robot  controller. 
constantly in an optimal processing position. The relative  Third,  simultaneous  motion  start/stop  and  motion 
position and orientation between the workpiece and tool  synchronization  have  to  be  realized  between  different 
is retained during motions of the workpiece.   robot  controllers.  By  far,  trajectory  planning  problem  for 
  multiple  robot  cooperation  systems  can  be  formed  as 
Although the above classification may not be exhaustive,  following:  
it covers the most application cases for industrial process. 
 

Most of all, the above 3 cooperation types include all the 
cooperative functions mentioned in Section 2.  

3.2 Path planning for coupled synchronous cooperation  

In conventional robotic systems, path planning is usually 
carried  out  in  two  spaces,  the  cartesian  space  and  robot 
configuration  space.  Robot  base  frame  is  the  frequently 
used  cartesian  space  where  Continuous‐Path  trajectory 
including  line  motion  and  circle  arc  motion  is  planned. 
Robot  tool  frame  and  user  defined  frame  also  are 
cartesian  spaces,  but  they  are  seldom  used  for  single 
robot system. Robot configuration space is conventionally   
used  in  the  Point‐To‐Point  trajectory  planning  problem  Figure 3. Schematic diagram of two robots cooperative system 
and  will  not  be  suitable  for  arc  welding  application.  for welding.  

www.intechopen.com Yahui Gan, Xianzhong Dai and Dongwei Li: Off-Line Programming Techniques for Multirobot Cooperation System 7
 Cooperative path planning for a multiple robots system is  Substituting equation (1) into (2) at time t  t 0 yields 
to  identify  one  robot  as  master  and  the  other  as  slaves, 
determine  two  cartesian  positions  for  line  motion  and  mb
Pm  0   m
Hs  mb Hsb  sb Ps  0                     (3) 
three  cartesian  positions  for  circle  arc  motion  in  master   
base  frame  for  master  robot.  For  coupled  synchronous  By equation (3), we have  
cooperation, no further information needs to be collected 

 
for  slaves.  For  concurrent  cooperation  or  combined  1
m
Hs  mb
Pm  0   sb
Ps  0   sb Hmb                  (4) 
synchronous  cooperation,  determine  two  cartesian   
positions for line motion and three cartesian positions for 
circle  arc  motion  in  slave  base  frame  for  slave  robots.  As  the  definition  of  coupled  synchronous  cooperation,
m  
After  that,  plan  nominal  trajectories  in  configuration  Hs will  be  hold  constant  during  the  entire  period  of 
space  for  each  robot  by  these  collected  information  to  coupled synchronous cooperation, which means  
achieve cooperative motions between master and slave.   mb
Pm  t   m
Hs  mb Ps  t 
 
In  the  above  3  cooperation  types,  no  motion  constraints   m
Hs  mb Hsb  sb Ps  t 
exists  for  concurrent  cooperation.  Therefore,  cooperative   (5)  
 
1
 mb
Pm  0   sb
Ps  0   sb H mb  mb Hsb  sb Ps  t 
path  planning  strategy  is  not  needed  for  this  type  of 
0   P 0 
1
cooperation.  In  the  following  part,  the  cooperative  path   mb
Pm sb
 sb Ps  t 
s
planning  problem  is  only  investigated  for  the  rest  two   
cooperations,  coupled  synchronous  cooperation  and 
By equation (5), we have  
combined synchronous cooperation.  
 
 
1
Consider  two  robots,  each  with n joints,  handling  a 
sb
Ps  t   sb
Ps  0   mb
Pm  0   mb Pm  t              (6) 
 
voluminous rigid body object (as shown in Figure 1) that 
is  beyond  the  payload  capacity  of  any  individual  robot.  Equation  (6)  expresses  the  holonomic  constraints  for  the 
To move the object, two robot end‐effectors must grasp it  position and orientation between master and slave robots 
at  two  specified  points.  It  is  assumed  that  the  end‐ during  their  coupled  cooperation  motion.  This  equation 
effectors  furnish  tight  grips  so  that  there  are  no  relative  also  implies  that  the  slave  trajectory sb Ps  t  in  its  base 
motions among the end‐effectors and the object. Followed  frame can be uniquely determined in terms of the master 
by the definition of Coupled synchronous cooperation, no  trajector mb Pm  t  and  relative  position/orientation
relative  motion  exists  between  master  and  slave  end‐ mb
Pm  0  at  the  initial  time  of  coupled  cooperation.  This 
effectors  once  their  motion  have  been  coupled,  which  equation  establishes  the  theoretical  foundation  of  our 
means  relative  position/orientation  between  master  end‐ cooperative  path  planning  method  for  coupled 
effector and slave end‐effector will hold const during the  synchronous cooperation.  
entire period of cooperation.  
  3.3 Path planning for combined synchronous cooperation  
Let  the  homogenous  matrix mb Pm  t    44 be  the 
Consider two robots cooperate for a jigless welding process 
position/orientation of master robot in master base frame 
as  shown  in  Figure  2.  Here,  the  master  robot  holds  the 
and sb Ps  t    4 4 be  the  position/orientation  of  slave 
workpiece while the slave holds a processing tool. In such 
robot  in  slave  base  frame  at  time t. Let  coordinates  for 
a case, motion trajectory for master robot must be specified 
slave end‐effector in master base frame be mb Ps  t    44 ,
beforehand. Whereas, slave trajectory can not be specified 
we have  
directly  and  it  must  be  determined  by  the  processing 
requirement  in  order  to  achieve  a  cooperative  motion 
mb
Ps  t   mb
Hsb  sb Ps  t                            (1)  
  which  is  a  combined  one.  Usually,  the  processing 
requirement  can  only  be  given  in  workpiece  frame.  It  is 
where mb Hsb   44 is  the  transformation  matrix  from 
supposed  that  no  relative  motion  is  allowed  when  the 
slave  base  frame  to  master  base  frame.  Once  the  robots 
master  robot  holds  the  workpiece.  In  such  a  supposition, 
have  been  mounted,  their  base  will  not  be  changed 
processing requirement can also be specified or converted 
during  the  entire  period  of  cooperation.  So mb Hsb will  be 
to  the  master  endeffector  frame  because  a  constant 
a  constant  homogeneous  transformation  matrix  during 
transformation matrix exists between the workpiece frame 
the  entire  process.  Let t0 be  the  simultaneous  start  time 
and  master  end‐effector  frame.  Constraint  relations  for 
for mb Pm  t  and  sb Ps  t  . Let  m Hs  t    4 4 be  the 
      such  cooperative  motions  of  the  master‐slave  robots  will 
transformation  matrix  from  slave  end‐effector  to  master 
then be different from that of the coupled case. Unlike the 
end‐effector in master base frame at time t 0 , which means   constant relation in the above case, a definite time‐varying 
constraints of the processing requirement must be retained 
mb
Pm  0   m
Hs  mb Ps  0                            (2) 
  during the combined cooperation.  

8 Int. j. adv. robot. syst., 2013, Vol. 10, 282:2013 www.intechopen.com

Let mb Pm  t  be  the  motion  trajectory  for  master  robot  in  processes that provide explicit support to multiple robots 
its  base frame.  Let me Ps  t  be  the  processing  requirement  cooperative  motions.  For  consistency,  basic  assumptions 
in  master  end‐effector  frame,  which  is  also  the  slave  for  cooperative  programming  are  the  same  adopted  as 
motion  trajectory  in  master  end‐effector  frame.  By  robot  described in the previous sections. That is,  
inverse  kinematics,  trajectory  representation mb Pm  t  can   
be  converted  to  master  joint  space  for  executing  the  a. Instructions  must  be  provided  which  allow  the  user 
motion.  While  the  slave  trajectory me Ps  t  must  be  to specify the role of each robot or device involved in 
converted  from  the  master  end‐effector  frame  to  slave  the  cooperation  process.  Each  robot  or  device  must 
base  frame  in  order  to  execute  the  motion.  By  be  identified  as  a  master  or  slave.  A  master  often 
homogeneous transformation, we have   plays the role of holding and moving the workpieces, 
such  as  a  positioning  table  or  transporting  robot.  A 
sb
Ps  t   sb
H mb  mb H me  t   me Ps  t                  (7)   slave  often  plays  the  role  of  task  processing  on  the 
  workpieces,  such  as  a  welding  robot,  a  spraying 
where sb Hmb is  the  transformation  matrix  from  master  robot and so on.  
base  frame  to  slave  base  frame, mb H me  t  is  the  b. Instructions  must  be  provided  which  achieve  the 
  cooperative  motions  between  master  and  slaves. 
transformation  matrix  from  master  end‐effector  frame  to 
master  base  frame.  As  the  definition  of  robot  forward  These cooperative motions include all the previously 
kinematics, mb H me  t  is  the  inverse  of me H mb  t  , the  mentioned  types,  concurrent  cooperation,  coupled 
  synchronous  cooperation  and  combined 
position/orietation of robot end‐effector in its base frame,  
synchronous cooperation.  
 
   
1 1
mb
Hme  t   me
Hmb  t  mb
Pm  t              (8)  
  A  general  structure  of  instructions  for  cooperative 
programming  is  presented  in  reference  [15].  Inspired  by 
Substituting (8) to (7) yields,   their  proposal,  prototype  instructions  for  our 
classification are presented here, which is developed and 
 
1
  sb
Ps  t   sb
Hmb  mb
Pm  t   me Ps  t               (9) different  from  reference  [15].  These  specific  instructions 
for  cooperative  robot  motions  can  be  realized  as  an 
Equation  (9)  expresses  the  holonomic  constraints  for  the  incremental part for traditional robot controllers. Figure 4 
position and orientation between master and slave robots  shows  the  function  blocks  for  cooperative  motion 
during their combined cooperation motion. This equation  package  as  an  incremental  part  for  traditional  control 
also  implies  that  the  slave  trajectory sb Ps  t  can  be  systems of industrial robot.  
uniquely  determined  in  terms  of  counterpart mb Pm  t  of 
the master and task processing requirement me Ps  t  . This 
equation  establishes  the  theoretical  foundation  of  our 
cooperative  path  planning  method  for  combined 
synchronous cooperation.  

4. Software architecture  

4.1 Extended prototype instructions for cooperative motion  

The  theoretical  development  in  the  above  sections  is  a 

necessary  step  to  achieve  the  cooperative  path  planning 
and  job  programming  for  multiple  robots  cooperative 
systems.  However,  traditional  programming  languages 
for  industrial  robot  are  usually  oriented  towards  single 
robot  operation.  In  order  to realize  the  above  mentioned 
three  cooperations,  concurrent  cooperation,  coupled   
synchronous  cooperation  and  combined  synchronous  Figure 4. Function blocks for cooperative motion package.  
cooperation,  present  robot  programming  languages  need 
In  the  following,  for  the  sake  of  clarity,  instructions  of 
to be extended.  
cooperative robot control are classified into three distinct 
 
subsets.  
For  this  aim,  an  extension  of  a  prototype  programming 
language has been devised here by defining a set of high  4.1.1 Instructions for cooperation setting  
level  instructions  to  support  the  above  cooperations  for 
master‐slave robots. This is also a main pathway to foster  This  set  of  instructions  is  used  to  construct  or  release  a 
the  application  of  multiple  robots  systems  in  industrial  multiple robots cooperative system. A component can be 

www.intechopen.com Yahui Gan, Xianzhong Dai and Dongwei Li: Off-Line Programming Techniques for Multirobot Cooperation System 9
 added  or  removed  from  the  cooperative  system  by  such  and  
instructions. When a component is added, its role must be 
specified  as  master  or  slave  at  the  same  time.  Prototype  MOVCIRC [POS, VIA] VEL=[VAR] [FLYBY]
instructions are listed below,  
which  realize  a  continuous  linear  or  circular  path  in 
SETCOOP [ID_STRING]  cartesian  space.  Here,  argument POS is  the  cartesian 
[Rbt1, Rbt2,   , RbtN] [Role1, Role2,   , RoleN]   position  destination  to  be  reached,  argument VIA is  the 
via  cartesian  position  for  circular  path,  argument VAR
or   specifies the path velocity during the motion. FLYBY is an 
optional  argument  which  indicates  that  with FLYBY the 
ADDCOOP [ID_STRING]  robot  will  go  through  this  intermedius  position  without 
 
[Rbt1, Rbt2,   , RbtN] [Role1, Role2,   , RoleN] stopping while without FLYBY it will stop.  

Here, ID_STRING is  a  user  specified  command  name,  4.1.3 Motion instructions for cooperative robots  

 
Rbt1, Rbt2,   , RbtN is  the  robot  names  involved  in  the 
cooperative  process,  Role1, Role2,   , RoleN is  the  Instructions  in  this  subset  are  to  start  a  cooperative 
corresponding  roles  for  each  robot,  and  values  for motion between multiple robots. The instrcution  
Role1, Role2,   , RoleN must be MASTER or SLAVE .   CONCURRENT 
The instruction   [ID_STRING] [R1, R2,   , Rn] [WAIT/NO_WAIT]
RELEASECOOP 
  is  to  start  the  previously  mentioned  concurrent 
[Rbt1, Rbt2,   , RbtN] FROM [ID_STRING] cooperation process. Here, ID_STRING is a user specified 
 
command  name,  R1, R2,   , Rn is  the  robot  names 
removes  the  specified  components Rbt1, Rbt2,   , RbtN
involved  in  this  cooperative  process.  The WAIT option 
from the cooperative set specified as ID_STRING.   
causes the robot to wait on reaching this command until 
4.1.2 Motion instructions for noncooperative robots   all  the  other  robots  have  reached  this  command.  The
NO_WAIT option  causes  the  robot  not  to  wait  on 
Instructions in this subset are executed only by robots not  reaching  this  command  but  merely  to  communicate  its 
declared  as  cooperative.  They  are  usually  used  to  arrival to the other robots and the robot continues its path 
program  movements  to  be  executed  independently  from  motion without interruption.  
the  other  components  in  the  cooperative  set.  Usually,   
they  are  already  part  of  the  standard  instruction  set  of  The instruction  
industrial  robot  programming  languages,  and  are 
COUPLED [ID_STRING] [Rs1, Rs2,   , RsN] TO [Rm]
presented  here  only  for  the  sake  of  completeness.  They 
can  command  a  joint  space  motion  or  a  cartesian  space 
is  to  start  the  previously  mentioned  coupled 
motion.  
synchronous  cooperation  process.  Here, ID_STRING is 
   
a  user  specified  command  name,  Rs1, Rs2,   , RsN is 
Prototype instructions for joint space motion are  
names of slave robots and Rm is name of master robot. 
MOVJOINT [POS] VEL=[VAR]   Numbers of slave robots can be single or multiple, but 
number  of  master  robot  must  be  single  per  one
and   COUPLED command.  
 
MOVAXES [POS] VEL=[VAR] The instruction  

which realize a point to point motion in joint space. Here,  COMBINED [ID_STRING] [Rs1, Rs2,   , RsN] TO [Rm]

argument POS is  the  joint  position  destination  to  be 
reached, argument VAR specifies the joint velocity during  is to start the previously mentioned combined synchronous 
the  motion.  Difference  between  instructions  of cooperation process. Here, ID_STRING is a user specified 
 
MOVJOINT and MOVAXES lies  in  that  the  former  is  command  name,  Rs1, Rs2,   , RsN is  names  of  slave 
used  for  6  DOF  robot  while  the  latter  for  1  or  2  DOF  robots and Rm is name of master robot. Numbers of slave 
devices such as a positioning table.   robots  can  be  single  or  multiple,  but  number  of  master 
  robot must be single per one COMBINED command.  
Prototype instructions for cartesian space motion are    
The instruction  
MOVLIN [POS] VEL=[VAR] [FLYBY]
RELEASECOOP 
[Rbt1, Rbt2,   , RbtN] FROM [ID_STRING]

10 Int. j. adv. robot. syst., 2013, Vol. 10, 282:2013 www.intechopen.com

has already been defined above. It can also be used here  4.2 OLP software architecture of multirobot cooperation system  
to  release  the  cooperative  process  defined  by  the  three 
commands  The  above  prototype  instructions  for  multirobot 
cooperation  are  devised  for  bridging  the  simulated  3D 
CONCURRENT,  COUPLED,  and COMBINED.  
visual  environment  to  real  robots.  Key  steps  of  the 
Motion instructions for single/noncooperative robot have  software realization are presented in Figure 5. Part of the 
to  be  modified  here  to  realize  cooperative  motions  class  hierarchies  for  multirobot  OLP  system  is  shown  in 
defined  by  the  above  three  commands Figure 6.  
CONCURRENT,  COUPLED,  and COMBINED. They  are 
list as,  
 
MOVJOINT [POS] VEL=[VAR] COOP=[ID_STRING] [Rbt]
MOVAXES [POS] VEL=[VAR] COOP=[ID_STRING] [Rbt]
MOVLIN [POS] VEL=[VAR] [FLYBY] COOP=[ID_STRING][Rbt]
MOVCIRC [POS, VIA] VEL=[VAR] [FLYBY] COOP=
=[ID_STRING] [Rbt]
 
in  which,  the  augmented  argument  ID_STRING   is  the 
user  specified  command  name  defined  by
CONCURRENT,  COUPLED,  or COMBINED,   argument
 
Rbt is  the  robot  name  that  specifies  the  controller  group 
Figure 5. Key steps of the software realization.  
for this instruction.  

 
Figure 6. Part of the class view of the OLP software.

www.intechopen.com Yahui Gan, Xianzhong Dai and Dongwei Li: Off-Line Programming Techniques for Multirobot Cooperation System 11
  3D  CAD  Model:  This  step  is  to  prepare  the  3D  CAD  program  [16].  SolidWorks  is  an  outstanding  3D  entity 
models  of  robots  and  environment  setups.  These  design  and  modeling  software.  It  is  easy‐to‐use  and  has 
CAD  models  should  be  standardized  and  used  good  performance  in  3D  visualation  and  simulation. 
universally  in  different  3D  CAD  design  softwares,  Besides that, SolidWorks allows secondary development of 
like  Pro/E,  UG,  SolidWorks,  etc.  Nowadays,  the SolidWorks Application Programming Interface (API), 
commercial  industrial  robot  manufactures  always  which  you  can  use  to  automate  and  customize  the 
provide CAD models of their robots in their product  SolidWorks  software.  SolidWorks  API  contains  hundreds 
introduction  webpages,  including  ABB,  KUKA  and  of functions that you can call from Visual Basic 6.0, Visual 
Motoman.  These  models  are  collected  and  involved  Basic for Applications (VBA), Visual Basic .NET, Visual C# 
in our research work. As for robot tools and the other  .NET, Visual C++ 6.0, Visual C++ .NET, or SolidWorks macro 
setups, their CAD models need to be sketched in the  files.  These  functions  provide  direct  access  to  SolidWorks 
aforementioned CAD design softwares.   functionality  such  as  creating  a  line,  inserting  an  existing 
 Kinematic  Modeling:  This  step  is  to  make  clear  part into a part document, or verifying the parameters of a 
relations between robot joint positions and robot tool  surface.  Here,  the  Microsoft  ®  Visual  C++  6.0  is  adopted  as 
postures. Forward kinematics and inverse kinematics  the programming tool in our research work.  
of every robot need to be figured out in this step. The   
only difference of robot kinematic modeling between 
a single‐robot OLP and a multirobot OLP lies in that 
robot  base  frames  relative  to  absolute  world  frame 
must be calibrated beforehand and involved in these 
kinematic equations.  
 Cooperative Path Planning: This step is an unique part 
of  multirobot  OLP  softwares.  Strategies  of 
cooperative  path  planning  have  already  been 
presented in Section 3 of this manuscript. This step is 
to calculate cooperative cartesian path for master and 
slave  robots  by  equation  (6)  or  equation  (9)  with 
robot teach points.  
 Motion  Planning:  This  step  is  to  calculate  joint 
trajectory  for  each  robot.  Strategies  used  in this  step 
are the same with single robot OLP softwares.  
 Simulation: This step is to show a 3D animation of robot   
motions. Techniques of robot 3D animation used in this  Figure 7. Multirobot OLP programme developed with 
SolidWorks ®  2010  
step are the same with single robot OLP softwares.    
 Calibration:  This  step  is  to  make  up  errors  between 
the  simulated  environment  and  the  real  world.  This 
calibration step includes robot base frame calibration, 
robot  tool  calibration,  workpiece  calibration  and  so 
on.  Techniques  used  in  this  step  are  also  the  same 
with single robot OLP softwares.  
 Real  Robot:  This  step  is  to  download  robot  jobs 
generated  by  the  OLP  software  into  real  robot 
controllers.  There  are  usually  some  standard 
communication  interface  (or  software)  for  robot  job 
download, such as Motocom SDK or KUKA.Sim pro.  

5. Software realization result  

For  further  illustration  and  testification  of  the  above 

presented  discussions,  an  OLP  software  for  multirobot 
cooperation  system  is  realized  and  result  of  the 
realization is presented here.  

5.1 Cooperative system configuration and workcell layout  

In the first step of the procedure, the graphical simulation   
of  industrial  robots,  processing  tools,  workpiece  and  Figure 8. Software modules of the developed multirobot OLP 
workspace  is  achieved  using  the  SolidWorks  ®  2010  SP2  programme  

12 Int. j. adv. robot. syst., 2013, Vol. 10, 282:2013 www.intechopen.com

 SolidWorks r 2010 in our lab is shown in Figure 7. Figure 
8  is  the  software  modules  of  our  developed  OLP 
programme  for  multirobot  system.  Figure  9  shows  the 
simulated graphics of workcell layout of exemplary ABB 
robots and Motoman robots in our OLP software. 

5.2 Job files for cooperative motion and its simulation  

In this part, the above proposed cooperation instructions 
are organized into job files to realize the aforementioned 
3  cooperative  motions.  In  the  following  part,  Motoman 
HP20  and  VA1400  robot  are  selected  as  the  exemplary 
robots  for  considered  cooperation  process.  Both  of  the 
two  robots  are  widely‐used  and  high‐performance 
industrial robots. Photographs of the two robots and their 
kinematic  models  are  shown  in  Figure  10.  Denavit‐
  Hartenberg  parameters  of  the  two  robot  are  shown  in 
Figure 9. Simulated graphics of workcell layout in our OLP  Table 5 and 6 respectively.  
software. (a) 2 ABB robots and a positioner; (b) 4 ABB robots; (c)   
2 Motoman robots and a positioner; (d) 3 Motoman robots  
 

 
Table 5. DH parameters for Motoman HP20 robot 
 

Table 6. DH parameters for Motoman VA1400 robot 

  For  coupled  synchronous  motion,  consider  the  example 

Figure 10. Motoman HP20 and VA1400 robot. (a) Photograph of  of  two  robots  cooperating  for  such  a  process:  Firstly,  a 
HP20, (b) Kinematic model of HP20, (c) Photograph of VA1400,  transportation task is considered for the two robot HP20 
(d) Kinematic model of VA1400.   and  VA1400.  At  first,  the  two  robot  move  to  their  home 
positions concurrently and prepare for the transportation 
Since  SolidWorks  programm  supports  many  file  format  task.  Then,  they  move  to  the  grasp  positions  by  point  to 
of  3D  entities,  like  IGES(*.igs),  STEP(*.step,*.stp),  point  motion  in  joint  space.  After  that,  coupled 
STL(*.stl),  VRML(*.wrl),  etc,  these  file  format  for  robots,  synchronous  motions  are  executed  for  both  robots, 
tools,  and  workpiece  can  also  be  supported  in  our  including line path and circular path. After the workpiece 
developed  OLP  software.  This  character  makes  our  being transported to its destination, the two robots will be 
software  open  to  most  industrial  robots  and  easy  be   released from the coupled cooperation process. Using the 
connected to other 3D entities software designed results.  instruction  set  developed  in  the  previous  section,  the 
The  developed  multirobot  OLP  programme  with  assigned task can be programmed via the following code: 

www.intechopen.com Yahui Gan, Xianzhong Dai and Dongwei Li: Off-Line Programming Techniques for Multirobot Cooperation System 13
 SETCOOP       testcoop1  HP20, Master, VA1400, Slave
CONCURRENT   testcoop1   HP20,VA1400   WAIT  
 
MOVJOINT    homepos1    VEL=30%     COOP=testcoop1     HP20
MOVJOINT    homepos2    VEL=30%     COOP=testcoop1     VA1400
RELEASECOOP    testcoop1
  
  
COUPLED    testcoop2    VA1400    TO    HP20
MOVLIN   pos1   VEL=100mm/s   COOP=testcoop2    HP20
MOVCIRC   pos2,viapos2       VEL=100mm/s   COOP=testcoop2    HP20
RELEASECOOP  testcoop2
  
    
 

 
Figure 11. Snapshot of combined synchronous cooperation by two Motoman robots, HP20 and VA1400. 

14 Int. j. adv. robot. syst., 2013, Vol. 10, 282:2013 www.intechopen.com

  
Figure 12. Time evolution of the joint position and joint velocity for Motoman HP20 robot 

 
Figure 13. Time evolution of the joint position and joint velocity for Motoman VA1400 robot. 

In this programm section, only one motion instruction for  combined synchronous motions are executed with HP20 
master  robot  HP20  is  able  to  produce  two  robot  motions  robot  moves  in  line  path  and  VA1400  robot  moves  in 
during the coupled synchronous cooperation. As the above  line  path  and  circular  path  with  respect  to  the 
mentioned,  motions  of  the  slave  robot  VA1400  must  be  workpiece.  In  this  process,  HP20  robot  is  identified  as 
calculated  automatically  after  motions  of  master  robot  the master which holds the workpiece and transports it 
HP20 being taught in order to achieve the coupled motion.   from  one  workstation  to  another.  VA1400  robot  is 
  identified  as  the  slave  which  carries  out  the  welding 
Secondly, a welding task is considered for the two robot  task.  After  the  welding  process  being  finished,  the  two 
HP20 and VA1400. At first, the two robot move to their  robots  will  be  released  from  the  combined  cooperation. 
home  positions  concurrently  and  prepare  for  the  Using  the  instruction  set  developed  in  the  previous 
welding task. Then, they move to the welding positions  section,  the  assigned  task  can  be  programmed  via  the 
by  point  to  point  motion  in  joint  space.  After  that,  following code:  
 

www.intechopen.com Yahui Gan, Xianzhong Dai and Dongwei Li: Off-Line Programming Techniques for Multirobot Cooperation System 15
 SETCOOP       testcoop1    HP20, Master, VA1400, Slave
CONCURRENT   testcoop1     HP20,VA1400    WAIT
MOVJOINT    homepos1   VEL=30%    COOP=testcoop1    HP20
MOVJOINT    homepos2   VEL=30%    COOP=testcoop1    VA1400
RELEASECOOP    testcoop1


COMBINED    testcoop3    VA1400   TO   HP20
MOVLIN    pos1   VEL=50mm/s   COOP=testcoop3   HP20
MOVLIN    pos2   VEL=65mm/s   COOP=testcoop3   VA1400
MOVLIN    pos3   VEL=50mm/s   COOP=testcoop3   HP20
MOVCIRC   pos4, viapos4       VEL=40mm/s   COOP=testcoop3   VA1400
RELEASECOOP   testcoop3

  

 
In  this  programm  section,  individual  motion  instruction  Special  issues  presented  in  this  paper  for  multirobot 
for both master robot HP20 and slave robot VA1400 need  cooperation  system  include  cooperation  motion  analysis, 
to  be  specified.  As  the  above  mentioned,  motions  of  the  cooperative  path  planning  strategy,  cooperative 
slave robot VA1400 needs to be calculated based on both  instructions design and cooperative motion simulation. It 
path  information  of  the  master  and  slave  in  order  to  is  believed  that  these  investigated  techniques  will 
achieve the combined motion.   promote  researches  of  OLP  software  development  for 
  multirobot  cooperation  systems.  Only  basic  problems 
Snapshot  of  the  motion  animations  for  the  two  robots  have  been  touched  in  this  paper.  Technique  details  to 
cooperation process is presented in Figure 11. For clarity  design  an  OLP  software  support  multirobot  cooperation 
reason,  a  square  board  with  a  red  circle  mark  has  been  for commercial use still need to be clarified in our further 
mounted at the end of HP20 robot. Trajectory of the tool‐ research.  
centerpoint  for  VA1400  robot  in  the  task  space  has  be 
marked  by  a  green  curve  while  trajectory  of  the  tool‐ 7. Acknowledgements 
center‐point  for  HP20  robot  in  the  task  space  has  be 
marked  by  a  red  curve  in  Figure  11.  This  cooperative  This work was supported by the National Natural Science 
motion  animation  shows  a  combined  cooperation  Foundation of China under Grant No.61175113, National 
process, in which HP20 moves along a straight line while  High Technology Research and Development Program of 
VA1400 moves around a circle on the board at the end of  China  under  Grant  No.2009AA043903‐1‐1,  No.2007AA 
HP20  robot  simultaneously.  Time  evolution  of  the  joint  041703,  Research  Innovation  Program  for  College 
position and joint velocity for Motoman HP20 robot with  Graduates  of  Jiangsu  Province  under  No.  CX10B_076Z
respect to Figure 11 are shown in Figure 12(a) and Figure  and Scientific Research Foundation of Graduate School of 
12(b)  respectively.  Time  evolution  of  the  joint  position  Southeast University under Grant No.YBPY1302.  
and  joint  velocity  for  Motoman  VA1400  robot  with 
8. References  
respect to Figure 11 are shown in Figure 13(a) and Figure 
13(b) respectively. These data in Figure 12 and 13 are all  [1] Siemens  Product  Lifecycle  Management  Software 
generated  by  our  simulated  robot  path  planner  in  the  Inc.  Robotics  and  automation  workcell  simulation, 
multirobot OLP software.  
validation and off‐line programming [EB/OL].  
6. Conclusion   http://www.plm.automation.siemens.com/zhcn/ 
products/tecnomatix/roboticsautomation/robcad/ 
Techniques  of  devising  an  OLP  software  for  multirobot  index.shtml, avaliable 2012.10.6  
cooperation  systems  are  investigated  in  this  paper.  The  [2] Dassault  Systemes.  DELMIA  Digital  Manufacturing 
discussion  is  focused  on  special  issues  encountered  by  & Production [EB/OL].  
multiple  robot  cooperation  process.  These  issues  can  be  http://www.3ds.com/products/delmia/,avaliable 
recognized  as  an  augmented  part  of  the  conventional  2012.10.6  
OLP  softwares  to  make  them  support  not  only  single  [3] Applied  Computing  &  Engineering  Ltd.  CimStation 
robot but also multiple robots systems.   Robotics [EB/OL].  
  http://acel.squarespace.com/cimstation‐robotics, 
avaliable 2012.10.6  

16 Int. j. adv. robot. syst., 2013, Vol. 10, 282:2013 www.intechopen.com

[4] ABB  Robotics  Corpration.  RobotStudio  Overview  [10] W.M. Shen, J. Gu, Y.D. Ma. 3D Kinematic Simulation 
[EB/OL].   for PA10‐7C Robot Arm Based on VRML. in: Proc of 
http://www.abb.com/product/seitp327/78fb236cae7e6 2007  IEEE  International  Conference  on  Automation 
05dc1256f1e002a892c.aspx, avaliable 2012.10.6   and Logistics (ICAL 2007), pp. 614‐619, 2007.  
[5] KUKA Roboter GmbH. KUKA.Sim Pro [EB/OL].   [11] ABB  Robotics.  ABB  Robotics  Application  manual: 
http://www.kuka‐robotics.com/en/products/software/  MultiMove,  Document  ID:  3HAC021272‐001, 
kukasim/kuka  sim  detail/PS  KUKA  Sim  Pro.htm,  Revision: K, 2007.  
avaliable 2012.10.6   [12] KUKA  Roboter  GmbH.  KUKA.CR  Motion 
[6] Yaskawa  Motoman  Robotics.  MotoSim  EG‐VRC  Cooperation  2.1  For  KUKA  System  Software  (KSS) 
[EB/OL].   5.3/5.4/5.5. Issued: 21 Aug 2007, Version: 00.  
http://www.motoman.com/products/software/default. [13] Yaskawa  Motoman  Robotics.  NX100/NXC100 
php, avaliable 2012.10.6   Options:  Instructions  for  Independent/  Coordinated 
[7] P.  Neto,  J.N.  Pires,  A.P.  Moreira.  Robot  path  control function. Manual NO. RE‐CKIA443, 2004.  
simulation:  a  low  cost  solution  based  on  CAD.  in:  [14] Y.H.  GAN,  X.Z.  DAI,  J.  LI.  Cooperative  Path 
Proc  of  2010  IEEE  Conference  on  Robotics  Planning  and  Constraints  Analysis  for  Master‐Slave 
Automation  and  Mechatronics  (RAM),  pp.  333‐338,  Industrial Robots. International Journal of Advanced 
2010.   Robotic Systems, Vol. 9, 88: 1‐13, 2012.  
[8] S.  Mitsi,  K.‐D.  Bouzakis,  G.  Mansour,  D.  Sagris,  G.  [15] F.Basile,  F.Caccavale,  P.Chiacchio,  J.Coppola, 
Maliaris. Off‐line programming of an industrial robot  C.Curatella.  Task‐oriented  motion  planning  for 
for  manufacturing.  International  Journal  of  multi‐arm  robotic  systems.  Robotics  and  Computer‐
Advanced  Manufacturing  Technology,  Integrated Manufacturing, 2012.28(5):569−582.  
26(3):262C267, 2005.   [16] Dassault  Systemes.  SOLIDWORKS  TUTORIALS 
[9] W.X.  Zhang,  F.S.  Zou,  D.K.  Qu,  F.  Xu.  Research  of  [EB/OL].  
key  technologies  on  3D  simulation  system  of  http://www.solidworks.com/sw/resources/solidworks‐
industrial robot. in: Proc of 7th World Congress on in  tutorials.htm, avaliable 2012.10.6 
Intelligent  Control  and  Automation  (WCICA  2008),   
pp. 565‐568, 2008.  

www.intechopen.com Yahui Gan, Xianzhong Dai and Dongwei Li: Off-Line Programming Techniques for Multirobot Cooperation System 17