New Coordination Algorithms Improve the Throughput of a GM Press Line
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.
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’’‘,
for fixed adaptive rates k1, k2, and k3 and fixed feedback parameters g1 and g2.