Control system and program

Abstract

To regulate protection stop and restart in a program provided by a provider of a controller and execute it.SOLUTION: A control system 1 is equipped with user program obtaining means 162 for obtaining a user program for making a robot to execute specified work that is requested by a user and performed by a series of operation, user program executing means 164 for executing the user program, system program memory means 166 for storing a system program that regulates processing of detecting the generation of a protection stop event in the robot, processing of stopping the execution of the user program when the protection stop event is generated, and processing of restarting the execution of the user program from a predetermined recovery position of the user program, and system program executing means 168 for executing the system program.SELECTED DRAWING: Figure 3

Description

Technical Field

[0001] The disclosed technology relates to control systems and programs.

Background Art

[0002] In the field of FA (Factory Automation) in the production site, various technologies for controlling robots responsible for automation have been developed. For robot control, there is a mechanism for controlling the operation from stop to restart when the robot stops suddenly due to some factor.

[0003] For example, there is a technology related to a robot control device for shortening the operation restart time when the robot stops suddenly (see Patent Document 1). In this technology, a signal for instructing a backward movement causes the robot to move backward step by step to restart the operation of the robot.

[0004] Also, there is a technology related to a robot control method that enables prevention of so-called "chocolate stops" caused by misalignment of work target parts, etc. (see Patent Document 2). In this technology, it is determined whether the position error of each detected work target part with respect to its normal position is within the allowable range.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Patent Document 2

Patent Document 3

Summary of the Invention

Problems to be Solved by the Invention

[0006] In the conventional robot control systems mentioned above, the control related to stopping and restarting the robot was defined in the program that controls the robot's movements.

[0007] However, modern factory automation (FA) systems are becoming more sophisticated, often involving robots composed of multiple components, such as image sensors and grippers, each of which is a control target, or multiple robots working in coordination. In such advanced FA systems, it is assumed that integrated control is performed by a higher-level integrated controller, while individual robots are controlled by separate robot controllers. In a control system using an integrated controller, two different programs are defined: a system program and a user program.

[0008] For example, there is a technology relating to a control device that provides a configuration capable of efficiently running multiple types of programs with different execution formats on a single control device (see Patent Document 3). In Patent Document 3, a system program is a program for realizing basic functions. In Patent Document 3, a user program is a general term for programs prepared according to the user's specific control purposes. User programs also include programs such as IEC programs, which are scanned entirely each time they are executed and can output control commands each time they are executed.

[0009] In prior art such as Patent Documents 1 and 2, there was no assumption that a control system would use a system program and a user program separately; robot control was always assumed to be done solely through a user program. Furthermore, in conventional factory automation (FA), it was assumed that a robot used for work would repeat a series of the same movements, and therefore, an emergency stop caused by torque overload meant that a dangerous situation had occurred that should not have happened during normal operation, requiring human (user) intervention for safety checks and recovery.

[0010] However, in a control system that uses both a system program and a user program, it is not possible to apply conventional techniques for stopping and restarting. When the system program stops the robot, the execution of the user program is stopped in consideration of the consistency of processing between the programs, so it is not possible to define stopping and restarting actions in the user program. Furthermore, if the system is designed to involve the user in exception handling for restarting operations after stopping, as in the past, the user will have to be involved every time it stops, which is cumbersome for the user. In addition, the control method of the system program in Patent Document 3 is limited to the means for executing processing related to priority changes, and other control methods are not specified.

[0011] This disclosure is made in view of the above points and aims to provide a control system and program that can define and execute protection suspension and resumption in a program provided by the controller provider. [Means for solving the problem]

[0012] A first aspect of the disclosure is a control system comprising: a user program acquisition means for acquiring a user program for causing a robot to perform a specific task requested by a user, which is performed by a series of actions; a user program execution means for executing the user program; a system program storage means for storing a system program that defines a process for detecting the occurrence of a protective stop event in the robot, a process for stopping the execution of the user program when the protective stop event occurs, and a process for resuming the execution of the user program from a predetermined return position of the user program; and a system program execution means for executing the system program.

[0013] In the first embodiment described above, the process for resuming the execution of the user program may be configured such that the resumption requirements are met as a condition for resumption.

[0014] In the first embodiment described above, the restart requirement may include at least one of the following: no malfunction was detected as a result of the self-diagnosis, and the deviation between the robot's position and orientation after protective shutdown and the planned position and orientation corresponding to that position and orientation is within a reference value.

[0015] In the first embodiment described above, the system program may further define a process to make available to the user program the restart data to be used in the execution of the user program after restart.

[0016] In the first embodiment described above, the restart data may include a stop area, which is the area where the execution of the user program stopped.

[0017] In the first embodiment described above, the system may further include means for acquiring return position data, wherein the return position data includes a plurality of return positions in the user program associated with a plurality of candidate stop areas of the user program, and the process for resuming the execution of the user program is a process for resuming the execution of the user program according to the return position data.

[0018] A second aspect of the disclosure provides a system that includes a user program acquisition means for acquiring a user program that causes a robot to perform a specific task requested by a user, which is performed by a series of actions; a user program execution means for executing the user program; a system program storage means for storing a system program that defines a process for detecting the occurrence of a protective stop event in the robot; a process for stopping the execution of the user program when the protective stop event occurs; and a system program storage means for storing a system program that defines a process for resuming the execution of the user program from a predetermined return position of the user program; and a system program execution means for executing the system program, comprising one or more computers in cooperation with the system program execution means. [Effects of the Invention]

