« Back To Tech papers
Robotic Industries Association Logo

Member Since 1900


RIA has transformed into the Association for Advancing Automation, the leading global automation trade association of the robotics, machine vision, motion control, and industrial AI industries.

Content Filed Under:



New Coordination Algorithms Improve the Throughput of a GM Press Line

POSTED 07/01/2003



Introduction: Previous research [1, 2] had confirmed our ability to control motion with high dynamic accuracy independent of robot speed and acceleration, within physical performance limits. In the past, the increased smoothness and accuracy of the new control allowed us to improve motion-related cycle times by 40 – 60% over the state-of-the-art.


Our latest task was to apply this research, previously confined to laboratory implementation, to a General Motors press line, with the goal of improving the overall throughput by at least 18%. A preliminary review of the existing system, operating under a Unico control, suggested that, unlike earlier tests, the robots on the press line were being utilized at or near their physical limits. Therefore, while improved motion would certainly yield other benefits, throughput would probably not increase significantly if high performance motion control were the sole control change made. However, we were able to identify an area which was likely to contribute to improved throughput—inter-device coordination. We observed that the coordination between the robot loaders/unloaders and the presses was particularly inefficient. Thus, while we would implement improved motion control [1, 2], we would also attempt to improve the overall throughput of the line by controlling inter-device coordination for high efficiency. We named our controller ‘‘MTEK’‘.


Any means of control that is not entirely automatic has three facets that must be designed into the controller: a language or a paradigm for describing how the control is to be implemented; hardware/software structures for actualization of the control; and a user interface that allows the user to specify operational parameters to govern the implementation.


The state-of-the-art approach to inter-device coordination is to provide a collection of what is sometimes called ‘‘software limit switches’‘. These allow the user to specify that an output be set at a time when a certain event occurs, thus giving the user the ability to schedule the start-up of the different devices.


On the GM press line, under the Unico control, there was a software ‘‘clock’‘ that cycled at a uniform speed from 0 to 360 degrees and then repeated, so that each cycle corresponded to one press line cycle. Any device could be set to initiate its cyclic motion at a specific clock angle. Thus, the concept of the limit switch was the implementation paradigm, the hardware/software structures were the software clock and the serial link that distributed the current clock angle and the user interface was a screen that portrayed a list of available limit switches and allowed the user to associate an output with a particular one. There are several disadvantages to this approach. First, it requires the user to estimate the times from device-start to the critical points of coordination, and these may be difficult to estimate or somewhat variable. Second, these times are dependent on the line speed and therefore, coordination would need to be retuned manually whenever the line speed is changed. Third, these times are estimated off-line and there is no real-time correction. That is, coordination is normally an open-loop process, so real-time variations are not taken into account. It is natural, then, that state-of-the-art inter-device coordination, in deference to ease of implementation and safety, more nearly resembles event sequencing than choreography.


The MTEK approach to coordination is to regard it as a rendezvous between two moving devices, and to allow the user to specify what device states should occur simultaneously. In actuality, in every coordination on the press line, there is always a master device which is already in motion, and a slave device which is waiting for the ‘‘right’‘ moment to begin so that the required synchronization takes place. In addition, for safety, the slave can be late, at the cost of some efficiency, but never early. Thus, the unloader robot can arrive under the press after the press has cleared the zone of potential interference, and there will be no collision, but never before.


The Role of Uncertainty: The fundamental limitation on how closely two devices may be coordinated is the uncertainty with which their future positions can be forecast. If the press motion is highly variable from cycle to cycle, then it would be unsafe to try to program the unloader robot to pass too close on its way in to pick up its part. If the press were running a little slow on this cycle, the unloader would be likely to collide with it. Similarly, if the robot following error could be large, as was the case under the Unico control, and the robot were to be stuck (due to a fault) under the press, it might take too long for the system to recognize the fact so as to shut itself down and to prevent the press from closing.


We define:

TM = time from current time to master coordination state

TS = time from current time to start slave

?T = time from start slave to slave coordination state.


In the absence of uncertainty, the formula relating these three quantities that leads to perfect coordination would be:

TS = TM - ?T.


If UM is the uncertainty in the estimate of the time to the master coordination state and US is the uncertainty of the time estimate to the slave coordination state, then a safe calculation would be:

TS = TM - ?T + UM + US.


