Coordinated robot control from multiple remote instruction sources

[0002] The present invention relates generally to robotic machines, and more particularly, to a robot control system for controlling multiple robotic machines where at least some of the robotic machines are controlled using a control program that resides on a controller other than the local controller of the controlled robotic machines.

[0003] When first introduced into the manufacturing environment, each automated robotic machine was dedicated to performing a specific task independent of any other robotic machine. Each robotic machine typically included a dedicated controller and an associated motion system for controlling its physical movements. The operation of the robotic machine is dictated by control program instructions which are embodied, in a control program. The control program instructions are converted by the controller into motion control commands which in turn are carried out by the motion system of the robotic machine. Thus, each robotic machine required its own control program.

[0004] As automation became more prevalent in the manufacturing environment, it was envisioned that robotic machines would cooperatively work together to complete various manufacturing tasks. For example, a first robotic machine may transfer a workpiece from a conveyor into a workstation. At the workstation, one or more additional robotic machines would perform various manufacturing operations on the workpiece. Lastly, the workpiece is transferred back to the conveyor and transported to the next workstation.

[0005] In this example, the various tasks need to be coordinated amongst the robotic machines. For instance, the first robotic machine is responsible for transferring the workpiece to and from the conveyor. Additionally, this robotic machine must know how long to wait before removing the workpiece from the workstation, thereby allowing the completion of the manufacturing operations by the other robotic machines. Since each robotic machine relies on its own control program, coordination amongst the robotic machines must be designed into the control programs residing on each robotic machine. In this way, coordinating tasks amongst robotic machines is difficult and complex.

[0006] One approach for simplifying the coordination amongst robotic machines is illustrated in FIG. 1. In this approach, a single controller 4 uses one control program 6 to provide motion control commands to a plurality of robotic machines 8. In other words, all the robotic machines physically share the same controller to perform their respective tasks. In order for each robotic machine to perform an independent task, the single controller must support the execution of multiple control programs in a multi-tasking environment, such that the coordination of tasks between the robotic machine is dispersed amongst one or more control programs. Because all of the robots are controlled from the same controller, it is relatively straightforward to coordinate the control among the tasks, because 1) multi-tasking programming constructs, such as semaphores and mutexes are provided for the programmer on such a controller, and 2) It is usually possible during simple sequences involving multiple robots for a single control program to control multiple machines.

[0007] The problem with the above solution is that the transfer of control of one robot between various control programs is limited only to that robot controller. Control of simple sequences between robots residing on different controllers remains a challenging task.

[0008] One of the objectives of the present invention is to dynamically exchange control of a given robot between various control programs running on different robot controllers. This makes it possible for robots controlled by different controllers, working more or less independently to occasionally come under the control of a single control program, so that one program can control a sequence involving more than one robot. This is important, because it is much easier for a programmer to create a reliable sequence of events in a single program thread than to try to cause two or more separate programs to perform a set of events in sequence. For instance, passing a part from one robot to another or moving more than one robot simultaneously with a single control instruction.

[0009] In order for the dynamic exchange of control to work well, a robot control system should include four key features. First, a control program must be able to issue commands to more than one robot either in sequence or simultaneously. This is how a simple sequence is achieved. For example, the control program would move a robot carrying a part to a drop position and open its gripper to drop the part. The same control program would then move a second robot to the drop position and close its gripper to pick up the part.

[0010] Second, the motion system, working on behalf of a given robot, must be able to accept commands for that robot from more than one control program. By this feature, a robot can work independently while being controlled by one control program, then work in a sequence or simultaneously with another robot by accepting commands from a different control program.

[0011] Third, a mutual exclusion mechanism should be available, so that control programs do not simultaneously issue commands to the same robot. Since one of the objectives of this invention is convenience of programming, a mutual exclusion mechanism is built into the robot control system. As further described below, the mutual exclusion method may be of several different forms.

[0012] Fourth, an instruction source must be able to issue motion commands from a control program across a communications network to a motion system residing on a robot controller different from where the instruction source resides. This is necessary, so that the locality of cooperation is unrestricted. For example, if the control program must reside on the same controller as the motion system for the robot it can control, then the exchange of control between control programs is limited to only the robots controlled by that robot controller. The locality of exchange is thus limited to those robots.

[0013] The term “multitasking” is used to describe a known feature of conventional robot controllers. This term refers to the ability of the robot controller to perform several tasks simultaneously. Several different methods may be used to perform several tasks simultaneously. These include multitasking interpreters that run separate program files simultaneously, multitasking operating systems that can run multiple compiled programs simultaneously, special interpreters that can run multiple co-routines simultaneously, or other methods used to run multiple threads of execution simultaneously. In this application, the meaning of “control program” is equivalent to a task, regardless of the method used to perform a task. The meaning of “instruction source” is any of the mechanisms capable of executing one or more control programs on the same robot controller. It is also possible that a multi-tasking instruction source could exist on its own computer, not part of a robot controller