[0019] According to the control system and program of the present invention, protection stop and restart can be defined in the program provided by the controller provider and executed.

Brief Description of the Drawings

[0020] [Figure 1] It is a diagram schematically showing an overall configuration example of the control system. [Figure 2] It is a block diagram showing a hardware configuration example of the integrated controller according to the present embodiment. [Figure 3] It is a diagram showing a functional configuration of the integrated controller. [Figure 4] It is sequence control when transmitting a command from the integrated controller to the robot controller to execute a script. [Figure 5] It is sequence control when directly transmitting a command from the integrated controller to the robot for control. [Figure 6] It is a diagram schematically showing the control content for executing the operation of inserting a component into the work plate. [Figure 7] It is an example of a control flow when executing the operation of inserting a component. [Figure 8] It is an example of the acquired data of the robot used for the determination of protection stop. [Figure 9] It is an example of a control flow for protection stop determination. [Figure 10] It is an example of an information source that can be used for restart determination after protection stop. [Figure 11] It is a control flow for restart determination after protection stop. [Figure 12] It is a control flow for return by a user program. [Figure 13] It is an example of a return position and a return position table for the control flow when executing the operation of inserting a component. [Figure 14] It is a diagram schematically showing a case of pulling a cable attached to the robot. [Figure 15]This diagram schematically illustrates a case where an externally fixed cable, such as an external tool, is pulled. [Figure 16] This diagram schematically illustrates a case where a robot's robotic arm experiences an overload while opening or closing a door, such as a freezer door, causing the arm to shut down as a protective measure. [Modes for carrying out the invention]

[0021] Hereinafter, an example of an embodiment of the present invention will be described with reference to the drawings. In each drawing, identical or equivalent components and parts are given the same reference numerals. Also, the dimensional ratios in the drawings are exaggerated for illustrative purposes and may differ from the actual ratios.

[0022] In this embodiment, the control system defines the process of controlling a robot on the production floor using a system program of an integrated controller and a user program. In this embodiment, the processing of the system program and the user program is defined assuming that a protective stop event occurs in the robot. In this embodiment, the system program defines the process of stopping and restarting the execution of the user program when a protective stop event occurs in the robot. Details of "protective stop" and "protective stop event" will be described later.

[0023] (Example of overall control system configuration) Figure 1 is a schematic diagram showing an example of the overall configuration of a control system. As shown in Figure 1, in the control system 1, the integrated controller 100 is connected to the tool terminal 200 via USB or the like, and communicates with various devices and controllers via network N. Network N consists of an upstream information network N1 and a downstream field network N2. The information network N1 is connected to the management terminal 202 and the server device 210, etc. The field network N2 is connected to various controllers of the robot application RA. It may also be connected to other I / O devices and various sensors. The robot application RA includes a robot controller 300, an image sensor controller 302, and a gripper controller 304, and these various controllers control the operation of the robot 400. The integrated controller 100 is an example of a "controller" in the technology of this disclosure.

[0024] The tool terminal 200 is a device that assists the integrated controller 100 in making the necessary preparations to control the controlled object. Specifically, the tool terminal 200 provides a development environment for programs executed on the integrated controller 100 (program creation and editing tools, parser, compiler, etc.), a configuration environment for setting parameters (configurations) of the integrated controller 100 and various devices connected to the integrated controller 100, a function to output the generated user program to the integrated controller 100, and a function to modify and change the user program executed on the integrated controller 100 online.

[0025] The management terminal 202 is a terminal used for monitoring and managing the entire production process, and manages the integrated controller 100 and the server device 210. The server device 210 is envisioned to include a database system, a manufacturing execution system (MES), etc. The manufacturing execution system acquires information from controlled manufacturing equipment and facilities to monitor and manage the entire production process, and can handle order information, quality information, shipping information, etc. However, it is not limited to this; devices providing information services may also be connected to the information network N1. Information services are envisioned to include processes that acquire information from controlled manufacturing equipment and facilities and perform macro or micro analysis. For example, data mining to extract characteristic trends from information from controlled manufacturing equipment and facilities, or machine learning tools for performing machine learning based on information from controlled equipment and machines are envisioned.

[0026] The robot controller 300 performs trajectory calculations and angle calculations for each axis according to control commands (position commands or velocity commands, etc.) from the integrated controller 100, and drives the servo motors (not shown in the figure) and other components of the robot 400 according to the calculation results. The image sensor 402 attached to the robot 400 is controlled by the image sensor controller 302, and the gripper 404 is controlled by the gripper controller 304. In addition, the teaching pendant 310 is used to change the parameters of the robot 400 and adjust its operation.

[0027] (Example hardware configuration of integrated controller 100) Next, an example of the hardware configuration of the integrated controller 100 according to this embodiment will be described. Figure 2 is a block diagram showing an example of the hardware configuration of the integrated controller 100 according to this embodiment.