With this formula, if the master is as late as possible and the slave is as early as possible, there will still be no collision. We delay the slave from the ideal start time to account for the possibility of variability in both master and slave device.

Control accuracy improves coordination because tight coordination is more easily achieved and tested, safety margins are maximized, and tuning and training times are minimized.


To make this approach operational, MTEK requires a specification of actual system states and the control must be implemented in such a way that MTEK can forecast the time from start to any desired state, along with a (conservative) estimate of the uncertainty of that forecast. This has ramifications for each type of controlled device.


Press Control: For the press, normally controlled by a PLC, the input/output must be made in a more timely manner in order to effect accurate forecasting. However, even with press measurements made frequently from a subsystem of a real-time (PC-based) operating system, there are inherent uncertainties. There is no motion model for the press dynamics, and, since the press is actuated physically by a clutch and platen, there are random stopping points and starting delays.


On this line, the press is measured by a 256 count encoder. Reading press position every 10 msec guarantees that no state transition will be missed. The MTEK controller is configured to collect arrays of measurements, indexed by encoder state, of the transition time from commanded press start to the current state. The controller then stores a fixed number of total cycles for each press. Each array yields the time transition for a specified state transition for one cycle. Multiple cycles contribute to the estimate of variability, which is augmented by the (random) actuation delay and the 10 msec sample delay. The coordination must be run ‘‘conservatively’‘ until sufficiently many data cycles (say, five) are collected to have confidence in the resulting estimates. Then, the forecasts can be used to implement tight coordination.


Robot Control: For the robots, the main issue is one of maximum following error. Under the Unico control, the maximum following error had to be set at 30 in. in order to keep the line running. Such a following error limit would afford no confidence in a close coordination scheme.


The MTEK control is a soft motion control, with path planning and the position loop both implemented in a subsystem of the real-time, PC-based controller. Typically, in soft motion control, the position loop runs at high frequency and the path planner runs at a somewhat lower frequency. Ours is no exception. However, the path planner is designed to compute command position, velocity, acceleration and jerk, all in real-time. This dynamic command is then used by the loop control to effect accurate tracking, independent of speed. The formula is an adaptive feedforward control, in which the controller modifies its own control parameters in real-time in response to the observed error. If:

u = motor input,

y = command position,

y’ = command velocity,

y’‘ = command acceleration,

y’’‘ = command jerk,

e = observed error = command – actual,

e’ = error rate (or an approximation),


u = g1 e + g2 e’ + v1 y’ + v2 y’‘ + v3 y’’‘,


g1, g2, v1, v2, v3

are control parameters and v1, v2, and v3 are modified by the controller according to the formulas

v1’ = k1 y’ e,

v2’ = k2 y’‘ e,

v3’ = k3 y’’‘ e,


for fixed adaptive rates k1, k2, and k3 and fixed feedback parameters g1 and g2.


This form of control has been tested on different robots with all the different kinds of motors, from hydraulic to brushless DC, and it functions to virtually eliminate following error. On the press line, the MTEK control reduced the following error to a peak of 0.025 in., independent of speed. A following error limit of 0.25 in. could be imposed and it was never triggered during normal robot operation. As long as inter-device clearances were specified to exceed that 0.25 in., then, the time forecast uncertainty for motion control could be taken to be the position loop update time, or less than 2.0 msec.


The Language of Control: In order to retain the maximum flexibility in implementing this complex controller in a factory environment, we chose to design a control macro language, called MTEK Executive Language, or MEL, so that the actual control would be specified in our so-called executive language and the underlying software served as a base to build and execute the user-configured control scripts. Thus, it became important to design language elements that would support the needed coordination paradigm. MEL supports the operational definition of events:


Event PressUp (press, PressName, PressPosition);

Event UnloaderEnteringPress (path, PathName, PathPosition);


The Event declaration gives a name to the event, the type of event (press or path), the name of the device and a variable or formula that specifies the state that can be measured to ascertain that the event has triggered. In this case, PressUp is the master event and UnloaderEnteringPress is the slave event. MEL then allows these events to be coordinated with the statement:

status = coordinate UnloaderEnteringPress to PressUp;


This statement sleeps until it is time to start the unloader motion to rendezvous with the PressUp event. Thus, the ‘‘coordinate’‘ statement can be followed by the requisite motion statements so that the unloader is started relative to the press and UnloaderEnteringPress and PressUp occur at (nearly) the same time.


Structures for Control Actualization: MTEK is designed fundam