[0014] Some known robot controllers have multitasking capabilities, but restrict each control program so that it can control only one robot and each robot can be run only by that control program. The present invention clearly requires that no such restriction is present, because this would contradict the first two features listed above. Other known robot controllers have more general multitasking capabilities but may be missing one of the first three features listed above. However, no known robot control systems, including those with multitasking capabilities, implement all four of the above listed features.

[0015] The present invention takes a different approach to facilitate the coordination amongst numerous robotic machines. A robot control system may be comprised of a plurality of robot controllers, where each of the controllers includes an associated motion system and is adapted to control a physically attached robotic machine. However, in accordance with the present invention, a single control program may be used to take logical temporary ownership of a robot controlled by the motion system of any of the robot controllers and issue motion commands for that robot to the appropriate motion systems.

[0016] Thus, the robot control system of the present invention includes one or more remote instruction sources that supply motion control commands to a plurality of robotic machines. Each instruction source is comprised of a memory for storing at least one robot control program and a processor for converting the control program into motion control commands. The instruction source may reside within one or more of the robot controllers or within a computer external to the robot controller.

[0017] A computer network is used to communicate between the plurality of robot controllers and other instruction source computers, so that an instruction source can send motion control commands to the motion system of a selected group of robot controllers. Attach/detach commands embodied in the motion control commands are used to mediate the operating state of at least one of the robot controllers via the motion systems of such robot controllers. When in an attached state, the motion systems of the selected robots operate only upon motion control commands received from the instructions source that issued a corresponding attach command. When in a detached state, selected robots may be attached to a different instruction source and then subsequently operate upon motion control commands from that other instruction source.

[0018] For a more complete understanding of the invention, its objects and advantages refer to the following specification and to the accompanying drawings.

[0019] FIG. 1 is a block diagram depicting a prior art robot control system employing a single controller for controlling multiple robotic machines;

[0020] FIG. 2 is a plan view of an exemplary manufacturing workstation employing cooperating robotic machines;

[0021] FIG. 3 is a block diagram depicting a robot control system in accordance with the present invention;

[0022] FIGS. 4A and 4B are diagrams illustrating exemplary mutual exclusion mechanisms in accordance with the present invention; and

[0023] FIG. 5 is a block diagram depicting an exemplary motion system architecture for a robot controller.

[0024] An example of cooperating robotic machines in a manufacturing environment is illustrated in FIG. 2. In this example, a first robotic machine 12 and a second robotic machine 14 work together to perform various manufacturing operations. Initially, each of the robots operate independently to perform different manufacturing tasks as shown at 16. However, the robots may also perform a cooperative task as shown at 18. For example, the first robot 12 may transfer a workpiece to the second robot 14. Upon completion of this task, each of the robots continue to independently perform different manufacturing tasks as shown at 20.

[0025] In accordance with the present invention, a robot control system 30 for coordinating the operation amongst various robotic machines is depicted in FIG. 3. The robot control system 30 comprises a control program instruction source 32 and a plurality of robot controllers 34 interconnected by a computer network 40. Although the instruction source 32 is depicted as residing on a separate computing device 33, it is envisioned that it may alternatively reside on one of the robot controllers 34 and that multiple instruction sources of these forms may exist simultaneously in a robot control system. In addition, one or more of the robot controllers may have a local instruction source 37. Each robot controller 34 further includes an associated motion system 36 adapted to control a physically attached robotic machine 38 and its associated mechanisms. It is to be understood that the robot controller and associated motion system need not be physically attached, but are in data communication with, the robotic machine. it is further understood that an associated motion system 36 may also be adapted to control more than one robotic machine.

[0026] Referring to FIG. 4A, the instruction source 32 includes a memory 42 for storing at least one robot control program 44 and an instruction processor 46 for converting the robot control program 44 into a first set of motion control commands 48. Although an interpreter is preferably used as the instruction processor, this is not intended as a limitation on the broader aspects of the present invention. On the contrary, the instruction processor may be implemented in other forms, such as a computer executing instructions compiled into the native language of the computer. The instruction source 32 is further operable to supply motion control commands across the computer network 40 to one or more of the robot controllers 34.

[0027] Likewise, each of the robot controllers 34 may be configured with a memory 42′ for storing at least one robot control program 44′ and an instruction processor 46′ for converting the robot control program 44′ into a second set of motion control commands 48′. The robot controller 34 further Includes an arbitrator 50. In operation, the arbitrator 50 receives motion control commands and directs them to the motion system 36 associated with the robot controller 34. To the extent that the arbitrator 50 receives motion control commands from more than one control program and/or from more than one instruction source, it mediates the operating state of motion system 36, such that only the appropriate commands are acted upon by each of the robots under control of that motion system.

