Conveyor Tracking Short

Language:	[[::Conveyor Tracking Short|English]]  • [[::Conveyor Tracking Short/zh-hans|中文（简体）‎]]

About this Document

This document presents a general overview of the softMC controller’s conveyor tracking feature. It does not provide detailed descriptions of every command or property, which can be found in the softMC-wiki. Main Features

• Direct, on-the-fly synchronization with the moving object
• Implicit engagement of the outer source
• Relative movement to the moving frame (the moving object)
• Dynamic re-synchronization with the moving object

Conveyor Tracking Overview

Conveyor tracking is a feature of the softMC controller used mostly in packing applications in which the robot end effector needs to be synchronized with a moving object. Conveyor tracking is typically used for two types of tasks. One type of task is inserting or extracting an item into/from a container that is located on a moving conveyor. The robot must move along with the conveyor so that its motion relative to the moving object is zero, otherwise it will impact the sides of the container. The other type of task is picking up an object located on a moving conveyer. In this task the robot tool-tip (gripper) needs to be in contact with the object for as long as is needed to fully grasp it, either mechanically or by establishing a sufficient level of suction pressure (vacuum). The conveyor has one direction of movement, called the stream. The upstream position is where the object first “appears”, and the downstream position is where the object is no longer within the robot’s reach. Movement of the object is monitored by an external position variable (MasterSource). If the conveyor is actuated by the drive under softMC control, the variable is usually the axis position command (pcmd) or feedback (pfb). If the conveyor is not actuated by one of the softMC’s axis, the external position signal (pext) of an axis (secondary encoder input) is used. Conveyors are a type of moving frame, which is a generalized data type used to track external coordinate sources such as robots or conveyors. Therefore moving frame is used in the MC-BASIC declaration statements.

Typical Conveyor Tracking Setup

A typical conveyor tracking setup is shown in Figure 1.

Figure 1. Typical conveyor tracking setup

Connecting a Vision System

A conveyor tracking system with a vision system is shown in Figure 2.

Figure 2. Conveyor tracking with vision system

The conveyor tracking system includes a trigger position at which a moving object is detected by a sensor connected as an input probe to the conveyor drive. When the object moving on the conveyor is detected, its exact position is captured. Simultaneously the vision system takes a snapshot and computes the XYR coordinates of the object. By knowing the distance between the trigger position and the beginning of the working window (upstream position), the robot can be positioned to the conveyor (captured position + distance offset). Once the object enters the working window, the robot will move to it; once synchronized with the conveyor, the robot can perform an action upon the object.

Defining the Conveyor as a System Variable

A conveyor is defined as a global data type associated with the point type of the robot model; it is usually defined in the configuration file (CONFIG.PRG):

Common shared <Conveyor Name> as moving frame of <Point Type>

<Conveyor Name> is name of the new variable (object) representing the conveyor. Standard rules for naming apply.
<Point Type> is the type of the coordinate system the conveyor represents. It should be the same as the point type of the robot that is being used (e.g., XYZ, XYZR, XYZYPR).
For example:

common shared Conv as moving frame of XYZYPR

This defines Conv as a conveyor of type XYZYPR (X, Y, Z, Yaw, Pitch, Roll).

Conveyors can be linear or rotary, which is defined by the type property:

<Conveyor Name>.type = n

Values:
0 – linear
1 – rotary
2 – rotary decoupled

Driving Variable of a Conveyor

The variable driving a conveyor is its master source, which is defined by the MasterSource property, which defines the axis (or group) that moves the conveyor. The variable can be a one-dimensional variable such as a position of an axis (e.g., position command, position feedback or external position). It can also be an array of independent axes’ positions, or a complete position vector of a group. The number of independent position variables defines the conveyor property ndof, which represents the number of degrees of freedom of a conveyor. For example:

Conv.Type = 1
Conv.Ndof = 1
Conv.MasterSource = A1.Pext

