Element Coordination/zh-hans

语言:	[[::Element Coordination|English]]  • [[::Element Coordination/zh-hans|中文（简体）‎]]

介绍

此功能的主要目标是几个机器人的空间和时间上运动同步。这将使用系统中存在的标准主 - 从关系将其扩展为通用机器人到机器人连接。将要使用的功能是移动坐标系特性，通常用于传输带跟踪。移动坐标系的源将从简单的轴列表扩展到任何机器人类型的笛卡尔命令（SETPOINT，HERE）。

主机器人是从机器人跟随的移动坐标系的主源。 将使用相同的同步算法，除了与跟踪窗口和触发相关的问题（这两个将是无关紧要的）。

跟踪期间从机器人的相对运动是允许的，在常规的输送机跟踪以相同的方式执行。

机器人的相互空间关系将通过新添加的基坐标系和移动坐标系的对象位置偏移来定义。 与此同时，可以实现不同点类型（世界（机器人）框架）和/或不同NDOF的机器人的相互协作。

	IMPORTANT
	只有在机器人具有相同点类型的情况下，才能使用完整的位置（位置+姿态）。 在具有不同点类型的机器人的情况下，仅跟踪主机器人位置的位置部分（X，Y，Z）。 姿态角（Yaw，Pitch，Roll）将 被忽略

	IMPORTANT
	在具有相同点类型的机器人的情况下，用户能够选择是仅仅在位置或姿态坐标上进行跟踪或者在两者上进行跟踪。请参阅MovingFrame.type属性。

	NOTE
	在跟踪期间检测（监控）轴的位置限制和加速度/速度阈值，方式与常规传送带跟踪相同。

	DANGER
	需要重要强调的是此功能（使用基于机器人的运动坐标系的元素协作）不会阻止机器人碰撞。 机器人防碰撞完全脱离了这个主题。

系统设置

数据创建

ControlStudio中有两种运动参考系（MF）对象：基于轴和基于机器人。它们都以与使用该命令的基于轴的方式以相同的方式创建:

COMMON SHARED <mf name> as moving frame of <mf-type>

基于轴和基于机器人的运动参考系之间的差异在提供给 MasterSource 命令的参数中。在基于轴<u>的MF中，仅使用主轴作为主源。此外，在<u>基于轴<u>的MF中，所有位置MF的属性（零，此处，上行，下行）的点类型与MF的点类型（即<mf-type>）相同。

在<u>基于机器人 的MF的主源是具有自己的点类型的机器人元素。在基于机器人<u>的MF中，MF的位置和机器人的位置之间的关系将使用新引入的属性来定义。 (参考: Translation Transformation )

主源

<Moving Frame>.MasterSource属性将允许将机器人元素的命令（setpoint）或反馈（here）添加为主站，以下句法将有效:

<Moving Frame>.MasterSource = <robot>.setpoint and <Moving Frame>.MasterSource = <robot>.here

	NOTE
	master<robot>的点类型不必与<moving frame>的点类型匹配！ 但是，<moving frame>和从机器人的类型必须匹配！!

MF.TYPE

将主机器人的位置分配给主源会自动在MF和主机器人的位置和方向之间施加一定的关系。下表说明了主站和从站点类型与<MF> .type值之间的关系。

→ 将MasterSource设置为主机器人位置之一（SetPoint或Here）将自动将Moving-Frametype更改为其默认值（参见表）并将其锁定。<u>锁定意味着根据给定的MasterSource，只允许某些MF.type值（表中带有“?”符号）。并且如果用户尝试分配任何其他值，将返回错误。

<mf>.type value	axis-MF	robot-MF pointtype(position)robot = robot-MF pointtype(position)MF or: pointtype(orientation)robot = robot-MF pointtype(orientation)MF	robot-MF neither position or orientation match
0 (linear)	✓(default)	invalid	invalid
1 (rotary)	✓	invalid	invalid
2 (rotary de-coupled)	✓	invalid	invalid
3 (position only)	N/A	✓	✓ (default)
4 (orientation only)	N/A	✓	invalid
5 (both pos. and ori.)	N/A	✓ (default)	invalid