[0028] As shown in Figure 2, the integrated controller 100 is an arithmetic processing unit called a CPU unit and includes a processor 102, a chipset 104, main memory 106, storage 108, a higher network controller 110, a USB (Universal Serial Bus) controller 112, a memory card interface 114, an internal bus controller 120, and a field network controller 130.

[0029] The processor 102 consists of a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a GPU (Graphics Processing Unit), etc. The processor 102 may have a configuration with multiple cores, or multiple processors 102 may be arranged. That is, the integrated controller 100 has one or more processors 102, and / or one or more processors 102 having multiple cores. The chipset 104 controls the processors 102 and peripheral elements to realize the overall processing of the integrated controller 100. The main memory 106 consists of volatile storage devices such as DRAM (Dynamic Random Access Memory) and SRAM (Static Random Access Memory). The storage 108 consists of non-volatile storage devices such as HDD (Hard Disk Drive) and SSD (Solid State Drive).

[0030] The processor 102 reads various programs stored in the storage 108, expands them into the memory 106, and executes them to perform control according to the controlled object, as well as various processes as described later. The storage 108 stores user programs 30 created according to the manufacturing equipment and facilities such as the robot 400 to be controlled, system programs 32 for realizing the basic functions of the control system 1, and setting information 34 for making various settings. The system program 32 is a program provided by the provider of the integrated controller 100.

[0031] The higher-level network controller 110 controls data exchange with the server device 210 and other devices via the information network N1. The USB controller 112 controls data exchange with the tool terminal 200 via the USB connection.

[0032] The memory card interface 114 is configured to allow the insertion and removal of a memory card 116, enabling data to be written to the memory card 116 and various types of data (such as user programs and trace data) to be read from the memory card 116.

[0033] The internal bus controller 120 controls data exchange with the I / O unit 122 installed on the integrated controller 100. The field network controller 130 controls data exchange with the robot application RA via the field network N2.

[0034] Figure 2 shows an example configuration in which the processor 102 provides the necessary functions by executing a program. However, some or all of these provided functions may be implemented using dedicated hardware circuits (e.g., ASIC or FPGA). Alternatively, the main part of the integrated controller 100 may be realized using hardware that conforms to a general-purpose architecture (e.g., an industrial PC based on a general-purpose PC). In this case, virtualization technology may be used to run multiple operating systems (OS) with different purposes in parallel, and to run the necessary applications on each OS.

[0035] Furthermore, in the control system 1 shown in Figure 2, the integrated controller 100, tool terminal 200, and management terminal 202 are configured as separate units, but a configuration in which all or some of these functions are integrated into a single device may also be adopted.

[0036] (Example of functional configuration of integrated controller 100) Figure 3 shows the functional configuration of the integrated controller 100. Functionally, the integrated controller 100 includes a program function unit 160, a higher-level network interface 170, and a field network interface 172. The program function unit 160 is a functional unit that combines means for performing overall execution control functions related to the user program 30 and the system program 32. The program function unit 160 includes a user program acquisition means 162, a user program execution means 164, a system program storage means 166, and a system program execution means 168. The program function unit 160 also performs the function of processing data stored in memory (not shown) and processing results by the user program execution means 164 or the system program execution means 168 into data for output to the user or others.

[0037] The upper-level network interface 170 mediates data exchange with devices connected via the information network N1. The field network interface 172 mediates data exchange with various robots 400 connected via the field network N2.

[0038] The user program acquisition means 162 acquires the user program 30 from various devices capable of holding or inputting the user program 30 by some means. The user program acquisition means 162 includes the following: Firstly, when the control system 1 acquires the user program 30 from the tool terminal 200, it includes the hardware and software of the communication interface between the control system 1 and the tool terminal 200. Secondly, when the control system 1 has an editing function for the user program 30 and inputs the user program 30 from an input device such as a keyboard, it includes the input device and related software. Thirdly, when the control system 1 acquires the user program 30 from a library of user programs 30 stored in a server device 210 or the like via the information network N1, it includes the hardware for network communication and the software involved in acquiring the user program 30.

[0039] The system program storage means 166 is a means for storing the system program 32, and a program-storage means such as ROM and memory is used.

[0040] The user program execution means 164 is a means for executing the user program 30. The system program execution means 168 is a means for executing the system program 32. The user program execution means 164 and the system program execution means 168 include the following: hardware such as a general-purpose processor and ASIC included in the control system 1, and software that manages resources and timing for user program execution. Furthermore, the entities of the user program execution means 164 and the system program execution means 168 may be the same or they may be different entities.

[0041] The system program 32 is a program for realizing the basic functions of the control system 1, and in this embodiment, various processes related to protective shutdown are defined in a part of the system program 32. The various processes related to protective shutdown are a process for detecting the occurrence of a protective shutdown event in the robot 400 (occurrence detection process), a process for stopping the execution of the user program 30 when a protective shutdown event occurs (execution stop process), and a process for resuming the execution of the user program 30 from a predetermined return position of the user program 30 (restart process). Thus, the system program 32 includes a provision for a process for stopping the execution of the user program 30 when a protective shutdown event occurs. As a result, the operation of the robot 400 stops when a protective shutdown event occurs. Furthermore, processes such as a process for braking the movement of the robot 400 to quickly stop the movement of the robot 400 and a process for maintaining the position and orientation of the stopped robot 400 may be added.