This example shows a declaration of a one-dimensional linear conveyor driven by an external position command of axis 1 (a1). If the conveyor is actuated by an external motor (that is, a motor not under control of softMC), its movement is measured by physically attaching an external encoder to the conveyor belt that is connected to an external position input (secondary encoder) of the drive (pext).

Linking the Conveyor to the Robot

Before starting conveyor tracking, the conveyor must be linked to the robot, by declaring, for example:

Puma.MasterFrame = conv

This command establishes a relationship (link) between the conveyor and the robot, and keeps conveyor and the robot positions independent. This command does not activate conveyor tracking. Actual conveyor tracking begins only when the property slave is set to 5.

Working Window of a Conveyor

The area or range in which the robot can be synchronized with a conveyor is called the working window. For linear conveyors it is defined by upstream and downstream positions. For rotary conveyors the circular path is defined by an additional point (ArcPoint) that lies between the upstream and downstream positions. These points are defined by assigning them values as for any other location-data types, either as expressions or constants. For example:

Conv.UpStream[1] = #{100,0,0,0,0,0}
Conv.DownStream[1] =  #{250,0,0,0,0,0}

In this example, a linear conveyor’s working window is defined along the line parallel with the X-coordinate, beginning at X=100 and ending at X = 250.
Note that the index [1] in the example indicates that the conveyor has been defined with one degree of freedom (ndof =1)
To define conveyor movement, each point in the working window (Upstream, Downstream; and ArcPoint for rotary conveyors) needs to be assigned a master coordinate. The two conveyor properties, UpMaster[1] and DownMaster[1], set the values of the master axis and correspond to the UpStream and DownStream points. Thus, when the master axis is at UpMaster[1] position, the object on the conveyor is at UpStream point. These points are offset by the trigger position, which will be discussed later in this article.) For example:

Conv.UpMaster[1] = 1000
Conv.DownMaster[1] = 2000

In this example (assuming the offset is 0), when the master axis (a1.pext) is at 1000 (a1.pext = 1000), the conveyor object is located at #{100,0,0,0,0,0}. When the master axis (a1.pext) is at 2000 (a1.pext = 1000), the conveyor object is located at #{250,0,0,0,0,0}. This also means there are 1000/150 = 6.66 units of master axis per 1 mm of the conveyor.

Figure 3. Catching the item on a rotary conveyor “MOVES CNV.ZERO”

Cyclic Conveyor Position

The conveyor is inherently cyclic. The master position of the conveyor is an endlessly increasing value. To obtain the periodicity of the conveyor, a trigger offset of the master axis position must be introduced. The offset value is issued by trigger command. For example:

Trigger puma Ndof = 1 Value = 300

In this example, the trigger command offsets the master position for 300 position units of the master. This means the next working window will be between 1300 and 2300 of the master position. Triggers can be buffered; up to 16 trigger values can be stored in the system. The number of trigger values entered so far can be queried using the property <conveyor>.noi. Each time conveyor tracking is started (slave=5), one value is taken out of the trigger buffer. Each time a conveyor is disengaged, tracking is disengaged (slave=0), and another value is taken from the buffer. The trigger is the condition for starting the tracking. The trigger command specifies the master position that is used as a reference point. All master positions during the tracking process are recalculated relative to this point. If there is a delay between the actual trigger and the position update, the difference can be compensated for by adding an offset to the position specified by the trigger command. The value of the offset is determined by the user. The value specified in the trigger command serves as a reference for determining the working window, as shown in the following example.

Figure 4. Master position values

A (UpMaster[1]) and B (DownMaster[1]) are the upper and lower master limit positions.
X is the value specified in the trigger command.
M is the current master position. Thus, the actual limits of the window are currently:
Lower Limit: L = X + A
Upper Limit: U = X + B
IsInWindow = (L <= M) and (M <= U)

Monitoring Variables

The following variables are used to monitor the conveyer-tracking process: <conveyor>.IIW (Is In Window) (0 or 1) indicates whether or not the robot is within the working window. <robot>.IMFS (Is Motion Frame Synchronized) (0 or 1) indicates whether or not the robot is completely in sync with the conveyor. <conveyor>.here is the actual position of the moving object on the conveyor. <conveyor>.zero is the position within the working window at which the object appears after triggering.