一些最常用的点类型的类型分配表

	master-robot
MF		X	XY	XYZ	XYZR	XYZYPR	YPR	YP
	X	p	p	p	p	p	p	p
	XY	p	p	p	p	p	p	p
	XYZ	p	p	p	p	p	p	p
	XYZR	p	p	p	p/o/po	p	p	p
	XYZYPR	p	p	p	p	p/o/po	o	p (inactive)
	YPR	p (inactive)	p (inactive)	p (inactive)	p (inactive)	o	o	p (inactive)
	YP	p (inactive)	p (inactive)	p (inactive)	p (inactive)	p (inactive)	p (inactive)	o

• p(3) 仅位置
• o(4) 仅姿态
• po(5) 位置和姿态

	NOTE
	在由主机器人点类型不足以驱动的纯方向运动参考系的情况下，类型将被设置为位置（3），但是运动参考系将无效（不能运动

例子 1

common shared MF as moving frame of XYZR
MF.mastersource = SCARA.setpoint

将MF.type自动设置为 5（位置和姿态 - 默认值）!

尝试将其更改为主机不支持的值（例如MF.type = 0）源将返回错误:

例子 2

common shared MF as moving frame of XYZR
common shared gXYZ   as group axnm = a1 axnm = a2 axnm = a3 model=1  of XYZ
MF.mastersource = gXYZ.setpoint

在这种情况下，我们具有相同位置类型的情况，但是具有不同（或不存在）姿态类型的情况。 MF.type自动为3（仅位置）!

例子 3

common shared MF as moving frame of XYZYPR
common shared TILT   as group axnm = a1 axnm = a2 axnm = a3 model=1  of YPR
MF.mastersource = TILT.setpoint

在这种情况下，我们具有相同姿态类型但具有不同（或不存在）位置类型的情况。 MF.type自动为4（仅限姿态）！!

例子 4

common shared MF as moving frame of XYZ
common shared TILT   as group axnm = a1 axnm = a2 axnm = a3 model=1  of YPR
MF.mastersource = TILT.setpoint

在这种情况下，我们有两种点类型没有任何共同之处的情况 因此，类型将自动设置为3（仅位置）。

新属性

运动参考系基坐标偏移

主机和从机器人之间的相互空间关系（位置和姿态）由MF的BASE属性描述。

• <moving-frame>.BASE是一个主机器人到从属的偏移量。 这是一个运动参考系的属性。

对象位置

由两个机器人运动的对象或两个机器人的端点的相对位置彼此描述由 <moving-frame>.OBJECTLOC Moving-Frame属性。它描述从实际主站的源坐标（SetPoint或Here）中从站设定点的相对位置和姿态。它与父MF（或从机器人）保持相同的点类型。

参考: Object Location Property

	NOTE
	OBJECTLOC可用于在连续的拾取和应用中更新新的接触点位置，类似于基于轴的MF的TRIGGER命令。

主从关系

一旦设置了MF参数，则主站和从站位置之间的连接由以下公式定义。

slave.robot = MS2MF( MF.base^-1 : MF.MSource:MF.ObjectLoc )

其中MF.MSource是<master> .setpoint或<master> .feedback

MS2MF函数定义为

Master Source to Master Frame 函数: A = MS2MF(B) 定义为:

A->position = p-projection (B->position)
A->orientation = B->orientation (for MF.types: 4 and 5 only!)

• p-projection是简单的矩阵乘法，形式如下: A->position = TranslationTransformation * B->position

点类型转换

Translation Transformation

与普通轴相反 - MF机器人—MF可以具有与从动机器人不同的点类型。为了将位置从MF点类型转换为从机器人点类型<moving-frame>.TranslationTransformation定义3x3双矩阵属性。

