Patent Application
20230356345
The present disclosure relates to robot control. Various embodiments of the teachings herein include multi-type industrial robot control systems, apparatus, and/or methods.
The integration of industrial robots with automated systems plays a key role in manufacturing. However, automation controllers and robot controllers use different engineering environments and tools. Greater effort is needed in engineering and debugging. Different robot manufacturers have different engineering software, presenting a challenge to programming and maintenance.
In view of the above, various embodiments of the present application include multi-type industrial robot control systems and apparatus, and/or multi-type industrial robot control methods to realize unified control of industrial robots of different types. For example, some embodiments include a multi-type industrial robot control system comprising: an automation controller and a programmable logic controller (PLC)-robot bridge, wherein the automation controller stores a general-purpose robot control function block generated in compliance with a unified design standard, calls a corresponding robot control function block according to a control program for a robot and in conjunction with robot state data received from the PLC-robot bridge, the control program being written by a user based on the general-purpose robot control function block, and outputs corresponding first command data to the PLC-robot bridge; the PLC-robot bridge virtualizes robot interfaces of corresponding offline programming functions of different types of robot as a unified virtual interface, calls a corresponding offline programming function of a corresponding type of robot via the unified virtual interface according to the first command data, and generates second command data for output to a corresponding robot controller, and the corresponding robot controller controls a corresponding robot; at the same time, robot state data from a corresponding type of robot is received via the unified virtual interface, and the robot state data is fed back to the automation controller.
In some embodiments, the PLC-robot bridge comprises: a data switch, for receiving the first command data from the automation controller; and sending the robot state data to the automation controller; a robot control application programming interface, for virtualizing robot interfaces of corresponding offline programming functions of different types of robot as a unified virtual interface; a command manager, for performing a correctness check on the first command data, and when the check is passed, extracting a valid data field therefrom for parsing to obtain a corresponding command set, and caching the command set; a command execution module, for reading the command set, and calling and running a corresponding offline programming function of a corresponding robot via the virtual interface provided by the robot control application programming interface according to the command set, to generate second command data; a robot state manager, for reading, via the virtual interface provided by the robot control application programming interface, robot state data returned by the robot controller, and providing the robot state data to the data switch; a robot communication interface, for outputting the second command data to a corresponding robot controller, and receiving robot state data returned by the robot controller.
In some embodiments, the command manager comprises: a data preprocessor, for performing a correctness check on the first command data, and when the check is passed, extracting a valid data field therefrom; a command parser, for parsing the valid data field to obtain a corresponding command set; and a command buffer zone, for caching the command set.
In some embodiments, the data preprocessor is further used to receive robot state data from the robot state manager, and provide the robot state data to the command parser; and the command parser further obtains a corresponding command set according to the robot state data.
In some embodiments, the multi-type industrial robot control system further comprises: a robot controller, for receiving the second command data from the PLC-robot bridge, and controlling a corresponding robot to perform a corresponding operation according to the second command data; and feeding state data of the robot back to the PLC-robot bridge.
As another example, some embodiments include a multi-type industrial robot control apparatus comprising: a data switch, for receiving first command data from an automation controller; and sending acquired robot state data to the automation controller; the first command data being first command data obtained by the automation controller calling a corresponding robot control function block according to a control program for a robot and in conjunction with robot state data from the switch, the control program being written by a user based on a general-purpose robot control function block, which is generated in compliance with a unified design standard and stored in the automation controller; a robot control application programming interface, for virtualizing robot interfaces of corresponding offline programming functions of different types of robot as a unified virtual interface; a command manager, for performing a correctness check on the first command data, and when the check is passed, extracting a valid data field therefrom for parsing to obtain a corresponding command set, and caching the command set; a command execution module, for reading the command set, and calling and running a corresponding offline programming function of a corresponding robot via the virtual interface provided by the robot control application programming interface according to the command set, to generate second command data; a robot state manager, for reading, via the virtual interface provided by the robot control application programming interface, robot state data returned by the robot controller, packaging the robot state data and then providing same to the data switch; a robot communication interface, for outputting the second command data to a corresponding robot controller, and receiving robot state data returned by the robot controller.
In some embodiments, the command manager comprises: a data preprocessor, for performing a correctness check on the first command data, and when the check is passed, extracting a valid data field therefrom; a command parser, for parsing the valid data field to obtain a corresponding command set; and a command buffer zone, for caching the command set.
In some embodiments, the data preprocessor is further used to receive robot state data from the robot state manager, and provide the robot state data to the command parser; the command parser further obtains a corresponding command set according to the robot state data.
As another example, some embodiments include a multi-type industrial robot control method comprising: an automation controller receiving a control program for a robot written by a user based on a general-purpose robot control function block, which is generated in compliance with a unified design standard and stored in the automation controller; and receiving robot state data fed back by a PLC-robot bridge; calling a corresponding robot control function block according to the control program and the robot state data, and outputting corresponding first command data to the PLC-robot bridge; the PLC-robot bridge receiving the first command data, calling a corresponding offline programming function of a corresponding type of robot via a unified virtual interface according to the first command data, generating second command data for output to a corresponding robot controller, and the corresponding robot controller controlling a corresponding robot; the unified virtual interface being obtained by virtualizing robot interfaces of corresponding offline programming functions of different types of robot; the PLC-robot bridge receiving robot state data from a corresponding type of robot via the unified virtual interface, and feeding the robot state data back to the automation controller.
In some embodiments, the PLC-robot bridge receiving the first command data, and calling a corresponding offline programming function of a corresponding type of robot via a unified virtual interface according to the first command data, comprises: the PLC-robot bridge receiving the first command data, and performing a correctness check on the first command data; when the check is passed, extracting a valid data field therefrom, and parsing the valid data field to obtain a corresponding command set, and caching the command set; reading the cached command set, and calling and running a corresponding offline programming function of a corresponding robot via the virtual interface according to the command set.
In one embodiment, the PLC-robot bridge is further used for generating a corresponding command set in conjunction with the robot state data when parsing the valid data field.
As another example, some embodiments include a multi-type industrial robot control system comprising: at least one memory and at least one processor, wherein: the at least one memory is used to store a computer program; the at least one processor is used to call the computer program stored in the at least one memory to make the system perform the multi-type industrial robot control method as described in any of the above embodiments.
As another example, some embodiments include a computer-readable storage medium with a computer program stored thereon; the computer program is executable by a processor and realizes one or more of the multi-type industrial robot control methods as described herein.
Example embodiments of the teachings of the present disclosure are described in detail below by referring to the drawings, to give those skilled in the art a clearer understanding of the abovementioned and other features and advantages of the present application. In the drawings:
Key to the drawings:
It can be seen from the above solution that because a bridge connecting the automation controller and the robot controller, i.e. the PLC-robot bridge, is provided in the embodiments of the present application, the PLC-robot bridge virtualizing robot interfaces of corresponding offline programming functions of different types of robot as a unified virtual interface, a set of general-purpose robot function blocks may be provided in the automation controller, such that the user does not need to be concerned about programming differences between different robots, and can simply use the general-purpose robot function block directly to write an instantiation control program for a robot; subsequently, the PLC-robot bridge converts command data from the automation controller to a call instruction for an offline programming function of a corresponding type of robot via the unified virtual interface, and generates a corresponding control instruction to send to the robot controller, thereby realizing control of the corresponding robot.
In addition, by further configuring data checking, parsing and buffering operations in the PLC-robot bridge, the automation controller is enabled to send batches of control commands to the PLC-robot bridge, and the PLC-robot bridge then manages the process of executing sub-commands.
Furthermore, by having the PLC-robot bridge further manage the process of executing sub-commands according to robot state data, the reliability of command execution is improved.
In the Siemens Totally Integrated Automation (TIA Portal) platform, robot-PLC (programmable logic controller) integration with many leading robots (e.g. KUKA robots, DENSO robots, STAUBLI robots and YASAKAWA MOTOMAN robots) is possible. For this purpose, KUKA robots have provided the KUKA.PLC mxAutomation function block library, DENSO robots have the DENSO Command Slave function block library, and STAUBLI robots have the STAUBLI Unival PLC function block library; these module libraries can support the integration of the products of these robot companies with the TIA Portal platform, and can eliminate programming work at the robot controller. In addition, ABB and B&R have similar concepts in machine-centered robot solutions. However, they still have the following shortcomings:
The function blocks of different robot manufacturers are incompatible, because these function blocks are custom-made by the corresponding robot manufacturer, and therefore are not suitable for robots of other manufacturers. In actual applications, an automation controller program for a robot of one particular manufacturer might not be able to be used again for integration of a robot of another manufacturer. In addition, for a robot manufacturer, the development of a PLC-robot module library requires major investment and is very difficult, and small and medium-sized robot manufacturers in particular simply do not have either the opportunity or the ability to develop a module library capable of integration with the TIA Portal platform.
Using teachings of this disclosure, however, a multi-type industrial robot control system, for a function block and a unified interface programmed for multiple types of industrial robot, a unified programming interface can screen different robots, thus allowing an automation controller program to be reused. Example embodiments are given below to explain the present application in further detail.
The automation controller 1, in addition to comprising another necessary function block 11 for automation control, also comprises a robot control function block 12; these robot control function blocks 12 may be used to perform all robot motion control and action execution related functions, including robot motion control, fault monitoring, state monitoring, robot operating parameter configuration, etc. These robot control function blocks 12 comply with a unified design standard, e.g. a function block definition or open standard, to unify and simplify the function block programming complexity. In other words, these robot control function blocks are no longer function blocks for one particular type of robot only, instead being a type of general-purpose robot control function block. These robot control function blocks are equivalent to other PLC function blocks in the TIA Portal, so a user can use these function blocks, based on a unified standard, to perform instantiation programming for the control of different robots, i.e. a user program module 13 is used to receive a control program for a robot written by the user based on the robot control function block, and run the control program by calling a corresponding function block, to obtain a command data packet; for ease of identification, this is called first command data here. The command data packet may be sent to the PLC-robot bridge 2 via a first controller communication interface 14. In addition, a robot state data packet from the PLC-robot bridge 2 may be received through the first controller communication interface 14, and serves as a data source for the robot control function block 12, to perform decision-making on robot state tracking and control logic.
As can be seen, the automation controller 1 stores a general-purpose robot control function block generated in compliance with a unified design standard; the automation controller 1 calls a corresponding robot control function block according to a control program for a robot and in conjunction with robot state data received from the PLC-robot bridge, the control program being written by the user based on the general-purpose robot control function block, and outputs corresponding first command data to the PLC-robot bridge.
The PLC-robot bridge 2 is a bridge connecting the automation controller 1 and a robot controller 3. It runs on an industrial computer or another embedded device on which a real-time operating system (such as RT-Linux) has been installed. The PLC-robot bridge 2 virtualizes robot interfaces of corresponding offline programming functions of robots of different types as a unified virtual interface, calls a corresponding offline programming function of a corresponding type of robot via the unified virtual interface according to the first command data, generates second command data, i.e. a robot command output to the corresponding robot controller 3, the corresponding robot controller 3 controls the corresponding robot, e.g. controls a mechanical arm 4 of the corresponding robot; at the same time, state data from the robot of the corresponding type is received through the unified virtual interface, and the state data is fed back to the automation controller 1.
In some embodiments, various specific forms of implementation of the PLC-robot bridge 2 are possible. For example, in one embodiment, the PLC-robot bridge 2 may be formed of modules, which convert commands of the automation controller to robot commands, and return the robot state to the automation controller 1. As shown in
The second controller communication interface 21 is used to realize a communication connection with the first controller communication interface 13 of the automation controller 1. The second controller communication interface 21 depends on an actual interface of the automation controller 1. It provides a physical interface and a communication protocol. For example, PROFINET is a common interface of a PLC 571500 controller, and communication between the PLC robot function block library and the data switch relies on the PROFINET hardware adapter and protocol. The controller communication interface 21 may also be another interface capable of transmitting real-time data.
The data switch 22 is used to receive, through the second controller communication interface 21, a command data packet from the automation controller 1, and return a robot state data packet to the automation controller 1 via the second controller communication interface 21.
The command manager 23 is used to perform a correctness check on the first command data, and when the check is passed, extract a valid data field therefrom for parsing, to obtain a corresponding command set and cache the command set. The command sets may be divided into three types: manage command sets, stop command sets and run command sets. In particular implementation, the command manager 23 may comprise a data preprocessor 231, a command parser 232 and a command buffer zone 233.
The data preprocessor 231 is used to check the correctness of data, including checking the heartbeat value, checking the transmission sequence number, checking the checksum value, checking the command check value, etc., and extracts a valid data field from the command data packet.
In some embodiments, the robot state and command execution state might affect the command execution process; therefore, the data preprocessor 231 may further receive robot state data from the robot state manager 25, and provide the robot state data to the command parser 232. In this case, the data preprocessor 231 may be further used to package the robot state data provided by the robot state manager 25, e.g. add a header field, a data validation field, a sequence number, etc., and push it to the data switch 22. Correspondingly, the robot state manager 25 may no longer package the robot state data, and no longer send data directly to the data switch 22.
The command parser 232 is used to realize command type identification, command data extraction, and the parsing of commands into corresponding command sets according to command type, then storing the command sets in the command buffer zone 233. Further, the command parser 232 may also obtain corresponding command sets in conjunction with the robot state data.
The command buffer zone 233 caches command data in the form of command sets, and can be accessed by the command execution module 24 to read command data.
The command execution module 24 accesses the command buffer zone 233 and extracts command data. The command execution module 24, via the unified virtual interface provided by the robot control APIs 26, calls and runs a corresponding offline programming function of a corresponding robot, to generate second command data. In particular implementation, different operations are performed according to different first command data; the first command data may include command type, command parameters and command execution conditions. The robot state and command execution state might affect the command execution process, so the command execution state is updated by the command manager 23, and the robot state data is provided by the robot state manager 25.
The robot state manager 25 reads robot state data via the virtual interface provided by the robot control APIs 26, including motion state data, error state data and other robot-related state data, manages the robot state data, then packages the robot state data before providing same to the data switch 22. In other embodiments, the robot state manager 25 may also provide unpackaged robot state data to the data preprocessor 231. Moreover, if the data preprocessor 231 is able to package robot state data and provide same to the data switch 22, the robot state manager 25 may no longer package robot state data and no longer provide robot state data directly to the data switch 22, instead indirectly providing robot state data to the data switch 22 via the data preprocessor 231, for feedback to the automation controller 1.
The robot control APIs 26 provide a robot interface strictly related to the actual robot. Robots of different manufacturers all have their own offline programming functions, and can call these via corresponding robot interfaces. The robot control APIs 26 are used to virtualize robot interfaces of corresponding offline programming functions of various industrial robots as a unified virtual interface. Moreover, the command execution module 24 issues commands based on the unified interface, while allowing the robot state manager 25 to read state data of various industrial robots based on the unified interface. Thus, the robot control API 26 screens different robots, and robots of different manufacturers can be controlled by the same program running on the automation controller 1.
The robot communication interface 27 depends on the actual interface form of the robot controller 3; through the robot communication interface 27, instruction data and state data are exchanged between the PLC-robot bridge 2 and the robot controller 3, including outputting the second command data to the corresponding robot controller 3, such that the robot controller 3 can control the corresponding robot, e.g. control the mechanical arm 4 of the corresponding robot; at the same time, robot state data returned by the robot controller 3 is received. The robot communication interface 27 can use the following forms: a public network port (e.g. TCP/IP protocol), an industrial Ethernet port (e.g. Ethernet CAT), a CAN interface, etc.
The multi-type industrial robot control apparatus provided in embodiments of the present application may be used to realize the functions of the PLC-robot bridge.
The multi-type industrial robot control system and apparatus in embodiments of the present application have been described in detail above; the multi-type industrial robot control method in embodiments of the present application will now be described in detail below. The multi-type industrial robot control system may be used to perform one or more of the multi-type industrial robot control method incorporating teachings of the present application. For details which are not disclosed in detail in the method embodiments of the present application, see the corresponding descriptions in the system embodiments of the present application, which are not repeated individually here.
Step 301, an automation controller receives a control program for a robot written by a user based on a general-purpose robot control function block, which is generated in compliance with a unified design standard and stored in the automation controller; and receives robot state data fed back by a PLC-robot bridge.
Step 302, a corresponding robot control function block is called according to the control program and the robot state data, and corresponding first command data is outputted to the PLC-robot bridge.
Step 303, the PLC-robot bridge receives the first command data, calls a corresponding offline programming function of a corresponding type of robot via a unified virtual interface according to the first command data, and generates second command data for output to a corresponding robot controller, which controls a corresponding robot; the unified virtual interface is obtained by virtualizing robot interfaces of corresponding offline programming functions of different types of robot.
In some embodiments, the PLC-robot bridge receives the first command data, and performs a correctness check on the first command data, and when the check is passed, extracts a valid data field therefrom, and parses the valid data field to obtain a corresponding command set, and caches the command set; reads the cached command set, and calls and runs a corresponding offline programming function of a corresponding robot via the virtual interface according to the command set.
In some embodiments, the PLC-robot bridge may be further used to generate a corresponding command set in conjunction with the robot state data when parsing the valid data field.
Step 304, the PLC-robot bridge receives robot state data from a corresponding type of robot via the unified virtual interface, and feeds the robot state data back to the automation controller.
The at least one memory 41 is used to store a computer program. In some embodiments, the computer program may be understood to comprise the various modules of the multi-type industrial robot control system shown in
The at least one processor 42 is used to call the computer program stored in the at least one memory 41, and perform the multi-type industrial robot control method in embodiments of the present application.
In some embodiments, the at least one processor 42 is used to call the computer program stored in the at least one memory 41 to make the apparatus perform corresponding operations.
The processor 42 may be a CPU, a processing unit/module, an ASIC, a logic module or a programmable gate array, etc. It can receive and send data via the communication port.
It must be explained that not all of the steps and modules in the procedures and structural drawings above are necessary; certain steps or modules may be omitted according to actual needs. The order in which the steps are performed is not fixed, and may be adjusted as needed. The division of modules is merely functional division adopted to facilitate description; in practice, one module may be realized by multiple modules, and the functions of multiple modules may be realized by the same module, and these modules may be located in the same device or different devices.
Hardware modules described in the embodiments above may be realized mechanically or electronically. For example, a hardware module may include a specially designed permanent circuit or logic device (such as a dedicated processor, such as an FPGA or ASIC) for performing specific operations. A hardware module may also include a programmable logic device or circuit configured temporarily by software (e.g. including a general-purpose processor or another programmable processor) for performing specific operations. The decision to specifically use a mechanical method or a dedicated permanent circuit or a temporarily configured circuit (e.g. configured by software) to realize a hardware module may be made on the basis of cost and time considerations.
In addition, a computer-readable storage medium is further provided in embodiments of the present application, having stored thereon a computer program which can be executed by a processor and realize the multi-type industrial robot control method in embodiments of the present application. Specifically, a system or apparatus equipped with a storage medium may be provided, wherein software program code realizing the functions of any one of the above embodiments is stored on the storage medium, and a computer (or CPU or MPU) of the system or apparatus is caused to read and execute the program code stored in the storage medium. In addition, an operating system operating on a computer, etc. may be made to complete some or all of the actual operations by means of instructions based on program code. Program code read out from the storage medium may also be written into a memory installed in an expansion board inserted in the computer, or written into a memory installed in an expansion unit connected to the computer, and thereafter instructions based on the program code make a CPU etc. installed on the expansion board or expansion unit execute some or all of the actual operations, so as to realize the functions of any of the embodiments above. Embodiments of storage media used to provide program code include floppy disks, hard disks, magneto-optical disks, optical disks (e.g. CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), magnetic tape, non-volatile memory cards and ROM. Optionally, program code may be downloaded from a server computer over a communication network.
Because a bridge connecting the automation controller and the robot controller, i.e. the PLC-robot bridge, is described, the PLC-robot bridge virtualizing robot interfaces of corresponding offline programming functions of different types of robot as a unified virtual interface, a set of general-purpose robot function blocks may be provided in the automation controller, such that the user does not need to be concerned about programming differences between different robots, and can simply use the general-purpose robot function block directly to write an instantiation control program for a robot; subsequently, the PLC-robot bridge converts command data from the automation controller to a call instruction for an offline programming function of a corresponding type of robot via the unified virtual interface, and generates a corresponding control instruction to send to the robot controller, thereby realizing control of the corresponding robot.
In addition, by further configuring data checking, parsing and buffering operations in the PLC-robot bridge, the automation controller is enabled to send batches of control commands to the PLC-robot bridge, and the PLC-robot bridge then manages the process of executing sub-commands.
Furthermore, by having the PLC-robot bridge further manage the process of executing sub-commands according to robot state data, the reliability of command execution is improved.
The above are merely example embodiments of the present application, which are not intended to limit it. Any amendments, equivalent substitutions or improvements, etc. made within the spirit and principles of the present application should be included in the scope of protection thereof.
This application is a U.S. National Stage Application of International Application No. PCT/CN2020/119428 filed Sep. 30, 2020, the contents of which are hereby incorporated by reference in their entirety.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/CN2020/119428 | 9/30/2020 | WO |
