Difference between revisions of "Element Coordination/zh-hans"

From SoftMC-Wiki
Jump to: navigation, search
(Created page with "{{Languages}} = Introduction = The main goal of this feature is to synchronize both in space and in time movement of several robots together. This will be done using the sta...")
 
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
{{Languages}}
+
{{Languages|Element_Coordination}}
= Introduction =  
+
=全局坐标概念 =  
  
The main goal of this feature is to synchronize both in space and in time movement of several robots together. This will be done using the standard master-slave relationship that exists in the system by expanding it into a general robot-to-robot connection. The feature that is going to be used is the '''Moving Frame Feature''' typically used in '''conveyor tracking'''.The source of the moving frame will be extended from simple axes list to any robot type cartesian command (SETPOINT, HERE).
+
对于使用不同点类型的''全局坐标概念''的机器人已经被定义。 这允许以一种常见的独特格式给予机器人位置,以独立地观察机器人具有多少轴。 这里使用的关键属性是机器人的[[MC-Basic:robot.BASE|base]]变换,如[[Robot Working Frames|Robot_Working_Frames]]所述
  
The master robot is the master source of a moving frame that the slave robot follows. Same synchronization algorithms will be used except the issues related to the tracking window and triggering (these two will be irrelevant).
+
== 基坐标系属性 ==
 +
机器人有两个笛卡尔坐标系:世界(机器人)坐标系和基坐标系。
  
Relative movements of the slave robot during tracking are allowed and executed in the same way as in regular conveyor tracking.
+
=== 世界(机器人)坐标系 ===
  
The robot's mutual space-relationship will be defined through newly-added base and object location offsets of the moving frame. Together with it, mutual coordination of robots of different point types (world(robot) frame) and/or different NDOF's will be possible.
+
在由''q = (q<sub>1</sub>,q<sub>2</sub>,q<sub>3</sub>, .... , q<sub>n</sub>)''定义的机器人姿势中,n是机器人的NDOF。 世界(机器人)参考坐标由下式定义:
  
 +
<center>'''''p<sub>world</sub> = DirectKinematics (q)'''''</center>
  