• 定义了MF.MasterSource的点类型到MF的机器人类型的平移（位置）部分的变换矩阵。
• 矩阵阶数通过MF和主机器人的位置维度自动调整。

	Master-Source: XY	Master-Source: XYZ
MF-type: XY	TranslationTransformation[1-2][1-2]	TranslationTransformation[1-2][1-3]
MF-type: XYZ	TranslationTransformation[1-2][1-3]	TranslationTransformation[1-3][1-3]

例如, 定义:

common shared MF as moving frame of XYZYPR
MF.MasterSource = GXY

自动定义:

TranslationTransformation[*][*] = ${\begin{bmatrix}1&0\\0&1\\0&0\\\end{bmatrix}}$

or: TranslationTransformation is 2x3 matrix!

	NOTE
	在MF的位置坐标数少于MasterSource的情况下，剩余的坐标将由 MF.BASE 相应的坐标值分配。

受影响（已更改）命令

激活（同步）

设置<robot>.slave = 5将立即进入同步跟踪模式，不需要触发命令。由于基于机器人MF的工作窗口不存在，MF.ZERO 将在进入"slave=5"时返回当前的MF位置！ 在此之后，从机器人将尝试与运动帧位置同步： MovingFrame(t) = MF(t) - MF(t0)
其中t0是发出"slave=5" 的时刻。 (参考:Absolute_Movements_During_Conveyor_Tracking)

 

其中MF(.)是:

MF(t) = MS2MF( MF.base^-1 : Master(t):MF.ObjectLoc )

Master(t) - 机器人主轴在时刻t的位置。
MS2MF 在Master Source to Moving Frame function定义

与MC-Basic语言变量的关系是显而易见的:

<mf>.here = MF(t)

<mf>.zero = MF(0) (参考MovingFrame.ZERO)

This means that the total slave robot motion of the slave robot that began to track (slave=5, synced or not) is the SAME as position of free slave robot (slave=0) IF the master robot did not move. In other words, if you want to teach some points on a moving object connected to the master robot just stop the master robot and move the slave to its desired destination on the object.

	NOTE
	Movement to MF.ZERO after initialization of tracking causes the slave robot to synchronize exactly to the master robot's location.

Deactivation(DeSyncing)

Setting <robot>.slave = 0 immediately enters into de-synchronization mode, which smoothly reduces tracking velocity to zero. (The part of the velocity induced by tracking not the velocity of added movements).

	NOTE
	In robot-based MF's de-syncing is done using initial values of the movement in cartesain space (position, velocity, acceleration) using the parameters below: VELOCITYDESYNCTRAN , VELOCITYDESYNCROT ACCELERATIONDESYNCTRAN , ACCELERATIONDESYNCROT JERKDESYNCTRAN , JERKDESYNCROT It is possible to activated syncing to another robot or just a plane movement during de-syncing. (Same as axes-based MF's)

Is Moving Frame Synchronized

The Is-Moving-Frame-Synchronized flag will have the same function as in axis-based MF's.

Tracking Parameters

The parameters:

• VelocityMaxTrans, VelocityMaxRot, AccelerationMaxTrans, AccelerationMaxRot, JerkMaxTrans, JerkMaxRot
  
• Dampingfactor, FilterFactor, MaxFlops
  

will be used in the same way as in axis-based MF's. Instead of acting on a scalar distance($dp$) between master axis and tracking variable, cartesian distance (${\vec {d}}p={\vec {p}}_{master}-{\vec {p}}_{track}$) and Euler's angle distance (${\vec {d}}e={\vec {e}}_{master}-{\vec {e}}_{track}$) between master robot position and slave-robot master tracking variable will be used for building criteria of stressful synchronization.

Trigger

As in robot-based MF's the concept of working-window and entering an object into it does not exist, the Trigger command will have no effect on robot-based moving frames. The actual moment of tracking will start always with setting of slave=5 independently of previously used trigger command.

NOI

In case of MF-robot NOI will return always -1.

Is In Window

Is In Window flag will return always 1 (true), actually there is no concept of working windows in this type of MF.