[0042] (Definition of "Protection Deactivation" and "Protection Deactivation Event") Here, "protective stop" in this embodiment will be explained. "Protective stop" refers to stopping the operation of the robot 400 when the robot 400 comes into contact with an object in the surrounding area, when there is a risk of unplanned contact, or when a high load is placed on the operation of the robot 400, with the aim of preventing damage to the robot itself or surrounding objects. Surrounding objects include the human body.

[0043] The decision to stop operation when the robot 400 comes into contact with an object in its surroundings can be made based on the detection results regarding the magnitude of the force the robot experiences due to the contact. To detect the magnitude of the force the robot 400 experiences, the torque values ​​applied to the motors driving the robot's joints or the detection values ​​from the force sensors installed in the robot 400 can be used. The same method can be used to decide whether to stop operation when a high load occurs.

[0044] The decision to stop operation when there is a risk of the robot 400 making unplanned contact with surrounding objects can be made based on detection results from sensors such as cameras that monitor the surrounding environment of the robot.

[0045] A "protective shutdown event" is an event that causes a protective shutdown. Examples of protective shutdown events include the robot being subjected to a force exceeding a specified magnitude, or the presence of an object around the robot that could cause unplanned contact.

[0046] (Robot control) The robot control of the control system 1 is assumed to be performed in two ways, for example, (A) by sending commands from the integrated controller 100 to the robot controller 300 to execute a script, and (B) by sending commands directly from the integrated controller 100 to the robot 400 for control. These will be explained with reference to Figures 4 and 5. In addition, each task executed by the integrated controller 100 has a defined priority and is triggered at each control cycle T1, as described in Patent Document 3. The first task 10 performs an input / output refresh process (referred to as "O / I" in Figures 4 and 5, and hereafter as O / I processing) to update input values ​​and control commands with the field. The program for performing the input / output refresh process belongs to the system program 32. The task with the next priority after the first task 10 is the second task 18. In the second task 18, a program according to the user's control purpose is executed. Specifically, the second task 18 includes a sequence process 12 that executes a sequence program, a first robot control program process 14 (RP14) that executes a first robot control program, and a motion control program process 16 (MC16) that executes a motion control program. The sequence program, the first robot control program, and the motion control program belong to the user program 30. In the sequence processing 12, the sequence program is executed from beginning to end in one control cycle T1. The sequence program is responsible for controlling devices surrounding the robot, such as transport devices. The first robot control program is responsible for controlling the robot. Alternatively, the sequence program executed in the sequence processing 12 may be made responsible for controlling the robot without providing the first robot control program processing 14. The motion control program is a program for calculating numerical values ​​such as position, velocity, acceleration, jerk, angle, angular velocity, angular acceleration, and angular jerk as control commands for actuators such as servo motors.

[0047] The robot control in case (A) will be explained with reference to Figure 4. In the control cycle T1a, the first robot control program processing 14 of the second task generates a script execution command (hereinafter sometimes simply referred to as a command). In the O / I processing of the first task in the next control cycle T1b, the generated script execution command is sent to the robot controller 300. Although not shown in the diagram for convenience, the system program 32 runs in the background and includes a scheduler that controls the execution timing of each program shown, and a program that monitors the occurrence of protective stop events. The script execution command may be sent at any timing, such as immediately after the execution of the first robot control program processing 14, rather than as part of the O / I processing.

[0048] The robot controller 300 executes control at each control cycle T1. It receives commands (20), executes the script of the received command (22), and sends an execution completion notification to the integrated controller 100 (24). The control cycle T1 of the robot controller 300 is preferably the same length as the control cycle T1 of the integrated controller 100 and is synchronized, but it may be a different length or asynchronous. Alternatively, the control cycle of the robot controller 300 may be shorter than the control cycle T1 of the integrated controller (for example, half the length), and the script may be executed at each control cycle T2. This would allow for smoother robot control. In this case, the script is of a size that can be completed within the control cycle T2. In this case as well, communication between the integrated controller 100 and the robot controller 300 takes place at each control cycle T1.

[0049] The robot control in case (B) will be explained with reference to Figure 5. In Figure 5, a third task 26 is added as a task executed by the integrated controller 100. The third task 26 has a lower priority than the second task 18 and is executed with a period twice the length of the control period T1. The second robot control program is executed in the third task 26. The second robot control program belongs to the user program 30. The second robot control program is a program that is responsible for controlling a part of the robot 400, such as the gripper. The contents of the second robot control program correspond to the script executed by the robot controller 300 in case (A). The command for the gripper of the robot 400 generated in the third task processing 26 is sent to the robot controller 300 as part of the O / I processing. The command generated in the third task processing 26 is not sent in the O / I processing of code (1) in control period T1b, when the execution of the third task processing is not yet complete, but is sent in the O / I processing of code (2) in control period T1c, after the execution is complete. Furthermore, the first robot control program executed in the second task 18 may specify content equivalent to a script executed by the robot controller 300 in case (A), and the execution of the first robot control program may generate commands for the robot 400.

[0050] The robot control methods (A) and (B) may be used individually, or they may be used interchangeably depending on the part being controlled. For example, the joints of the robot arm can be controlled using method (A), while the opening and closing of the gripper can be controlled using method (B). Methods (A) and (B) may also be used interchangeably within the same task, for example, in the second task 18.