{{Note/Important| Only in case of robot's with same point-types the complete location will be used (position+orientation). In case of robots with different point-types only the positional part (X, Y, Z) of the master-robot location will be tracked. Orientation angles (Yaw, Pitch, Roll) '''will be ignored'''}}
+
其中p可以是:p =(x,y,z,偏航,俯仰,滚动)取决于机器人运动学。
  
 +
{{Note|为了简化讨论,我们假定该'''''工具'''''包含在正运动学计算中。这里省略了工件和工作台的坐标系。}}
  
{{Note/Important| In case of robot's with same point-types user is able to select if tracking is done on position '''or''' orientation coordinates only or on '''both''' of them. See [[MC-Basic:movingFrame.TYPE|MovingFrame.type]] property}}
 
  
 +
=== 基坐标系 ===
  
{{Note| Axes' position limits and acceleration/velocity thresholds are checked (monitored) during tracking in the same way as in regular conveyor tracking }}
+
基坐标系是由[[MC-Basic:robot.BASE|robot.base]]属性移动的世界(机器人)坐标系:
  
 +
p<sub>base</sub> = base:p<sub>world</sub>
  
{{Note/Danger|It is important to emphasize that this feature (Element Coordination using robot-based Moving Frame) does '''not''' prevent robot collisions. Robot collision prevention is completely out of this topic.}}
+
其中''':'''是复合运算符。
  
= System Setup =
+
== 全局基坐标属性(全局坐标) ==
  
== Data Creation ==
+
所有用户输入(目标运动指令点,运动参考坐标等)都在基座坐标系中给出。 然而,这些系统可以与机器人不同(例如,R1具有XYZR和R2具有XYZYPR)。 因此,我们假设一个共同的(全局)基坐标系,将所有机器人转换到一个系统:
  
There are two kinds of Moving Frame (MF) objects in ControlStudio: axis-based and robot-based.
+
p<sup>1</sup><sub>global</sub> = '''R1.glbalbase''':R1.base:R1.DirectKinemaitcs(R1.pcmd) <br>
Both of them are created in the same way as axes-based  means using the command:<br>
+
p<sup>2</sup><sub>global</sub> = '''R2.glbalbase''':R2.base:R2.DirectKinemaitcs(R2.pcmd) <br>
 +
p<sup>3</sup><sub>global</sub> = '''R3.glbalbase''':R3.base:R3.DirectKinemaitcs(R3.pcmd) <br>
 +
...<br>
 +
p<sup>m</sup><sub>global</sub> = '''Rm.glbalbase''':Rm.base:Rm.DirectKinemaitcs(Rm.pcmd) <br>
  
<center>'''COMMON SHARED <mf name> as moving frame of <mf-type>'''</center><br>
+
假设系统有''m''个机器人
  
The difference between <u>axes-based</u> and <u>robot-based</u> moving frames is in the argument supplied to the '''[[MC-Basic:movingFrame.MASTERSOURCE| MasterSource]]''' command. In <u>axis-based</u> MF's only axes as master sources are used. Also,in the <u>axis-based</u> MF's the point-type of all location-MF's properties ''(Zero, Here, Upstream, DownStream)'' are same as point type of the MF (i.e. <mf-type>).<br>
+
这是通过添加始终与实际机器人点类型无关的[[MC-Basic:robot.GLOBALBASE|<robot>.globalbase]]位置来实现的,在XYZYPR系统中给出
  
In <u>robot-based</u> MF's master-source is a robot element with its own point-type. In <u>robot-based</u> MF's  the relation between MF's locations and the robot's locations will be defined using the newly introduced properties. ''(See: Translation Transformation )''
 
  
== Master Source ==
+
<div style="background-color:yellow;">
 +
'''为了使全局坐标系尽可能的使用,运动命令(MOVE,MOVES,MOVESKD,CIRCLE ...)的扩展方式除了目前仅允许的机器人点类型的位置之外,还可以接受XYZYPR点类型的位置。
 +
'''
 +
</div>
  
[[MC-Basic:movingFrame.MASTERSOURCE|<Moving Frame>.MasterSource]] property will allow adding robot element's  command (setpoint) or feedback(here) locations as masters, the following sytnax will be valid:
 
  
[[MC-Basic:movingFrame.MASTERSOURCE|<Moving Frame>.MasterSource]] = <robot>.setpoint
+
{{Note|给定的扩展适用于最多6个NDOF(不超过6个)的机器人。}}
and
 
[[MC-Basic:movingFrame.MASTERSOURCE|<Moving Frame>.MasterSource]] = <robot>.here
 
  
{{Note| The point-type of the '''master''' <robot> does not have to match the point-type of the <nowiki><moving frame></nowiki>! <br> However the type of the <nowiki><moving frame></nowiki> and the '''slave''' robot must match!}}
 
  
 +
{{Note| 如果机器人点类型已经是XYZYPR,则全局和基本属性具有绝对相同的功能,可以相互添加。 他们都可以使用,但我们强烈建议只使用一个(而另一个保留为零),以减少混乱。}}
  
=== MF.TYPE ===
 
Assigning master robot's locations to the  master-source automatically imposes certain relationship between the positions and orientations of the MF and the master-robot.
 
'''The following table explains the relationships between master's and slaves' point types and the <MF>.type values.'''
 
  
→ Setting the [[MC-Basic:movingFrame.MASTERSOURCE|MasterSource]] to the one of the master robot locations(SetPoint or Here)  will automatically change the Moving-Frame  '''[[MC-Basic:movingFrame.TYPE|type]]''' to its default value (see the table) and <u>lock it</u>. <u>Locking</u> means that according to the given MasterSource only certain '''MF.type''' values are allowed (those with "✓" sign in the table). And if the user tries to assign any other value an error will be returned.
 
  
 +
与此同时,还有两个新的属性:
  
{| border = "1" valign = "top"
+
* [[MC-Basic:robot.GLOBALSETPOINT|<robot>.globalsetpoint]]类似于常规[[MC-Basic:robot.SETPOINT|<robot>.setpoint]]
|- valign="top" align = "center"
+
* [[MC-Basic:robot.GLOBALHERE|<robot>.globalhere]] 类似于常规[[MC-Basic:robot.HERE|<robot>.here]]
| [[MC-Basic:movingFrame.TYPE|<mf>.'''type''']] value || '''axis-MF'''|| '''robot-MF''' <br> pointtype(position)<sub>robot</sub> = robot-MF pointtype(position)<sub>MF</sub> <br>''or:''<br> pointtype(orientation)<sub>robot</sub> = robot-MF pointtype(orientation)<sub>MF</sub>|| '''robot-MF''' <br> 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
 
|-
 
|}
 
<br>
 
  
 +
== 例子 ==
  
====Type-assignment table for some of the most used point-types ====
+
给定SCARA和PUMA机器人在同一个生产单元中,SCARA机器人在PUMA机器人的上方:
  
{| border = "1" valign = "top"
 
|- valign="top" align = "center"
 
| || colspan="8" |'''master-robot'''
 
|-
 
|rowspan="8"|'''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<br>(inactive)
 
|-
 
|  '''YPR''' || p<br>(inactive) || p<br>(inactive) || p<br>(inactive) || p<br>(inactive) || o || o || p<br>(inactive)
 
|-
 
|  '''YP''' || p<br>(inactive) || p<br>(inactive) || p<br>(inactive) || p<br>(inactive) || p<br>(inactive) || p<br>(inactive) || o
 
|-
 
|}
 
  
* p(3) position only
+
[[File:Global Frames.png]]
* o(4) orientation only
 
* po(5) both position and orientation
 
  
  
{{Note| In case of  pure orientational moving frames driven by inadequate master-robot point type, type will be set to position (3) but the acutall moving frame will be inactive (can not move)}}
+
=== 使用全局坐标系 ===
  
 +
执行以下运动命令:
  
[[File:AXY;MovingFrameType.png]]
+
'''Move scara target<br>
 
+
'''Move puma target<br>
====Example 1 ====
+
其中目标是点类型XYZYPR的位置<br>
<pre>
+
将其转移到每个机器人的基本坐标系中:
common shared MF as moving frame of XYZR
 
MF.mastersource = SCARA.setpoint
 
</pre>
 
Sets MF.type automatically to '''5''' (both position and orientation - default value)!
 
 
 
Trying to change it to a value not supported by the master (e.g. MF.type = 0 ) source will return error:
 
 
 
====Example 2 ====
 
<pre>
 
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
 
</pre>
 
In this case we have situation of same position type but a different (or non-existing) orientation type. The MF.type automatically to '''3''' (position only)!
 
 
 
 
 
====Example 3 ====
 
<pre>
 
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
 
</pre>
 
In this case we have situation of same orientation type but a different (or non-existing) position type. The MF.type automatically to '''4''' (orientation only)!
 
 
 
 
 
 
 
====Example 4 ====
 
<pre>
 
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
 
</pre>
 
In this case we have situation that both point types do not have anything in common ! So, type will be set to 3 (position only) automatically.
 
 
 
= New properties =
 
 
 
== Moving Frame Base Offset ==
 
Mutual space-relationship (position and orientation) between master and slave robots is described by BASE property of MF.<br>
 
 
 
* [[ MC-Basic:movingFrame.BASE| <moving-frame>.BASE]] is an offset of the master robot to the slave. It is a moving-frame's property.
 
 
 
== Object Location ==
 
 
 
Object moved by two robots or the relative position of two robot's end-points to each other is described by '''[[ MC-Basic:movingFrame.OBJECTLOC| <moving-frame>.OBJECTLOC]]''' Moving-Frame property. It describes the relative position and orientation of the slave's setpoint from the actual master's source coordinates (SetPoint or Here). It holds the same point-type as the parent MF (or the slave-robot).
 
 
 
See Also: [[ MC-Basic:movingFrame.OBJECTLOC| Object Location Property]]
 
 
 
{{Note| [[ MC-Basic:movingFrame.OBJECTLOC| OBJECTLOC]] can be used for updating new point-of-contact position in consecutive pick&place applications similar as TRIGGER command in axis-based MF's}}
 
 
 
= Master-Slave Relationship =
 
 
 
Once the MF parameters are set the connection between master and slave positions is defined by the following formula.
 
<center>
 
'''slave.robot = MS2MF( MF.base<sup>-1</sup> : MF.MSource:MF.ObjectLoc )'''
 
</center>
 
 
 
where MF.MSource is either <master>.setpoint or <master>.feedback
 
 
 
=== MS2MF function is defined as: ===
 
 
 
'''M'''aster '''S'''ource to '''M'''aster '''F'''rame function: A = MS2MF(B) is defined as:
 
 
 
A->position    = '''p-projection''' (B->position)<br>
 
A->orientation =  B->orientation (''for MF.types: 4 and 5 only!'') <br>
 
 
 
* '''p-projection''' is  simple matrix multiplication in the form: '''A->position = TranslationTransformation * B->position'''
 
 
 
 
 
<!-- this was original idea:
 
 
 
A->position  = '''p-projection''' * B->position<br>
 
A->orientation= '''q-projection''' * [[AXY:MC-Basic:movingFrame.SLAVEORIENTATION|MF.SLAVEORINETATION]] * B->orientation
 
 
 
 
 
* The <nowiki>* MF.SLAVEORINETATION</nowiki>  represents multiplication by  rotation matrix (quaternion, orientation-vector) for additional orientation vector manipulation.
 
 
 
* '''p-projection''' is a simple projection mapping that copies (X,Y,Z) into/from (X,Y) coordinatewise (X to X, Y to Y, Z to Z).
 
* '''q-projection''' is orientation vector projection, using quaternions it is easily represented by:
 
<br>
 
 
 
if:
 
<math> Q_{XYZ}  = \begin{bmatrix}
 
\varphi & , &  \vec n_{xyz}    \\
 
\end{bmatrix}
 
</math>
 
and: 
 
<math> \vec n_{xyz}  = \begin{bmatrix}
 
nx & ny & nz    \\
 
\end{bmatrix}
 
</math>
 
 
 
<br>
 
Then:
 
<math> Q_{XYZ}  := {qprojection} (Q_{XY} ) =  \begin{bmatrix}
 
\varphi & , &  \vec n_{xy}    \\
 
\end{bmatrix}
 
</math>
 
where <math>  \vec n_{xy}  </math>  by projecting the unit vector <math>  \vec n_{xyz}  </math> tot he XY plane and normalizing it again.
 
 
 
In other words the unit vector of orientation will be immersed into other's robot work-space (keeping it normalized, i.e. ||n|| = 1) while keeping the same rotation angle <math> \varphi </math>.
 
 
 
Due to the fact that projected unit orientation vector is in the same half-space the actual rotation angel sign will be updated.
 
 
 
For example:
 
 
 
Having Yaw-Pitch-Roll space with angles: #{0, 180,90} (vector turned down with roll of 90 degrees) will be projected into Roll space as:
 
 
 
<nowiki>#{-90}</nowiki> =  '''q-projection''' (#{0, 180,90}) , this due to the fact that n<sub>xyz</sub>  is projected into [0,0,-1]
 
 
 
-->
 
 
 
== Point Type transformation ==
 
 
 
<u>Translation Transformation</u>
 
 
 
Contrary to the ordinary axes-MFs robot-MFs can have different point type than the slaved robot. In order to translate location from MF point type into slave-robot point type [[MC-Basic:movingFrame.TranslationTransformation|'''<moving-frame>.TranslationTransformation''']] 3x3 double matrix property is defined.
 
 
 
* defines a transformation-matrix for  of the translation (position) part '''from''' MF.MasterSource's point-type '''to the''' MF's robot-type.
 
* the matrix dimension is automatically adjusted by position dimension of MF and the master robot.
 
<br>
 
 
 
{| border = "1"
 
|-
 
| || 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]
 
|}
 
 
 
 
 
for example, defining:<br>
 
<pre>
 
common shared MF as moving frame of XYZYPR
 
MF.MasterSource = GXY
 
</pre>
 
automatically defines:
 
 
 
[[MC-Basic:movingFrame.TranslationTransformation|TranslationTransformation]][*][*] = <math>
 
\begin{bmatrix}
 
1 &  0    \\
 
0 &  1    \\
 
0 &  0    \\
 
\end{bmatrix}
 
</math>
 
 
 
or: '''TranslationTransformation is 2x3 matrix!'''
 
 
 
{{Note| In case when number of position coordinates of MF is less then of MasterSource the remaining coordinate will be assigned by the '''MF.BASE''' corresponding  coordinate value.}}
 
 
 
 
 
 
 
<!--  This was just an idea but I want to keep it here as a reminder:
 
 
 
=== Orientation Transformation ===
 
 
 
* defines a matrix for the transformation of the orientation part '''from''' MF.MasterSource's point-type '''to the''' MF's robot-type.
 
* the matrix dimension is automatically adjusted by position dimension of MF and the master-source robot.
 
* automatic matrix-dimension adjustment:
 
 
 
{| border = "1"
 
|-
 
| || Master-Source: Roll ||Master-Source: Pitch Roll || Master-Source: Yaw Pitch Roll
 
|-
 
|MF-type: Roll  || TranslationTransformation[1][1] || TranslationTransformation[1-2][1] || TranslationTransformation[1-3][1]
 
|-
 
|MF-type: Pitch Roll || TranslationTransformation[1][1-2] || TranslationTransformation[1-2][1-2] || TranslationTransformation[1-3][1-2]
 
|-
 
|MF-type: Yaw Pitch Roll || TranslationTransformation[1][1-3] || TranslationTransformation[1-2][1-3] || TranslationTransformation[1-3][1-3]
 
|}
 
 
 
 
 
for example:<br>
 
defining:
 
<pre>
 
common shared MF as moving frame of XYZR
 
MF.MasterSource = PUMA.Setpoint
 
</pre>
 
automatically defines:
 
 
 
[[AXY:MC-Basic:movingFrame.OrientationTransformation|OrientationTransformation]][*][*] = <math>
 
\begin{bmatrix}
 
0 &  0  & 1  \\
 
\end{bmatrix}
 
</math>
 
 
 
or: '''OrientationTransformationis 3x1 matrix!'''
 
 
 
== Point Type transformations ==
 
 
 
Contrary to the ordinary axes-MF robot-MF can have different point type from the slaved robot. In order to transform from MF point type into slave-robot point type new property has been defined. The transformation is looking for the closest location inside slave-robot working space.
 
 
 
 
 
=== Slave Orientation ===
 
 
 
'''[[AXY:MC-Basic:movingFrame.SLAVEORIENTATION|MF.SLAVEORIENTATION]]''' is a fixed type YPR (Yaw-Pitch-Roll, See: [[AXY:Kinematics_Package#XYZ_Yaw_Pitch_Roll|Yaw Pitch Roll]]) orientation vector used to rotate moving frame orientation vector into slave-robot orientation coordinates.
 
 
 
Let's define the product of moving frame master source as intermediate SR variable:
 
 
 
SR := ( MF.base<sup>-1</sup> : MF.MSource:MF.ObjectLoc )
 
 
 
then the SR variable will be of the same point-type as the moving frame source MF.
 
in order to translate it into slave's robot command we do:
 
 
slaverobot.position    = '''p-projection'''(SR.position)<br>
 
slaverobot.oreintation = '''q-projection'''(MF.SLAVEORINTATION*SR.orientation)
 
 
 
{{Note| In case when number of position coordinates of MF is less then of MasterSource the remaining coordinate will be assigned by the '''MF.BASE''' corresponding  coordinate value.}}
 
 
 
{{Note| In case when number of position coordinates of MF is less then of MasterSource the remaining coordinate will be assigned by the MF.base corresponding  coordinate value.}}
 
-->
 
 
 
= Affected(changed) commands =
 
 
 
== Activation(Syncing) ==
 
 
 
Setting '''[[MC-Basic:robot.SLAVE|<robot>.slave]] = 5''' immediately enters into synchronization-tracking mode, no trigger command is needed.
 
As the working window in case of robot-based MF's does not exist the '''[[MC-Basic:movingFrame.ZERO|MF.ZERO]]''' will return the current MF position at the moment of entering '''"slave=5"'''! After that moment the slave robot will try to synchronize to the Moving Frame Location: '''MovingFrame(t) = MF(t) - MF(t0)''' <br> where t0 is the moment of issuing "slave=5" ''(See:[[Element Coordination/Absolute Movements During Conveyor Tracking|Absolute_Movements_During_Conveyor_Tracking]])''
 
 
 
&nbsp;
 
 
 
Where the MF(.) is:
 
 
 
'''MF(t) = MS2MF( MF.base<sup>-1</sup> : Master(t):MF.ObjectLoc ) '''
 
 
 
Master(t) - position of robot master axis at moment t.<br>
 
'''MS2MF''' defined in: [[Element Coordination#MS2MF:|Master Source to Moving Frame function]]<br>
 
 
 
The relation to MC-Basic language variables is obvious:  
 
 
 
<nowiki><mf>.</nowiki>'''here''' = MF(t)
 
 
 
<nowiki><mf>.</nowiki>'''zero''' = MF(0) ''(See [[MC-Basic:movingFrame.ZERO|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 '''[[MC-Basic:robot.SLAVE|<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:<br>
 
 
 
* [[MC-Basic:robot.VELOCITYDESYNCTRAN|VELOCITYDESYNCTRAN]] , [[MC-Basic:robot.VELOCITYDESYNCROT|VELOCITYDESYNCROT]]<br>
 
* [[MC-Basic:robot.ACCELERATIONDESYNCTRAN|ACCELERATIONDESYNCTRAN]] , [[MC-Basic:robot.ACCELERATIONDESYNCROT|ACCELERATIONDESYNCROT]]<br>
 
* [[MC-Basic:robot.JERKDESYNCTRAN|JERKDESYNCTRAN]] , [[MC-Basic:robot.JERKDESYNCROT|JERKDESYNCROT]]<br>
 
 
 
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 ''[[MC-Basic:robot.ISMOVINGFRAMESYNCHRONIZED| 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''' <br>
 
* '''Dampingfactor, FilterFactor, MaxFlops'''<br>
 
 
 
will be used in the same way as in axis-based MF's. Instead of acting on a scalar distance(<math>dp</math>) between master axis and tracking variable, <u>cartesian distance</u>  (<math>\vec dp = \vec p_{master} - \vec p_{track}</math>) and Euler's angle distance (<math>\vec de = \vec e_{master} - \vec e_{track}</math>) 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
 
[[MC-Basic:TRIGGER| 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 '''[[MC-Basic:movingFrame.NUMBEROFITEMS|NOI]]''' will return always  '''-1'''.
 
 
 
== Is In Window ==
 
[[MC-Basic:movingFrame.ISINWINDOW| 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''' <br>
 
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 ==
 
 
 
* [[MC-Basic:NEXTITEM|'''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:
 
<pre>
 
<slaverobot>.MasterFrame = <master frame>
 
</pre>
 
 
 
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'''):
 
 
 
<pre>
 
<master frame>.MasterSource = <masterrobot>.SETPOINT
 
</pre>
 
 
 
== BASE  transformation ==
 
 
 
Master frame defines spacial relationship (distance and rotation) of the slave's robot frame to the master: '''<Master Frame>.Base'''
 
 
 
[[File:COOP 2 ROB BASE.png|700px|border| Two robots with a defined distance between them using MF.BASE]]<br>
 
 
 
== 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):
 
 
 
<pre>
 
<masterrobot>.setpoint
 
<masterrobot>.setpoint:<movingframe>.objectloc
 
</pre>
 
 
 
The second point of the object can be also reached through salve robot by (viewed by master-robot's '''world(robot)''' frame):
 
<pre>
 
<movingframe>.base:<slaverobot>.setpoint
 
</pre>
 
 
 
[[File:COOP 2 ROB OBJ.png|700px|border|Usage of OBJECTLOC]]
 
 
 
<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 ==
 
 
 
[[File:COOP 2 ROB FRM.png|700px|border|Frame calculations in two-robot case.]]
 
 
 
 
 
mf.base          = '''#{100,100,0,45}''' <br>
 
mf.base<sup>-1</sup>   = '''#{-141,100,0,-45}'''<br>
 
mf.objectloc    = '''#{80,0,0,180}'''<br>
 
master.setpoint = '''#{130,-72,0,0}'''<br>
 
 
 
slave.setpoint = '''mf.base<sup>-1</sup>:master.setpoint:mf.objectloc'''<br>
 
slave.setpoint = '''#{-43 , -200 , 0 ,135 }'''<br>
 
 
 
 
 
* 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.
 
 
 
[[File:COOP 3 ROB.png|700px|border|Frame Calculation in three-robot case]]
 
 
 
In this example we will define two Moving frame with each of them having a different OBJECTLOC.
 
 
 
The first Moving Frame:
 
<pre>
 
Common Shared MF1 As Moving Frame Of XYZR
 
MF1.MasterSource = <masterrobot>.SETPOINT
 
MF1.BASE = #{..., ..., ..., 0}
 
MF1.OBJECTLOC = #{L,..., ..., 180}
 
</pre>
 
 
 
The second Moving Frame:
 
<pre>
 
Common Shared MF2 As Moving Frame Of XYZR
 
MF2.MasterSource = <masterrobot>.SETPOINT
 
MF2.BASE = #{..., ..., ..., 0}
 
MF2.OBJECTLOC = #{SQRT(3)*L,L/2, ..., -150}
 
</pre>
 
 
 
* '''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:  [[Element Coordination/Absolute Movements During Conveyor Tracking|Absolute_Movements_During_Conveyor_Tracking]]<br>
 
 
 
* 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: [[AXY:Element Coordination/One Dimensional Tracking Algorithm|One_Dimensional_Tracking_Algorithm]]<br>
 
 
 
* Same algorithm (tracking) applied on 3-dimensional position vector (Euler angles) is explained here: [[AXY:Element Coordination/Multi Dimensional Tracking Algorithm (Position)|Position_Tracking_Algorithm]]<br>
 
 
 
* Same algorithm (tracking) applied on 3-dimensional orientation vector is explained here: [[AXY:Element Coordination/Multi Dimensional Tracking Algorithm (Orientation)|Orientation_Tracking_Algorithm]]<br>
 
 
 
* Concept of '''global frame''' coordinate system as addition to '''base''' and '''world(robot)''' frames for multiple robot usage is described here:[[Element Coordination/Global Coordinates|Global Coordinates]]
 
 
 
* Enlargement of axis-based MF data structures is shown here: [[AXY:Element Coordination/Software Design| Software_Design]]<br>
 
 
 
<!-- == Issues List: ==
 
{{Bugzilla|5954}}<br>
 
{{Bugzilla|5955}}<br>
 
{{Bugzilla|5957}}<br>
 
{{Bugzilla|5960}}<br>
 
{{Bugzilla|5963}}<br>
 
{{Bugzilla|6058}}<br>
 
{{Bugzilla|6075}}<br>
 
-->
 
 
 
= Examples =
 
 
 
== Example 1. two different robot kinematics ==
 
 
 
Cooperation between two unequal robot kinematics.
 
 
 
[[File:AXY;SCARAPUMA_COO.png|700px|border|Cooperation between SCARA and PUMA robot kinematics, PUMA robot is the master frame here]]
 
 
 
 
 
Moving Frame definition:
 
<pre>
 
Common Shared MF as Moving Frame of XYZR
 
</pre>
 
 
 
Linking it to the source (master):
 
<pre>
 
MF.MasterSource = Puma.Setpoint
 
</pre>
 
 
 
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). <u> Orientation angle changes of the master robot will have no effects on the slave.</u> So we need to define transformation matrix:
 
 
 
 
 
<center>
 
 
 
<math>
 
 
 
\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}
 
</math>
 
 
 
</center>
 
 
 
 
 
Or in the code:
 
 
 
<pre>
 
' 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
 
</pre>
 
 
 
 
 
And then the offsets definitions:
 
 
 
The XY coordinates will be offseted for (10,10) mm:
 
<pre>
 
MF.base = #{10,10,0,0}
 
</pre>
 
 
 
A distance of 100mm between the two robots tool-tips is defined as:
 
<pre>
 
MF.ObjectLoc = #{0,0,100,0}
 
</pre>
 
 
 
 
 
and the tracking (master-slave) is defined by:
 
<pre>
 
Scara.Masterframe = MF
 
</pre>
 
and started:
 
<pre>
 
Scara.slave = 5
 
</pre>
 
 
 
== Example 2. SCARA and a tilting table==
 
 
 
 
 
[[File:AXY;SCARA_TILT.png]]
 
 
 
Moving Frame definition :
 
<pre>
 
Common Shared MF as Moving Frame of XYZR
 
</pre>
 
 
 
 
 
Having a tilt table robot (Object Having only Yaw and Pitch angle):
 
<pre>
 
Common Shared TiltTable As Group Axnm = Ax5 Axnm = Ax6 Model = 1 of YP
 
</pre>
 
 
 
Linking it to the source (master):
 
<pre>
 
MF.MasterSource = TilTable.Setpoint
 
</pre>
 
 
 
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:
 
<pre>
 
MF.base = #{-200,0,0,0}
 
</pre>
 
  
 +
<u>对Scara:</u>
  
 +
target<sup>scara</sup><sub>B</sub> ← scara.gbase<sup>-1</sup>:target
  
Defining the object-location of 100mm makes the '''trick!'''
+
其中 "←" 表示仅复制X,Y,Z和旋转坐标
  
mf.base          = '''#{Xb,Yb,Zb,Rb}''' <br>
 
mf.objectloc    = '''#{Xo,Yo,Zo,0}'''<br>
 
master.setpoint = '''#{yaw,pitch}'''<br>
 
  
slave.setpoint = '''mf.base<sup>-1</sup>:master.setpoint:mf.objectloc'''<br>
+
<u>对Puma:</u>
  
'''i.e. the vector [Xo,Yo,Zo] will be rotated by the tilt-table angles [yaw,pitch]!!!'''
+
target<sup>puma</sup><sub>B</sub> = puma.gbase<sup>-1</sup>:target
  
and the tracking (master-slave) is defined by:
+
这里我们有"=" 符号,因为puma和全局坐标系具有相同的点类型
<pre>
 
Scara.Masterframe = MF
 
</pre>
 
and started:
 
<pre>
 
Scara.slave = 5
 
</pre>
 
  
== Example 3. Two SCARA's working on a same piece ==
+
==== 数字示例 ====
  
A robot to robot tracking example:<br>
 
Two SCARA robots, one master the other is slave.<br>
 
[[File:COOP 2 ROB SYNC.png|700px|border|Case of tracking with two SCARA robots.]]<br><br>
 
<u>Setup:</u><br>
 
set the slave robot to track the master on a distance of 100mm pointing in face-to face direction (180º)
 
<pre>
 
Common Shared MF as Moving Frame Of XYZR
 
MF.MasterSource = ScaraMaster
 
MF.ObjectLoc = #{100,0,0,180}
 
ScaraSlave.MovingFrame = MF
 
ScaraSlave.Slave=5
 
</pre>
 
At the moment of engagement (i.e. '''Slave=5''') Zero point is recorded!<br>
 
<br><br><br>
 
<u>Wait to be Synchronized and arriving to master-position together:</u> <br>
 
''System waits until MF is synchronized ([[MC-Basic:robot.ISMOVINGFRAMESYNCHRONIZED|Is-Moving-Frame-Synchronized]] equals 1)'' '''and''' ''motion towards Zero point is completed ([[MC-Basic:group.ISMOVING|isMoving]] flag is not positive)''
 
<pre>
 
Moves MF.Zero
 
While ScaraSlave.IMFS <> 1 and ScaraSlave.Ismoving > 0
 
Sleep 1
 
End While
 
</pre><br>
 
<u>Do something, or just stay in tracking mode.</u><br><br><br>
 
<u>Stopping.</u>De-Synchronize: <br>
 
 
<pre>
 
<pre>
slave = 0
+
Move scara #{100,100,700,0,0,50}
while ScaraSlave.IMFS <> 0
+
Move puma #{100,100,700,0,0,50}
Sleep 1
 
End While
 
 
</pre>
 
</pre>
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)''.<br>
 
<br>
 
 
== 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º)
 
 
[[File:COOP 2 ROB SYNC TOOL.png|700px|border|Coordination.]]
 
zoomed detail:
 
[[File:COOP 2 ROB SYNC BIG.png|400px|border|Coordination detail]]
 
 
[[Category:Motion:MovingFrame]]
 
 
 
== Example 5. PUMA and SCARA on a patch placement job ==
 
 
 
[[File:Coordination.png|700px|border|Setup.]]
 
 
For setting up global; coordinates see: [[Element Coordination/Global Coordinates#Example|Global_Coordinates]]
 
 
[[File:Coordination detail.png|700px|border|Detail view of work-space locations]]
 
 
 
=== Geometry ===
 
 
[[File:Coordination Geometry.png|700px|border| Geometric Setup.]]
 
 
Also see: [[Element Coordination/Global Coordinates#numeric_example|Global_Coordinates]]
 
 
the given setup can be accomplished in four different ways:
 
{| border = "1" valign = "top"
 
|- valign="top" align = "center"
 
| World(Robot) Frame || Base Frame || Global Base || Moving Frame
 
|- valign="top"
 
|
 
puma.base  = #{0,0,0,0,0,0} <br>
 
scara.base = #{0,0,0,0} <br>
 
Moves puma #{50,0,600,90,90,0}<br>
 
Moves scara #{-100,-100,0,0}
 
||
 
puma.base  = #{200,100,0,0,0,0} <br>
 
scara.base = #{100,100,0,0} <br>
 
Moves puma #{250,100,600,90,90,0}<br>
 
Moves scara #{200,0,-100,0}
 
||
 
puma.base  = #{200,100,0,0,0,0} <br>
 
puma.gbase  = #{0,0,0,0,0,0} <br>
 
scara.base = #{100,100,0,0} <br>
 
scara.gbase = #{0,100,700,0} <br>
 
Moves puma  #{250,100,600,90,90,0}<br>
 
Moves scara #{250,100,600,90,90,0}<br>
 
||
 
puma.base  = #{200,100,0,0,0,0} <br>
 
scara.base = #{100,100,0,0} <br>
 
puma.globalbase = #{0,0,0,0,0,0}<br>
 
scara.globalbase = #{0,0,0,0,0,0}<br>
 
Moves puma  #{250,100,600,90,90,0}<br>
 
MF.MasterSource = puma.setpoint<br>
 
MF.Base    = #{200,0,-600,0}<br>
 
MF.ObjectLoc = #{0,0,50,0}<br>
 
scara.MasterFrame = MF<br>
 
scara.slave = 5<br>
 
Moves scara MF.zero<br>
 
|-
 
|}
 
 
{{Note|'''''All four given code examples will bring the two robots to same positions!'''''}}
 
 
{{Note/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:
+
<pre>scara.gbase = #{0,100,700,0,0,0}
 +
scara.base  = #{100,100,0,0}
  
<pre>
+
puma.gbase  = #{0,0,0,0,0,0}
Common Shared MF As Moving Frame Of XYZR
+
puma.base  = #{200,100,0,0,0,0}
Common Shared hold As Location Of XYZR
 
Common Shared patch_feeder As Location Of XYZR
 
 
</pre>
 
</pre>
  
initialization :
+
我们获得'''SCARA'''的本地目标位置(在SCARA的基坐标系中):
  
<pre>
 
SCARA.Base  = #{100,100,0,0}
 
SCARA.GBASE = #{0,100,700,0,0,0}
 
PUMA.Base  = #{200,100,0,0}
 
  
 +
<nowiki>#</nowiki>{0,100,700,0,0,0}<sup>-1</sup> : #{100,100,700,0,0,50}为 #{'''100''' , '''0''' , '''0''' , 0 , 0 ,''' 50'''},可以写为:<br>
 +
<nowiki>#</nowiki>{100,0,0,50}← #{0,100,700,0,0,0}<sup>-1</sup> : #{100,100,700,0,0,50}
 +
表示目标点在SCARA的基坐标系是: '''<u>#{100,0,0,50}</u>'''
  
MF.MasterSource = PUMA.SETPOINT
+
'''PUMA'''机器人本地目标点以类似的方法计算:
MF.ObjectLoc    = #{0,0,50,0}
 
MF.Base        = #{200,0,-700,0}
 
  
SCARA.BlendingMethod = 2
+
<nowiki>#</nowiki>{200,100,0,0,0,0}<sup>-1</sup> : #{100,100,700,0,0,50}为 #{'''-100''' , '''0''' , '''700''' , 0 , 0 ,''' 50'''}, which we can write as:<br>
SCARA.BlendingFactor = 80
+
<nowiki>#</nowiki>{-100,0,700,0,0,50}← #{200,100,0,0,0,0}<sup>-1</sup> : #{100,100,700,0,0,50}
SCARA.MasterFrame = MF
+
表示目标点在PUMA机器人基坐标系上为: '''<u>#{-100,0,700,0,0,50}</u>'''
</pre>
 
  
=== Execution Code ===
 
  
<pre>
 
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
 
</pre>
 
  
=== Functions and variables used in the program above:===
+
{{Note| PUMA运动学中的GBASE和BASE表示相同的事情,尽管可以给出不同的值(然后使用组合gbase:base),但强烈建议仅使用一个,另一个保留为零,即:#{0,0,0,0,0,0} }}
  
<pre>
+
=== 使用基于机器人的运动参考系 ===
Function MoldPose( n as long) as location of XYZYPR
 
</pre>
 
Function returning pathc position on the mold in PUMA's coordinate system (e.g. XYZYPR)
 
  
<pre>
+
可以使用基于机器人的运动参考系实现相同的功能示例。
Function MoldProfile( n as long) as location of XYZR
 
</pre>
 
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).
 
  
<pre>
+
我们假设PUMA机器人是主机器人:
Sub TakePatch(robot as generic group)
 
</pre>
 
Subroutine for taking (gripper manipulation, vacuum, waiting, etc) a patch from the feeder.
 
  
<pre>
+
common shared MF as Moving Frame of XYZR
Sub GluePatch(robot as generic group)
 
</pre>
 
Subroutine for placing the patch on the mold. Here included are all synchronizations needed (wait, gripper open, ...)
 
  
 
<pre>
 
<pre>
MF.Base
+
MF.MSource  = puma.setppoint
 +
MF.OBJECTLOC = #{0,0,0,0}
 +
MF.BASE      = Inverse(#{0,100,700,0,0,0})
 +
scara.MasterFrame = MF
 +
scara.slave  = 5
 
</pre>
 
</pre>
Moving Frame Base offset,
 
  
<pre>
+
现在发行:<br>
hold
 
</pre>
 
Waiting position
 
  
<pre>
+
Move puma target<br>
Patch_feeder
+
''和''<br>
 +
Moves MF.zero<br>
  
</pre>
+
将puma和scara移动到同样的位置(目标)。<br>
Position from where the patches are taken.
 

Latest revision as of 03:27, 31 May 2017

语言: English  • 中文(简体)‎

全局坐标概念

对于使用不同点类型的全局坐标概念的机器人已经被定义。 这允许以一种常见的独特格式给予机器人位置,以独立地观察机器人具有多少轴。 这里使用的关键属性是机器人的base变换,如Robot_Working_Frames所述

基坐标系属性

机器人有两个笛卡尔坐标系:世界(机器人)坐标系和基坐标系。

世界(机器人)坐标系

在由q = (q1,q2,q3, .... , qn)定义的机器人姿势中,n是机器人的NDOF。 世界(机器人)参考坐标由下式定义:

pworld = DirectKinematics (q)

其中p可以是:p =(x,y,z,偏航,俯仰,滚动)取决于机器人运动学。

NOTE-Info.svgNOTE
为了简化讨论,我们假定该工具包含在正运动学计算中。这里省略了工件和工作台的坐标系。


基坐标系

基坐标系是由robot.base属性移动的世界(机器人)坐标系:

pbase = base:pworld

其中:是复合运算符。

全局基坐标属性(全局坐标)

所有用户输入(目标运动指令点,运动参考坐标等)都在基座坐标系中给出。 然而,这些系统可以与机器人不同(例如,R1具有XYZR和R2具有XYZYPR)。 因此,我们假设一个共同的(全局)基坐标系,将所有机器人转换到一个系统:

p1global = R1.glbalbase:R1.base:R1.DirectKinemaitcs(R1.pcmd)
p2global = R2.glbalbase:R2.base:R2.DirectKinemaitcs(R2.pcmd)
p3global = R3.glbalbase:R3.base:R3.DirectKinemaitcs(R3.pcmd)
...
pmglobal = Rm.glbalbase:Rm.base:Rm.DirectKinemaitcs(Rm.pcmd)

假设系统有m个机器人

这是通过添加始终与实际机器人点类型无关的<robot>.globalbase位置来实现的,在XYZYPR系统中给出


为了使全局坐标系尽可能的使用,运动命令(MOVE,MOVES,MOVESKD,CIRCLE ...)的扩展方式除了目前仅允许的机器人点类型的位置之外,还可以接受XYZYPR点类型的位置。


NOTE-Info.svgNOTE
给定的扩展适用于最多6个NDOF(不超过6个)的机器人。


NOTE-Info.svgNOTE
如果机器人点类型已经是XYZYPR,则全局和基本属性具有绝对相同的功能,可以相互添加。 他们都可以使用,但我们强烈建议只使用一个(而另一个保留为零),以减少混乱。


与此同时,还有两个新的属性:

例子

给定SCARA和PUMA机器人在同一个生产单元中,SCARA机器人在PUMA机器人的上方:


Global Frames.png


使用全局坐标系

执行以下运动命令:

Move scara target
Move puma target
其中目标是点类型XYZYPR的位置
将其转移到每个机器人的基本坐标系中:

对Scara:

targetscaraB ← scara.gbase-1:target

其中 "←" 表示仅复制X,Y,Z和旋转坐标


对Puma:

targetpumaB = puma.gbase-1:target

这里我们有"=" 符号,因为puma和全局坐标系具有相同的点类型

数字示例

Move scara #{100,100,700,0,0,50}
Move puma  #{100,100,700,0,0,50}

有:

scara.gbase = #{0,100,700,0,0,0}
scara.base  = #{100,100,0,0}

puma.gbase  = #{0,0,0,0,0,0}
puma.base   = #{200,100,0,0,0,0}

我们获得SCARA的本地目标位置(在SCARA的基坐标系中):


#{0,100,700,0,0,0}-1 : #{100,100,700,0,0,50}为 #{100 , 0 , 0 , 0 , 0 , 50},可以写为:
#{100,0,0,50}← #{0,100,700,0,0,0}-1 : #{100,100,700,0,0,50} 表示目标点在SCARA的基坐标系是: #{100,0,0,50}

PUMA机器人本地目标点以类似的方法计算:

#{200,100,0,0,0,0}-1 : #{100,100,700,0,0,50}为 #{-100 , 0 , 700 , 0 , 0 , 50}, which we can write as:
#{-100,0,700,0,0,50}← #{200,100,0,0,0,0}-1 : #{100,100,700,0,0,50} 表示目标点在PUMA机器人基坐标系上为: #{-100,0,700,0,0,50}


NOTE-Info.svgNOTE
PUMA运动学中的GBASE和BASE表示相同的事情,尽管可以给出不同的值(然后使用组合gbase:base),但强烈建议仅使用一个,另一个保留为零,即:#{0,0,0,0,0,0}

使用基于机器人的运动参考系

可以使用基于机器人的运动参考系实现相同的功能示例。

我们假设PUMA机器人是主机器人:

common shared MF as Moving Frame of XYZR

MF.MSource   = puma.setppoint
MF.OBJECTLOC = #{0,0,0,0}
MF.BASE      = Inverse(#{0,100,700,0,0,0})
scara.MasterFrame = MF
scara.slave  = 5

现在发行:

Move puma target

Moves MF.zero

将puma和scara移动到同样的位置(目标)。