Unused Moving-Frame properties

• Upstream, Downstream, Upmaster, Downmaster
  

As the working-window concept does not exist in robot-based MF's these properties will have absolutely no influence on MF-robot operation.

Next Item command

• NEXTITEM command will have no effects on MF-robot operation.

Moving Frame Coordinate Transformations

Slave robot is connected to a master through Moving-Frame assigned to the slave's master frame property:

<slaverobot>.MasterFrame = <master frame>

Master frame is a link between slave and master robot. It Includes definition of the master-source which can be either robot Cartesian command point (SETPOINT) or robot's Cartesian feedback (HERE):

<master frame>.MasterSource = <masterrobot>.SETPOINT

BASE transformation

Master frame defines spacial relationship (distance and rotation) of the slave's robot frame to the master: <Master Frame>.Base

Defining an Object

In total the object is held by two robots from two sides. Looking from the master's coordinate frame we have two points (in master-robot's world(robot) frame):

<masterrobot>.setpoint
<masterrobot>.setpoint:<movingframe>.objectloc

The second point of the object can be also reached through salve robot by (viewed by master-robot's world(robot) frame):

<movingframe>.base:<slaverobot>.setpoint

<Moving Frame>.ObjectLoc is location property of the Moving Frame data-object of the same point-type as the moving frame. For example, it means if the moving frame was declared as XYZR (common shared MF as moving frame of XYZR), the OBJECTLOC will be also location of XYZR type.

The OBJECTLOC specifies position and orientation of the slave's end-effector relative to the master's end point (Master Frame actually).

Example of complete slave command calculation

mf.base = #{100,100,0,45}
mf.base^-1 = #{-141,100,0,-45}
mf.objectloc = #{80,0,0,180}
master.setpoint = #{130,-72,0,0}

slave.setpoint = mf.base^-1:master.setpoint:mf.objectloc
slave.setpoint = #{-43 , -200 , 0 ,135 }

• The above calculations are true in case both robots are of same (XYZR) point-type and the default MF.type value (5- both position and orientation) is used.

Example of three robots working on a same object

Here is an example of three-robot cooperation. One robot is defined as a master and the other two are slaves. Each of the slave robots is connected through it's master frame to the master robot on different distances from it and on different gripper-points on the object.

In this example we will define two Moving frame with each of them having a different OBJECTLOC.

The first Moving Frame:

Common Shared MF1 As Moving Frame Of XYZR
MF1.MasterSource = <masterrobot>.SETPOINT
MF1.BASE = #{..., ..., ..., 0}
MF1.OBJECTLOC = #{L,..., ..., 180}

The second Moving Frame:

Common Shared MF2 As Moving Frame Of XYZR
MF2.MasterSource = <masterrobot>.SETPOINT
MF2.BASE = #{..., ..., ..., 0}
MF2.OBJECTLOC = #{SQRT(3)*L,L/2, ..., -150}

• Assuming the object is even-sided (Equilateral) triangle of the side length L.

	NOTE
	The orientational part of the second object-location MF's it is -150 degrees. The first slave's robot Xtool axis is in exactly opposite direction to the master's Xtool axis. And the second slave robot's Ytool axis is in exactly opposite direction to the master's Ytool axis.

Algorithms and Software design

• The master slave relationship is based on the same principleas in robot-based MF's as in axis-based MF's. The underling idea is to have same sort of movement if the MF is standing or moving.The principals are described here: Absolute_Movements_During_Conveyor_Tracking
  

• Axis-based moving frame tracking algorithm based on predicting the rendezvous point and limiting the motion by velocity, acceleration and jerk constant is described here: One_Dimensional_Tracking_Algorithm
  

• Same algorithm (tracking) applied on 3-dimensional position vector (Euler angles) is explained here: Position_Tracking_Algorithm
  

• Same algorithm (tracking) applied on 3-dimensional orientation vector is explained here: Orientation_Tracking_Algorithm
  

• Concept of global frame coordinate system as addition to base and world(robot) frames for multiple robot usage is described here:Global Coordinates

• Enlargement of axis-based MF data structures is shown here: Software_Design
  

Examples

Example 1. two different robot kinematics

Cooperation between two unequal robot kinematics.

Moving Frame definition:

Common Shared MF as Moving Frame of XYZR

Linking it to the source (master):

MF.MasterSource = Puma.Setpoint

The master-source is a robot(PUMA) of point-type XYZYPR and the linked robot(SCARA) or the MF is of XYZR point type. In this case the MF.type will be automatically set to 3 (position only). Orientation angle changes of the master robot will have no effects on the slave. So we need to define transformation matrix:

${\begin{bmatrix}X\\Y\\Z\\\end{bmatrix}}={\begin{bmatrix}1&0&0\\0&1&0\\0&0&1\\\end{bmatrix}}\cdot {\begin{bmatrix}X\\Y\\Z\\\end{bmatrix}}$

Or in the code:

' First column:
MF.TranslationTransformation[1][1]=1
MF.TranslationTransformation[2][1]=0
MF.TranslationTransformation[3][1]=0
' Second column:
MF.TranslationTransformation[1][2]=0
MF.TranslationTransformation[2][2]=1
MF.TranslationTransformation[3][2]=0
' Third column:
MF.TranslationTransformation[1][3]=0
MF.TranslationTransformation[2][3]=0
MF.TranslationTransformation[3][3]=1

And then the offsets definitions:

The XY coordinates will be offseted for (10,10) mm:

MF.base = #{10,10,0,0}

A distance of 100mm between the two robots tool-tips is defined as:

MF.ObjectLoc = #{0,0,100,0}

and the tracking (master-slave) is defined by:

Scara.Masterframe = MF

and started:

Scara.slave = 5

Example 2. SCARA and a tilting table

Moving Frame definition :

Common Shared MF as Moving Frame of XYZR

Having a tilt table robot (Object Having only Yaw and Pitch angle):

Common Shared TiltTable As Group Axnm = Ax5 Axnm = Ax6 Model = 1 of YP

Linking it to the source (master):

MF.MasterSource = TilTable.Setpoint

The master-source is a tilt-table of point-type YP and the linked robot or the MF is of XYZR point type. The MF.type will be automatically set to 3 (position only).

Transformation matrix for position actually does not exist as the TiltTable have no position component! So there is nothing to be set here.

And then the offsets definitions:

The XY coordinates will be offseted for 200 mm:

MF.base = #{-200,0,0,0}

Defining the object-location of 100mm makes the trick!

mf.base = #{Xb,Yb,Zb,Rb}
mf.objectloc = #{Xo,Yo,Zo,0}
master.setpoint = #{yaw,pitch}

slave.setpoint = mf.base^-1:master.setpoint:mf.objectloc

i.e. the vector [Xo,Yo,Zo] will be rotated by the tilt-table angles [yaw,pitch]!!!

and the tracking (master-slave) is defined by:

Scara.Masterframe = MF

and started:

Scara.slave = 5

Example 3. Two SCARA's working on a same piece

A robot to robot tracking example:
Two SCARA robots, one master the other is slave.


Setup:
set the slave robot to track the master on a distance of 100mm pointing in face-to face direction (180º)

Common Shared MF as Moving Frame Of XYZR
MF.MasterSource = ScaraMaster
MF.ObjectLoc = #{100,0,0,180}
ScaraSlave.MovingFrame = MF
ScaraSlave.Slave=5

At the moment of engagement (i.e. Slave=5) Zero point is recorded!



Wait to be Synchronized and arriving to master-position together:
System waits until MF is synchronized (Is-Moving-Frame-Synchronized equals 1) and motion towards Zero point is completed (isMoving flag is not positive)

Moves MF.Zero
While ScaraSlave.IMFS <> 1 and ScaraSlave.Ismoving > 0
Sleep 1
End While

Do something, or just stay in tracking mode.


Stopping.De-Synchronize:

slave = 0
while  ScaraSlave.IMFS <> 0
Sleep 1
End While

After this ScaraSlave will be stopped not exactly on the ScaraMaster's path (deviation is more or less random and depends on the master's robot path and joints' deceleration parameters).

Example 4. Coordination

Relative position between the robots during tracking, the slave robot to track the master on a distance of 100mm pointing in face-to face direction (180º)

zoomed detail:

Example 5. PUMA and SCARA on a patch placement job

For setting up global; coordinates see: Global_Coordinates

Geometry

Also see: Global_Coordinates

the given setup can be accomplished in four different ways:

World(Robot) Frame	Base Frame	Global Base	Moving Frame
puma.base = #{0,0,0,0,0,0} scara.base = #{0,0,0,0} Moves puma #{50,0,600,90,90,0} Moves scara #{-100,-100,0,0}	puma.base = #{200,100,0,0,0,0} scara.base = #{100,100,0,0} Moves puma #{250,100,600,90,90,0} Moves scara #{200,0,-100,0}	puma.base = #{200,100,0,0,0,0} puma.gbase = #{0,0,0,0,0,0} scara.base = #{100,100,0,0} scara.gbase = #{0,100,700,0} Moves puma #{250,100,600,90,90,0} Moves scara #{250,100,600,90,90,0}	puma.base = #{200,100,0,0,0,0} scara.base = #{100,100,0,0} puma.globalbase = #{0,0,0,0,0,0} scara.globalbase = #{0,0,0,0,0,0} Moves puma #{250,100,600,90,90,0} MF.MasterSource = puma.setpoint MF.Base = #{200,0,-600,0} MF.ObjectLoc = #{0,0,50,0} scara.MasterFrame = MF scara.slave = 5 Moves scara MF.zero

	NOTE
	All four given code examples will bring the two robots to same positions!

	IMPORTANT
	The "Moving Frame" example takes into account SCARA base coordinates and not the global ones as the MF is declared of XYZR point type.

System setup

definitions:

Common Shared MF As Moving Frame Of XYZR
Common Shared hold As Location Of XYZR
Common Shared patch_feeder As Location Of XYZR

initialization :

SCARA.Base  = #{100,100,0,0}
SCARA.GBASE = #{0,100,700,0,0,0}
PUMA.Base   = #{200,100,0,0}


MF.MasterSource = PUMA.SETPOINT
MF.ObjectLoc    = #{0,0,50,0}
MF.Base         = #{200,0,-700,0}

SCARA.BlendingMethod = 2
SCARA.BlendingFactor = 80
SCARA.MasterFrame = MF

Execution Code

while patches()
   MoveS PUMA MoldPose((PatchNumber()))
   MoveS SCARA patch_feeder
   MoveS SCARA down
   Call TakePatch(SCARA)
   Moves SCARA up
   Moves SCARA hold
   MF.ObjectLoc = MoldProfile(PatchNumber())
   SCARA.slave = 5
   Moves SCARA MF.Zero
   Call GluePatch(SCARA)
   Moves SCARA up
   SCARA.Slave = 0
   Moves SCARA hold
end while

Functions and variables used in the program above:

Function MoldPose( n as long) as location of XYZYPR

Function returning pathc position on the mold in PUMA's coordinate system (e.g. XYZYPR)

Function MoldProfile( n as long) as location of XYZR

Function returning the shape profile of the mold in XYZ coordinates , setting it into OBJECTLOC will effectively set a right position of the SCARA robot on the mold. Returns SCARA locations (XYZR).

Sub TakePatch(robot as generic group)

Subroutine for taking (gripper manipulation, vacuum, waiting, etc) a patch from the feeder.

Sub GluePatch(robot as generic group)

Subroutine for placing the patch on the mold. Here included are all synchronizations needed (wait, gripper open, ...)

MF.Base 

Moving Frame Base offset,

hold

Waiting position

Patch_feeder

Position from where the patches are taken.