[0051] A protective stop event may occur during robot operation control. The handling of a protective stop event is specified in system program 32.

[0052] (Control related to the work example) Next, we will explain the control flow for the case where the control content is for executing an example of inserting a part into a work plate. The control method may be either the method of generating execution commands for the script described in (A) above, or the method of directly generating commands for the robot described in (B). Figure 6 is a schematic diagram showing the control content for executing the task of inserting a part into a work plate. As shown in Figure 6, the task is assumed to be inserting part A, which is placed on tray Ra, into the hole at insertion position Pi on work plate Rb. Insertion is divided into trial insertion and final insertion processes.

[0053] Figure 7 shows an example of a control flow when performing the operation of inserting a component.

[0054] In S10, the image sensor 402 captures an image of the tray Ra and obtains the part position Pa of part A. Here, "part position" refers to information representing the position and orientation of the part.

[0055] In S12, the gripper 404 is moved to a position where it can grasp part A at the acquired part position Pa, and part A is grasped by the gripper 404.

[0056] In S14, the gripped part A is moved to the insertion position Pi and pushed into the hole (corresponding to the temporary insertion process). Temporary insertion is the operation of moving part A to the insertion start position Pi and then pushing part A into the hole until a portion of part A is in the hole and part A does not fall out even when the gripper 404 is opened. Since the gripper 404 grips the side of part A, part A cannot be inserted deeply without temporary insertion.

[0057] In S16, the gripper 404 is opened, moved to the rearward starting position (Pr) of the main insertion relative to the insertion position Pi of the work plate Rb, and then the gripper 404 is closed.

[0058] In S18, the closed gripper 404 is used to push in the temporarily inserted part A (corresponding to the final insertion process), and the final insertion is completed by pushing it in until it reaches a predetermined depth or the bottom of the hole.

[0059] In S20, the gripper 404 is moved to a predetermined retraction position behind the insertion position Pi of the work plate Rb, and the operation is completed. Note that the control in S10 to S20 is just an example, and other control methods may be used.

[0060] (Decision to suspend protection) Next, an example of protective shutdown determination will be explained. The protective shutdown determination process described below is one aspect of the process by which the system program 32 stops the execution of the user program 30. Figure 8 shows an example of data acquired by the robot 400 used for protective shutdown determination. The robot controller 300 acquires force information from the force sensor of the robot 400 and current values ​​from the current detectors of each axis motor of the robot 400. The integrated controller 100 acquires the force information and current values ​​from the robot controller 300 as part of the O / I process shown in Figure 4.

[0061] Figure 9 shows an example of the control flow for protective shutdown determination. The control flow for protective shutdown determination is executed in the system program 32. As information necessary for controlling protective shutdown determination, the configuration information 34 of the integrated controller 100 stores thresholds defined for force information related to protective shutdown, thresholds defined for torque levels related to protective shutdown, and torque constants for converting current values ​​into torque.

[0062] In S30, force information from the force sensor and current values ​​for each axis motor are acquired.

[0063] In S32, it is determined whether the acquired force feedback information is above or below the threshold defined for force feedback information. If it is above the threshold, the process proceeds to S38 (protection stop); otherwise, the process proceeds to S34.

[0064] In S34, the acquired current values ​​for each axis motor are converted into torque based on the torque constant.

[0065] In S36, it is determined whether the converted torque is above or below a defined threshold for the torque level. If it is determined to be above the threshold, the process proceeds to S38 (protection stop). If it is determined to be below the threshold, protection stop is deemed unnecessary, and the process terminates.

[0066] In S38, the robot 400 is put into protective shutdown mode. This protective shutdown is performed by stopping the user program 30. Once the execution of the user program 30 is stopped, no further motion commands are issued, and the robot 400 will no longer move in response to new motion commands.

[0067] S40 saves debugging information when protection is disabled.

[0068] When stopping the execution of the user program 30, it is preferable to cancel any motion commands that are currently being executed. This prevents, for example, a speed command that is currently being executed from remaining valid and causing the motors of the robot 400 to continue to be driven. This cancellation process may be described in the system program 32, or the part of the robot 400 that drives the motors may be configured to automatically cancel any currently executed commands if no commands are received at regular intervals.

[0069] The system program 32 may also include processes for braking the movement of the robot 400 in order to quickly stop the robot 400's movement, and processes for maintaining the position and orientation of the stopped robot 400.

[0070] Furthermore, while the control flow for protective stop determination in Figure 9 describes the case where protective stop is determined based on force information and torque, the determination may also be made based on the detection results of surrounding obstacles by the image sensor 402 or the overload information of the gripper.

[0071] (Decision to resume) Next, an example of a restart decision after a protective shutdown will be explained. Figure 10 shows an example of information sources that can be used for a restart decision after a protective shutdown. The "restart decision" in system program 32 is provided with the following inputs from each information source: detection results from "image processing", gripper information from "gripping control", the position of the robot 400 and force information / torque information (current value) from "robot control", and the shutdown area of ​​the user program 30, self-diagnosis results, debug information, etc. from "robot diagnosis". The restart decision process described below is one aspect of the process by which system program 32 restarts the execution of user program 30 from a predetermined return position of user program 30. In system program 32, the process of restarting the execution of user program is conditional on the restart requirements being met.