Figure 5. Working window and monitoring variables

Starting Conveyor Tracking

Conveyor tracking is started by changing the slave property of the robot. For example: Puma.slave = 5 This command initiates the synchronization process. If no other commands are in effect, the robot end effector will move in parallel with the conveyor from the point at which slave property was changed. There are three different phases of conveyor tracking:  Synchronization  Tracking  De-synchronization

Figure 6. Synchronization – De-synchronization sequence during conveyor tracking

The first phase is synchronization. In this phase the robot tries to catch up with conveyor position movement. If the conveyor is too fast, the robot is unable to catch it. The kinematics parameters for robot synchronization are:
puma.velocitySyncTran
puma.accelerationSyncTran
puma.jerkSyncTran

puma.velocitySyncRot
puma.accelerationSyncRot
puma.jerkSyncRot

These parameters all need to be set to be a slightly higher value than the standard parameters of the robot (vtran, …). As soon as the slave is changed from 0 to 5, synchronization begins. During synchronization, <robot>.imfs = 0. Once the robot is synchronized with the conveyor the <robot>.imfs flag is set to 1. As soon as the slave state changes, the object on conveyor starts to move. This can be tracked by the property <Conveyor>.here, which returns the location of the conveyor movement. If the object exits the working window, an error is reported and conveyor tracking is disengaged. Once the action upon the moving conveyor is completed, the robot is disengaged from the conveyor. This phase is called de-synchronization, during which <robot>.imfs = 1. The de-synchronization parameters are:
puma.velocityDeSyncTran
puma.accelerationDeSyncTran
puma.jerkDeSyncTran

puma.velocityDeSyncRot
puma.accelerationDeSyncRot
puma.jerkDeSyncRot
It is crucial for the robot to be at least twice as fast as the conveyor. The maximum speed and other limitations of the conveyor are set by: Conv.VelocityMaxRot= …
Conv.AccelerationMaxRot = …
Conv.JerkmaxRot= …
These are monitoring values only. If any one is exceeded, an error is reported.

Position of the Object Origin on the Conveyor

The position of the moving object when it appears in working window is obtained by the property <Conveyor>.zero which is a location data type. It represents the location of the object when the synchronization started; if the synchronization started before the master position became greater than <conveyor>.UpMaster[1], then the <conveyor>.UpStream[1] value is returned.

Absolute Movements during Conveyor Tracking

The "total robot position” is the Cartesian position of the robot translated into joint values, which are the coordinates that are actually sent to drives over the motion bus (EtherCAT). The total position during conveyor tracking is composed of two elements: robot motion and conveyor motion. Robot motion is the change in coordinates introduced by motion commands such as MOVE and MOVES. Conveyor motion is the motion of the conveyor in different phases (synchronization, tracking, de-synchronization). Total robot position is expressed as: Total = Robot + Conveyor The conveyor coordinates are:
Conveyor(t) = CNV(t) - CNV(t0)
t0 is the moment at which "slave=5" is issued

For a linear conveyor, CNV is:
CNV(t) = (DownStream - UpStream)*(Master(t) - Trigger)/ (DownMaster - UpMaster[1])
Master(t) is the position of conveyor master axis at moment t.
DownStream, Upstream, DownMaster, and UpMaster are conveyor parameters.

The relationship to MC-BASIC variables:
Conv.here = CNV(t)
Conv.zero = CNV(0)

The idea behind this is that the queried/commanded robot position is the same both when conveyor is moving and when the conveyor is standing still. Thus, to teach points on the conveyor, just stop the conveyor and move the robot to its destination alongside the belt. The robot motion, that is, the Robot variable in the main equation, is the robot’s absolute position during conveyor tracking; it is equal to the position entered as the target point of the motion commands (e.g., MOVES/CIRCLE).

Detailed description

See: Conveyor_Tracking