[0028] In an preferred embodiment, attach/detach commands embodied in the motion control commands are used to dictate the operating state of the motion system 36. The arbitrator 50 generally implements a detached state on behalf of the robots under its control. Upon receipt of an attach command from a control program for the specific robot, the arbitrator 50 gives the control program logical temporary ownership of the robot. This is referred to as an attached state. For instance, the arbitrator 50 may receive an attach command from a control program 44′ via the instruction processor 46′ residing on the local robot controller 34. In this instance, the arbitrator 50 will only direct the motion control commands received from that control program 44′ to the motion system 36 on behalf of a robot.

[0029] Likewise, the arbitrator 50 may receive an attach command from a control program 44 residing on a remote instruction source 32. In this instance, the arbitrator 50 will only direct the motion control commands received from that control program 44 to the motion system 36 on behalf of a robot. When in an attached state, the arbitrator 50 on behalf of a particular robot will not accept motion control commands for that robot from a control program other than the control program that initiated the attached state. Furthermore, a control program is able to detect that a robot is attached to another control program and then wait on the availability of that robot, via its attach command The arbitrator will return to a detached state on behalf of that robot upon receipt of a detach command from the control program that initiated the attached state. In this way, the robot control system 30 is able to coordinate the operation of various robotic machines 38 This is especially useful for closely coordinated synchronous operation of multiple machines, as they can be handled from one program after having been attached to that control program.

[0030] It is envisioned that the attach/detach commands may be separate from the motion control commands, and thus sent independently in message format to the arbitrator. In this approach, motion control commands are sent directly to the motion system and an additional message is sent from the arbitrator to the motion system instructing it as to the appropriate motion control commands which are to be acted upon by each of the robots under control of that motion system.

[0031] Alternatively, the arbitrator may reside on the remote instruction source as shown in FIG. 4B. In this embodiment, the arbitrator 50 may also receive motion control commands from two or more robot control programs. To the extent that the arbitrator 50 receives motion control commands from more Than one control program and/or from more than one instruction source, it mediates the operating state of a motion system 36, such that only the appropriate commands are acted upon by each of the robots under control of that motion system. In this embodiment, the attach/detach commands are preferably separated from the motion control commands and sent independently to the arbitrator as described above. The arbitrator 50 then sends a message to the motion system 36 instructing it as to the appropriate motion control commands which are to be acted upon by each of the robots under control of that motion system; otherwise, the mediation mechanism may be as described above in relation to FIG. 4A.

[0032] The above description has been provided with reference to attach/detach commands. It is envisioned that other mutual exclusion mechanisms may be employed to control the operating state of the motion system 36. For example, a simple configuration of the robot control system Could determine a predetermined owner of a given motion system at power on or initialization time. Subsequently, an operator could change the instruction source that has ownership of the given motion system via an operator interface. Alternatively, a PLC could change the instruction source that has temporary ownership via I/O interaction with the various robot controllers. It is further envisioned that the mediation mechanism may be some combination of these techniques. For example, at power-on, configuration would determine a default instruction source that has initial ownership of a given motion system, and the default instruction source would subsequently issue detach commands to make the given motion system available to a different instruction source issuing an attach command. Other mediation mechanisms that control the operating state of a given motion system are also within the scope of the present invention.

[0033] FIG. 5 illustrates an exemplary motion system architecture 60 for the robot controller 34. The motion system architecture 60 includes a motion manager 62, a real-time planner 64, an interpolator 66, and a servo interface 68. While real-time planning and interpolation are well known in the art, the coordination of synchronized and independent motions by exchange of control between control programs is either not provided for in the art, or is handled partially by the instruction source interpreter so that assigning logical temporary ownership of the motion system to a control program processed by an instruction source of a different controller is not possible. In the exemplary motion system 60, the motion manager 62 is responsible for coordinating the independent and synchronized motions of the corresponding robotic machine, and is completely independent from the operation of any particular instruction source. In one embodiment, the motion manager 62 serves as the arbitrator. Thus, the motion manager 62 is adapted to receive motion control commands from control programs processed by two or more instruction sources in the robot control system, where the motion manager may reside on the same or different computing device as the instruction sources.

[0034] The foregoing discloses and describes merely exemplary embodiments of the present invention. One skilled in the art will readily recognize from such discussion, and from accompanying drawings and claims, that various changes, modifications, and variations can be made therein without departing from the spirit and scope of the present invention.