[0072] Furthermore, the system program 32 specifies a process to make available to the user program 30 the restart data used in the execution of the user program 30 after it has been resumed. The restart data may also include the stop area, which is the area where the execution of the user program 30 was stopped.

[0073] Figure 11 shows the control flow for determining whether to restart protection after it has been stopped.

[0074] S50 acquires various diagnostic information, including gripper diagnostic information, image sensor diagnostic information (detection results), and robot diagnostic information.

[0075] In S52, the system uses the acquired diagnostic information to determine whether or not there is a malfunction. The determination in S52 is an example of "no malfunction detected as a result of self-diagnosis" in the restart requirements of this disclosure. If it is determined that there is a malfunction, the system proceeds to S64; if it is determined that there is no malfunction, the system proceeds to S54. Whether or not there is a malfunction can be determined by whether any of the diagnostic information includes a diagnosis of malfunction. In addition, temporary malfunctions that do not hinder the continued operation of the robot 400, such as when a communication error occurs but normal communication is immediately resumed, are treated as "not a malfunction".

[0076] In S54, debug information is obtained at the time of stopping. This debug information includes the trajectory planned by user program 30, which was running at the time of stopping.

[0077] In S56, the system determines whether any abnormal events other than malfunctions have occurred in the debug information that would hinder recovery from a protective stop. An example of an abnormal event is the detection that the target object is damaged. If an abnormal event is determined to have occurred, the system proceeds to S64; if no abnormal event has occurred, the system proceeds to S58.

[0078] In S58, the current position and orientation of robot 400 are acquired.

[0079] In S60, the current position and orientation are compared with the planned trajectory to determine whether the current position and orientation deviate from the trajectory planned by the user program 30. If it is determined that there is no deviation, the process proceeds to S62; if it is determined that there is a deviation, the process proceeds to S64. Whether there is a deviation can be determined by checking whether the current position and orientation deviate from the planned trajectory by more than a reference value. The planned trajectory is the position and orientation of the robot 400 along the planned trajectory. Preferably, this is determined by comparing the last commanded position that was executed with the detected position.

[0080] The determination in S60 above is an example of the requirement in this disclosure that "the deviation between the robot's position and orientation after protection has been stopped and the planned position and orientation corresponding to that position and orientation is within a certain limit."

[0081] In S62, the system determines whether recovery is possible as "True" (recoverable) and proceeds to S66.

[0082] In S64 mode, the system determines whether recovery is possible to "False" (recovery impossible) and terminates the process.

[0083] As a restart requirement for determining whether the system is ready to resume operation, the cause of the protective shutdown may be added as the reason for the shutdown. For example, if the protective shutdown occurred due to force feedback, torque, or a high load on the gripper, the condition that the high load has been resolved for a certain period of time may be added as a restart requirement. Also, if the protective shutdown occurred based on a detection result indicating that the robot 400 is at risk of unplanned contact with a surrounding object, the determination that the risk of unplanned contact has been eliminated because the detected object is no longer detected may be added as a restart requirement.

[0084] In S66, the user program 30 is notified of the stopping area as restart data, and the user program 30 is instructed to start execution from its recovery position.

[0085] A stop area is a region in the user program 30 that includes the instruction steps of the user program 30 that were being executed when the protective stop occurred. The stop area is set as a region corresponding to one or a sequence of robot element movements that is suitable to be identified as a stop position. For example, the region of the user program 30 corresponding to the temporary insertion operation and the region of the user program 30 corresponding to the permanent insertion operation in the embodiment can be considered to correspond to the position where the execution of the user program 30 stopped if the execution of the user program 30 stops within that region. Notification is made, for example, by storing data that identifies the stop area in a memory area that can also be accessed from the user program 30.

[0086] The restart data may include, in addition to the stopping area, the time when the execution of user program 30 was stopped, the position and orientation of the robot 400 when the execution of user program 30 was stopped, the torque and force sensor detection values ​​that the robot 400 was receiving when the execution of user program 30 was stopped, and the detection results of image data including surrounding objects that were captured at or after the execution of user program 30 was stopped.

[0087] (Control flow by user program 30 after recovery) Figure 12 shows the control flow by the user program 30 after recovery. Figure 13 shows an example of the recovery position and recovery position table for the control flow when performing the operation of inserting a component.

[0088] In S70, the stop area is acquired. In S72, the process is branched based on whether the stop area corresponds to temporary insertion (Pg1) or permanent insertion (Pg2). In S74 (S74A, S74B), the process is branched based on whether the component has fallen or not. If it has fallen, the process proceeds to Rp1 (S76). In S74A, if it has not fallen, the process proceeds to Rp2 (S80). In S74B, if it has not fallen, the process returns to Rp3 in Figure 13.

[0089] In S76, the position of the falling part A is detected by the image sensor 402. In S78, the gripper 404 grasps part A and controls it to place it in the sorting box, and the system returns to its original state by transitioning to A in Figure 13.

[0090] In the S80, the part is restored by pulling part A out of the hole and moving it to part B in Figure 13.

[0091] The return location of the user program 30 is provided to the system program 32, for example, as a variable storing the return address.

[0092] Furthermore, the control flow by the user program 30 after recovery is not limited to the flow described above. For example, during the temporary insertion operation, part A may become engaged with a hole and be unable to move any further in. If part A is pushed in further at this point, a protective stop may occur. In this case, part A may be pulled out of the hole and the temporary insertion operation may be restarted. Instead of immediately restarting the temporary insertion operation after pulling out part A, part A may be pulled out, returned to the sorting box, and then the returned part A may be re-gripped and the temporary insertion operation restarted.

[0093] By inserting a compliance module into the connection between the robot arm and the gripper, or by providing an elastic material layer on the gripper's gripping surface, part A can move guided by the chamfers on the edges of part A and the hole. This makes it easier to successfully perform a trial insertion on the first attempt, even if there is a slight misalignment between part A and the hole, and also increases the success rate when the trial insertion is repeated. In some cases, simply repeating the trial insertion operation is sufficient for success.

[0094] Furthermore, if the insertion operation is stopped due to protection, the gripper's fingertips that were pressing on part A should be released from part A, and the insertion operation should be restarted. If the protection operation is repeatedly stopped even after attempting to restart the insertion operation a predetermined number of times, part A may be grasped, pulled out of the hole, returned to the sorting box, grasped again, and the temporary insertion operation restarted.

[0095] In the above explanation, the user program 30 has a single return position, and the user program 30 is responsible for the operation flow after the return. However, the system program 32 may select a return position from among several prepared return positions, thereby changing the control operation performed by the user program 30 after the return. The selection of the return position is performed, for example, according to the return position table in Figure 13. The return position table shows the return positions according to the post-stop component state for each of the candidate stop areas, stop area Pg1 and stop area Pg2. The return position table is provided to the integrated controller 100 along with the user program 30 and is accessible from the system program 32. The return position table is accompanied by information on how to identify the post-stop component state (whether the component did not fall or fell). The method for identifying the post-stop component state is, for example, to query the image processing unit that processes the image from the image sensor 402 and obtain a determination result of whether the component did not fall or fell. Also, depending on the content of the operation defined by the user program 30, there may be cases where there is no distinction such as the post-stop component state, and the return position table is determined according to the stop area. The return position table is an example of the return position data in this disclosure.

[0096] Furthermore, in the functional configuration of the integrated controller 100 shown in Figure 3, a means for acquiring return position data may be further provided to acquire return position data, thereby acquiring information from the above-mentioned return position table.

[0097] Furthermore, if the robot 400 stops its operation based on a determination (detection result) that there is a risk of unplanned contact with an object in its surroundings, the start position of the stop area in the user program 30 may be used as the return position. Also, if the operation stops based on such determination, it may be decided that the user program 30 will continue executing the steps immediately following the stop step without going back through any steps.

[0098] (Cases related to protection suspension events) This section describes cases related to protective shutdown events. For example, when a temporary overload occurs due to cable pulling, a protective shutdown event may occur even if there is no physical contact during operation. Also, due to variations in components, protective shutdown events may occur in cases where the same parameter operation succeeds or fails depending on the target object. In this case, it is generally expected that success can be achieved by changing the combination of components.

[0099] There are cases where a cable is attached to the robot 400. Figure 14 schematically shows a case where the cable attached to the robot 400 is pulled. In Figure 14 (A), the movement of the robot 400 causes the cable to be pulled, and a force in the opposite direction or a similar direction to the movement of the robot 400 or the robot hand is detected, causing a protective stop. This force can be detected by a force sensor on the wrist, etc. The cable is pulled when the robot arm extends. This pull can be calculated if a model of the robot 400 itself is available. In this case, as a recovery method, it is assumed that the robot hand will be moved in the direction that bends the robot arm, as shown in Figure 14 (B), to loosen the cable and then resume operation.

[0100] Furthermore, when pulling on a cable, it is conceivable that the cable may be pulled by an externally fixed cable, such as an external tool. As shown in Figure 15, if the robot 400 is gripping tool Ta and the robot 400's hand is moving away from the controller Tb to which tool Ta's cable is fixed, and an overload of force is detected in the opposite direction of movement by wrist force sensing, it is determined that the cable has been overloaded by tool Ta. The recovery method is as follows: (1) If the robot 400 has two arms, switch tool Ta to the arm that is not stopped. (2) If it has one arm, restart as is and move the robot 400's hand in the direction of loosening the cable. The loosening direction is the opposite direction of the original movement, towards the controller Tb. After moving, initialize the accumulated cable tension and resume work. If the cause of tension on the cable is that the cable has become entangled with another item (not shown), operate the robot 400 to untangle the cable before resuming work. It is also possible that the tool Ta may need to be released, picked up again, and then the work may need to be resumed.

[0101] Furthermore, as shown in Figure 16, it is conceivable that during the process of opening a freezer door or the like with the robot arm of robot 400, an overload may occur while the door is slightly ajar, causing robot 400 to shut down in protective mode. In this case, the AGV (Automatic Guided Vehicle) carrying robot 400 would first be moved in the direction that the door would close to close it, and then the AGV would be repositioned to reduce the load on the arm before resuming the door-opening operation. In LA (Laboratory Automation), there is a perspective that prioritizes minimizing temperature changes inside the freezer, that is, in this case, closing the freezer door as quickly as possible, rather than simply performing the task of opening the door. Therefore, a control system that moves only the AGV to first close the door is envisioned.

[0102] As described above, according to the control system 1 of this embodiment, protective shutdown and restart can be defined and executed in the system program 32 provided by the provider of the integrated controller 100.

[0103] The following provides further details regarding the aspects of the control system 1 in the above embodiment. The control system 1 can be implemented in the following forms in the embodiment. The control system 1 can be implemented as an apparatus equipped with each means, or as a plurality of interconnected apparatuses collectively equipped with each means, as at least one of the following (A1) and (A2).

[0104] (A1) For example, in one embodiment, when the integrated controller 100 determines a command to the robot 400, the program executed by the integrated controller 100 for determining the command to the robot 400 corresponds to the user program 30.

[0105] (A2) In one embodiment, the integrated controller 100 may instruct the robot controller 300 to execute a script. In this case, at least the program executed by the integrated controller 100 to determine the script execution instruction corresponds to the user program 30. The script executed by the robot controller 300 also corresponds to the user program 30 if it is created to cause the robot to perform all or part of a specific task that is requested by the user and is carried out by a series of actions. However, if the script is created only for general elemental actions such as "opening or closing" the gripper 404, it does not correspond to the user program 30.

[0106] The system program 32 is not limited to being stored and executed only in the integrated controller 100. In both of the embodiments described in (A1) and (A2) above, the system program 32 may be stored and executed in either the integrated controller 100 or the robot controller 300, or shared between both. In both of the embodiments described in (A1) and (A2) above, the robot controller 300 drives each motor of the robot 400 to perform actions that realize commands determined by the integrated controller 100 or commands generated by executing a script in the robot controller 300. The control system 1 may also be a device that combines the functions of the integrated controller 100 and the robot controller 300.

[0107] Furthermore, the control system 1 can be implemented as a system that cooperates with the robot 400 via a wide-area network.

[0108] For example, only the function of the robot controller 300 of the embodiment that drives each motor of the robot 400 may be placed near the robot 400, and this may be connected to the internet, while each means (user program acquisition means 162, user program execution means 164, system program storage means 166, system program execution means 168) may be placed on one or more computers connected to the internet.

[0109] The above embodiments are merely illustrative examples illustrating the configuration of the present invention. The technology disclosed herein is not limited to the specific forms described above, and various modifications are possible within the scope of its technical concept.

[0110] Furthermore, the processing that the CPU reads and executes in the above embodiment may be executed by various processors other than the CPU. Examples of such processors include PLDs (Programmable Logic Devices) such as FPGAs (Field-Programmable Gate Arrays) whose circuit configuration can be changed after manufacturing, and dedicated electrical circuits that are processors with circuit configurations specifically designed to execute recognition processing such as ASICs (Application Specific Integrated Circuits). The processing may be executed by one of these various processors, or by a combination of two or more processors of the same or different types (for example, multiple FPGAs, and a combination of a CPU and an FPGA). More specifically, the hardware structure of these various processors is an electrical circuit that combines circuit elements such as semiconductor elements. [Explanation of symbols]

[0111] 1. Control System 30 User Programs 32 System Programs 100 Integrated Controllers 160 Program Function Unit 162 User Program Acquisition Method 164 User program execution means 166 System program storage means 168 System program execution means

Claims

1. A user program acquisition means for acquiring a user program that causes a robot to perform a specific task requested by the user, which is carried out by a series of actions, User program execution means for executing the user program, A system program storage means that stores a system program that defines a process for detecting the occurrence of a protective stop event in the robot, a process for stopping the execution of the user program when the protective stop event occurs, and a process for resuming the execution of the user program from a predetermined return position of the user program. System program execution means for executing the aforementioned system program, It is equipped with means for acquiring return position data to acquire return position data, The return position data includes a plurality of return positions in the user program that are associated with a plurality of candidate stop areas of the user program. A control system in which the process of resuming the execution of the user program is the process of resuming the execution of the user program according to the return position data.

2. The control system according to claim 1, wherein the process for resuming the execution of the user program is conditional on the resumption requirements being met.

3. The control system according to claim 2, wherein the restart requirement includes at least one of the following: no malfunction was detected as a result of self-diagnosis, and the deviation between the robot's position and orientation after protective shutdown and the planned position and orientation corresponding to said position and orientation is within a reference value.

4. The control system according to any one of claims 1 to 3, wherein the system program further defines a process to make available to the user program the restart data used in the execution of the user program after restart.

5. The control system according to claim 4, wherein the restart data includes a stop area which is an area where execution in the user program has stopped.

6. User program acquisition means for acquiring a user program that causes a robot to perform a specific task requested by a user, which is carried out by a series of actions. User program execution means for executing the user program, A system program storage means that stores a system program that defines a process for detecting the occurrence of a protective stop event in the robot, a process for stopping the execution of the user program when the protective stop event occurs, and a process for resuming the execution of the user program from a predetermined return position of the user program. System program execution means for executing the aforementioned system program, and A program for causing one or more computers to function as means for acquiring return position data, The return position data includes a plurality of return positions in the user program that are associated with a plurality of candidate stop areas of the user program. The process for resuming the execution of the user program is a program that resumes the execution of the user program according to the return position data.

Images