Robot system, manufacturing method, and program

Abstract

A robot system (1) is provided with: a robot drive device (100) that drives a robot (10); and a computing device (200) that performs network communication with the robot drive device (100) and that is capable of executing an application (211) necessary for controlling the robot (10) in the robot drive device (100), the computing device (200) having a robot service (213) that performs network communication with the robot drive device (100) when any one of a plurality of computing-side APIs (212), which are APIs that can be called by the application (211), is called. The processor executes a process corresponding to the called computing-side API (212), and relays communication between the application (211) and the robot drive device (100) in accordance with the content of the executed process.

Description

Technical Field

[0001] This disclosure relates to robot systems, manufacturing methods, and procedures. Background Technology

[0002] Patent Document 1 discloses a motion control device that is equipped with both a non-real-time operating system (OS) and a real-time operating system (OS) to perform motion control on the controlled device. The motion control device has shared memory that can be referenced and written to from both the functional units on the non-real-time OS side and the functional units on the real-time OS side.

[0003] Existing technical documents

[0004] Patent documents

[0005] Patent Document 1: Japanese Patent Application Publication No. 2019-220135 Summary of the Invention

[0006] The problem that the invention aims to solve

[0007] According to this disclosure, a system that effectively expands the functionality of a robot can be provided.

[0008] Methods for solving problems

[0009] One aspect of this disclosure relates to a robot system comprising: a robot drive that drives a robot; and a computing unit that communicates with the robot drive via a network and is capable of executing applications in the robot drive required to control the robot. The computing unit has a robot service that, when any one of a plurality of computing-side APIs that can be invoked by the application is invoked, performs processing corresponding to the invoked computing-side API and relays communication between the application and the robot drive based on the content of the executed processing.

[0010] Another aspect of this disclosure relates to a manufacturing method for manufacturing a system for controlling a robot, comprising: generating server-side stub code based on an IDL to execute in accordance with the called computational API when any one of a plurality of computational APIs is called via RPC; executing processing corresponding to the called computational API to generate a robot service that relays communication between the application and the robot drive device according to the executed processing content, as a service program containing the stub code; and storing the service program in the computing device in such a way that the application, which is executed by the computing device that communicates with the robot drive device via a network, calls the computational API to execute the service program.

[0011] Another aspect of this disclosure relates to a program that enables a computing device to form multiple computing-side APIs and robot services, the computing device communicating with a robot drive device that drives the robot via a network, and is capable of executing applications required to control the robot in the robot drive device. The multiple computing-side APIs are APIs that can be called by the applications. When any of the multiple computing-side APIs is called, the robot service performs processing corresponding to the called computing-side API and relays communication between the application and the robot drive device based on the content of the executed processing.

[0012] Invention Effects

[0013] This disclosure provides a system for effectively extending the functionality of a robot. Attached Figure Description

[0014] Figure 1 It is a diagram that schematically represents the structure of a robot system.

[0015] Figure 2 This is a block diagram illustrating the functional structures of the computing device and the robot drive device, respectively.

[0016] Figure 3 This is a block diagram illustrating the hardware structure of the computing device and the robot drive device.

[0017] Figure 4 This is a flowchart illustrating the request processing steps in a computing device.

[0018] Figure 5 This is a flowchart illustrating the processing steps involving communication with the robot's drive unit.

[0019] Figure 6 This is a flowchart illustrating a non-periodic communication process.

[0020] Figure 7 This is a flowchart illustrating the request processing steps in a robot drive system.

[0021] Figure 8 This is a flowchart illustrating the periodic communication steps in a robot drive system.

[0022] Figure 9 This is a flowchart illustrating the periodic communication steps in a computing device.

[0023] Figure 10 This is a flowchart illustrating the installation steps of the service program.

[0024] Figure 11 This is a flowchart illustrating the application installation steps. Detailed Implementation

[0025] Hereinafter, the embodiments will be described in detail with reference to the accompanying drawings. In the description, the same reference numerals are used to label the same elements or elements having the same function, and repeated descriptions are omitted.

[0026] [Robot System]

[0027] Figure 1 The robot system 1 shown is a system that enables robot 10 to perform various tasks. Examples of tasks performed by robot 10 include workpiece handling, workpiece processing, and workpiece assembly in an industrial production line. For example, robot system 1 includes robot 10 and control system 20. Robot 10 is, for example, a vertical articulated robot, having a base 11, an articulated arm 12, and an end effector 13. The base 11 is provided on the ground, wall, or ceiling surface of the robot 10's working area. The base 11 can also be provided on a mobile body such as an automated guided vehicle. The articulated arm 12 is connected to the base 11. The articulated arm 12 has multiple links 15 connected sequentially from the base 11 at multiple joints 14. The end effector 13 is connected to the end of the articulated arm 12 and acts on the workpiece to perform the aforementioned tasks. Examples of end effectors 13 include a hand that holds the workpiece, a suction part that adsorbs the workpiece, a tool for processing the workpiece, and a tool for assembling the workpiece (e.g., a fastening tool, a welding tool, etc.). The multi-joint arm 12 changes the angles of its multiple joints 14 via actuators such as electric actuators, thereby changing the position and orientation of the end effector 13. The structure of the robot 10 is an example and can be modified. For example, the robot 10 could also be a SCARA-type robot.

[0028] Control system 20 is a system for controlling robot 10. For example, control system 20 includes robot drive unit 100 and computing unit 200. Robot drive unit 100 drives robot 10. For example, robot drive unit 100 drives multiple joints 14 of multi-joint arm 12 and end effector 13. For example, robot drive unit 100 repeatedly performs a control cycle with a fixed drive cycle, which includes: obtaining feedback information representing the state of robot 10 (e.g., the angles of the multiple joints 14); and driving robot 10 in a manner that reduces the difference between the target state of robot 10 and the state of robot 10 based on the feedback information. Driving robot 10 includes, for example, supplying drive power to multiple actuators that respectively drive the multiple joints 14. Driving robot 10 includes maintaining robot 10 in a certain posture by supplying drive power to the multiple actuators.

[0029] The computing device 200 communicates with the robot drive device 100 via a network. The computing device 200 is capable of executing applications required by the robot drive device 100 to control the robot 10. Network communication is digital communication performed by identifying the other party through addressing methods such as IP addresses or MAC addresses. Network communication is performed using layered protocols such as the TCP / IP model or the OSI model. For example, the TCP / IP model has a network interface layer, an internet layer, a transport layer, and an application layer.

[0030] The application required to control robot 10 is one that generates the information needed to perform the target control. This application, for example, is executed during the period when robot drive device 100 drives robot 10. The period during which robot drive device 100 drives robot 10 refers to what is known as servo activation, which includes the period during which robot 10 maintains a certain posture by supplying drive power to multiple actuators.

[0031] For example, an application is a program that performs processing not included in the program executed by the robot drive device 100 (hereinafter referred to as the "robot program"). Examples of applications include vision applications, force applications, and path generation applications, as shown below. A vision application is an application that performs image processing on images captured by a camera installed on the robot 10 or cameras installed around the robot 10 to extract information needed to control the robot. Examples of information needed to control the robot include the position of the workpiece and the position of peripheral devices of the robot 10. The information extracted through image processing is used to generate motion paths for the robot 10. Motion paths are information that determines the position and posture of the end effector 13. Image processing may also include matrix operations suitable for execution by a GPU (Graphics Processing Unit). A force application is an application that generates actions that cause the robot 10 to perform based on forces detected by force sensors. A path generation application is an application that generates motion paths for the robot 10 to perform tasks by simulating (e.g., interference checks) a 3D model of the robot 10 and surrounding objects based on the task to be performed by the robot 10. Simulations such as interference checks can also include matrix operations suitable for execution by a GPU (Graphics Processing Unit).

[0032] In the illustrated example, the control system 20 includes a robot drive unit 100 housed in a housing 21 of the robot system 1, a computing unit 200, and a network switch 300, as well as a programming teach pendant 400 usable in a location separate from the housing 21. The robot drive unit 100 can also be modularized via a sub-housing 22, etc., so that it can move in and out relative to the housing 21. Similarly, the computing unit 200 can also be modularized via a sub-housing 23, etc., so that it can move in and out relative to the housing 21. The programming teach pendant 400 is a device operated by an operator to teach the robot drive unit 100 the actions to be performed by the robot 10. The programming teach pendant 400 can be composed of hardware dedicated to action teaching, or it can be composed of a general-purpose computer such as a tablet computer and a teaching application. The network switch 300 is connected to the robot drive unit 100, the computing unit 200, and the programming teach pendant 400 respectively via LAN cables, etc., transmitting network communication data between the robot drive unit 100, the computing unit 200, and the programming teach pendant 400. For example, network switch 300 transmits data based on MAC addresses at the network interface layer of the TCP / IP model. In addition to being connected via network switch 300, robot drive unit 100 and computing unit 200 can also be directly connected to each other. For example, robot drive unit 100 and computing unit 200 can also be directly connected to each other via a LAN cable different from the LAN cable connecting robot drive unit 100 and network switch 300, and the LAN cable connecting computing unit 200 and network switch 300.

[0033] According to the control system 20, the resources required to control the robot can be extended from the robot drive unit 100 to the computing unit 200. Therefore, it is possible to easily build various applications required to control the robot, overcoming the resource constraints of the robot drive unit 100. However, in building applications in the computing unit 200, not only is it necessary to encode the functions to be installed, but also to encode special codes for communication between the robot drive unit 100 and the computing unit 200 to match the real-time performance of the robot drive unit 100. In contrast, the computing unit 200 is configured such that, when any one of a plurality of computing-side APIs that can be called by the application is invoked, it executes processing corresponding to the invoked computing-side API and relays communication between the application and the robot drive unit 100 based on the content of the executed processing. Thus, since the communication between the application and the robot drive unit 100 is encapsulated, applications can be built without considering communication with the robot drive unit 100. Therefore, the burden of building applications can be significantly reduced.

[0034] For example, such as Figure 2As shown, the computing device 200 has the aforementioned application 211 and multiple computing-side APIs 212. The computing device 200 may also have multiple applications 211. Furthermore, the computing device 200 has a robot service 213 as a functional component (hereinafter referred to as a "functional block"). The multiple computing-side APIs 212 are APIs (Application Programming Interfaces) that can be called by the application 211. When any of the multiple applications 211 is called, the robot service 213 performs processing corresponding to the called computing-side API. For example, the robot service 213 performs processing corresponding to the called computing-side API during the period when the robot drive device 100 drives the robot 10. The computing device 200 may also have multiple applications 211 that are different from each other, and the multiple computing-side APIs 212 may be called separately by the multiple applications 211.

[0035] Multiple processes with different content correspond to multiple applications 211 respectively. These multiple processes include processes that include communication with the communication control unit 111 and processes that do not include communication with the communication control unit 111. Examples of processes that do not include communication with the communication control unit 111 are listed below.

[0036] Example 1) Notify application 211 of the information that robot service 213 has been maintained.

[0037] Example 2) The process of notifying application 211 of information obtained by robot service 213 from other application 211. The communication process may also include the process of periodic communication with communication control unit 111 and the process of one-off communication with communication control unit 111.

[0038] Examples of processes that require periodic communication are as follows.

[0039] Example 1-1) The above feedback information, drive power information, etc., are notified to the processing of application 211 for each control cycle.

[0040] Example 1-2) The robot drive unit 100 notifies the application 211 of the status of the process being executed according to the request from the application 211 on a per-control-cycle basis.

[0041] (Examples 1-3) The target pose of robot 10 based on the motion path generated by application 211 is sent to the robot drive unit 100 for processing in each control cycle.

[0042] The following examples illustrate how processing requires one-way communication.

[0043] Example 2-1) Obtaining structural information of robot 10 and notifying application 211 for processing.

[0044] Example 2-2) Write the set process from application 211 to robot drive device 100.

[0045] Example 2-3) The process of requesting servo activation from application 211 to robot drive device 100.

[0046] Example 2-4) Application 211 requests a dataset of a single action from robot drive device 100. Requesting a dataset of a single action is, for example, requesting an action command to move robot 10 to a target pose.

[0047] When communication is used as a process for the content corresponding to application 211, which is invoked by application 211, robot service 213 relays the communication between application 211 and robot drive device 100. Robot service 213 can also periodically communicate with robot drive device 100 when the content being processed requires periodic communication, and non-periodicly communicate with robot drive device 100 when the content being processed requires unidirectional communication. Hereinafter, periodic data communication will be referred to as "periodic communication," and non-periodic data communication will be referred to as "non-periodic communication." Since robot service 213 distinguishes between periodic and non-periodic communication, application 211 can be constructed without considering the distinction between periodic and non-periodic communication.

[0048] Periodic communication can be fixed-cycle communication that must meet a fixed-cycle communication standard (e.g., EtherCAT (registered trademark)), but it does not necessarily have to be a strictly fixed-cycle communication that meets the standard. For example, periodic communication can also be communication that is performed at approximately a fixed cycle based on the system timer of at least one of the robot drive unit 100 and the computing unit 200. Furthermore, periodic communication only needs to be performed during the cycle in which data is to be sent, and can be omitted during the cycle in which no data is to be sent. In periodic communication, the communication control unit 111 can also repeatedly send the first cycle data to the robot service unit 213. The robot service unit 213 can also repeatedly send the second cycle data to the communication control unit 111.

[0049] The robot drive unit 100 may also have multiple controller-side APIs 112. Additionally, the robot drive unit 100 may have a communication control unit 111 and a processing unit 114 as functional blocks. The communication control unit 111 controls communication with the computing unit 200. The multiple controller-side APIs 112 are APIs (Application Programming Interfaces) that can be called by the communication control unit 111. When any of the multiple controller-side APIs 112 is called, the processing unit 114 performs pre-prepared processing corresponding to the called controller-side API 112.

[0050] Multiple processes with different content correspond to multiple controller-side API112s. Examples of multiple processes are listed below.

[0051] (Example 3-1) Processing to move robot 10 to the target pose.

[0052] (Example 3-2) Processing of reading feedback information, drive power information, etc.

[0053] (Example 3-3) Processing of reading setting information (such as setting information of control parameters) from robot drive device 100.

[0054] (Example 3-4) Processing of reading the contents of the memory of the robot drive unit 100 (e.g., memory used for input / output with external devices).

[0055] When the processing corresponding to the invoked computational API 212 includes processing in the robot drive unit 100, the robot service 213 can also generate communication data requesting processing in the robot drive unit 100 and send it to the robot drive unit 100. The communication control unit 111 can also invoke the controller-side API 112 corresponding to the communication data upon receiving the communication data, causing the processing unit 114 to execute processing in the robot drive unit 100. Since the invocation of the computational API 212 is translated into an invocation of the controller-side API 112 as needed, it is possible to invoke the computational API 212, which has fewer constraints on the robot drive unit 100, instead of invoking the controller-side API 112 constrained by the robot drive unit 100, to execute processing in the robot drive unit 100. Therefore, the burden on application builders can be significantly reduced. That is, the computational API 212 provides good usability for vendors building applications on the computational device 200 side, and the controller-side API 112 can be a specification that brings out the performance of the robot drive unit 100 corresponding to the constraints of the robot drive unit 100. Therefore, it is possible to balance the improvement of the performance of the robot drive device 100 and the ease of use of the computing device 200.

[0056] The communication data is data requesting any one of the multiple processes corresponding to the multiple controller-side APIs 112. The communication data can also specify any one of the multiple controller-side APIs 112. However, at least some of the computation-side APIs 212 may be the same as the controller-side APIs 112. In this case, the robot service 213 may directly send the communication data representing the call to the computation-side API 212 to the robot drive unit 100, and the communication control unit 111 will directly execute the received communication data as a call to the controller-side API 112.

[0057] The communication data can be data requesting the execution of any one of multiple processes and sending the processing result to the robot service 213. In this case, the communication control unit 111 can also send the result of the processing executed by the processing unit 114 in accordance with the invoked controller-side API 112 to the computing unit 200. The processing result from the robot drive unit 100 side can be returned to the computing unit 200, and the application can use the processing result.

[0058] A request to execute any one of the multiple processes and send the result to robot service 213 can be a single request or a periodic request. A single request is a request to execute any one of the multiple processes once and send the result to robot service 213. A periodic request is a request to repeatedly execute any one of the multiple processes and send the result to the computing side API 212 each time it is executed.

[0059] The robot service 213 can also send communication data to the robot drive device 100 via the aforementioned non-periodic communication. When the communication data contains a single request, the communication control unit 111 sends the processing result of the processing unit 114 to the computing device 200. For example, in non-periodic communication sending communication data, the communication control unit 111 sends the processing result to the computing device 200 in the response to the communication data. When the communication data contains a periodic request, the communication control unit 111 repeatedly sends the processing result of the processing unit 114 to the computing device 200. For example, the communication control unit 111 issues a response ID for periodic requests, and in non-periodic communication sending communication data, sends the response ID to the computing device 200 in the response to the communication data. Then, each time the processing unit 114 performs processing, the communication control unit 111 assigns the issued response ID to the processing result and sends the processing result with the assigned response ID to the robot service 213, including it in the first periodic data. Each time the robot service 213 receives the first periodic data, it extracts the processing result with the assigned response ID from the first periodic data. Robot service 213 returns the processing result to the request source (the application that makes the periodic request corresponding to the response ID) based on the response ID.

[0060] The processing unit 114 can also perform processing corresponding to the called controller-side API 112 when any of the multiple controller-side APIs 112 is called by a controller application executed within the robot drive device 100, and return the processing result to the controller application. Processing that can be called by the controller-side API 112 can be used jointly in both the controller application and the application of the computing device.

[0061] For example, the robot drive unit 100 may also have a controller application 113, and multiple controller-side APIs 112 can be called by the controller application 113. The robot drive unit 100 may also have multiple controller applications 113, and the multiple controller-side APIs 112 can be called separately by multiple controller applications 113. The controller application 113 is a program that executes processing not included in the robot program described above. When the robot drive unit 100 has surplus resources, the functionality of the robot drive unit 100 can also be expanded through the controller application 113. Therefore, as shown in the following usage examples 1-4, various selections can be made depending on what the robot 10 performs.

[0062] Example 1) Make robot 10 move only through robot program.

[0063] (Usage Example 2) Within the resources of the robot drive unit 100, the robot 10 is moved by extending the functionality of the controller application 113.

[0064] (Usage Example 3) Extend the resources to the computing device 200 and enable the robot 10 to move by applying the extended function 211.

[0065] (Usage Example 4) The robot 10 is made to move by combining the existing controller application 113 with the application 211 newly built in the computing device 200 to extend its functionality.

[0066] Alternatively, multiple computational APIs 212 may each have a predetermined priority. When the robot service 213 sends data to the robot drive device 100 in response to the invoked computational API 212, it will prioritize sending data with higher priority from the invoked computational API 212 to the robot drive device 100. This allows for reliable execution of high-priority processing while multiple applications 211 utilize the robot service.

[0067] In addition to network communication with the communication control unit 111, robot service 213 can also communicate with application 211 via the network. For example, computing device 200 may contain one or more virtualized containers, and application 211 may be stored in any container within one or more containers. One or more containers may contain application container 201 capable of communicating with robot service 213 via the network, and application 211 may also be stored in application container 201. When computing device 200 has multiple applications 211, the multiple applications 211 may also contain two or more applications 211 stored in different application containers 201. Alternatively, one or more containers may also contain service container 202 capable of communicating with application container 201 via the network, and robot service 213 may be stored in service container 202.

[0068] A container is a virtual execution environment that bundles together the libraries, configuration files, and other necessary components for an application's actions, enabling the application to run independently of other containers or host systems (such as operating systems). By utilizing one or more containers, each application 211 can be executed in a virtual, independent execution environment, unconstrained by other applications 211. Within this independent execution environment, the robot service 213 can also be processed by calling multiple computational APIs 212. Therefore, both execution environment independence and collaboration with the robot service 213 and other applications 211 can be achieved simultaneously.

[0069] Alternatively, multiple computational APIs 212 can be invoked by application 211 via RPC (Remote Procedure Call). When any of the multiple computational APIs 212 is invoked via RPC, robot service 213 performs the corresponding processing for the invoked computational API 212.

[0070] RPC (Remote Procedure Call) is a protocol used to invoke programs on different computers over a network, enabling the execution of remote functions or procedures as if they were executed locally. RPC is language-independent, allowing communication between programs written in different programming languages. RPC abstracts away the details of communication, allowing application builders to invoke remote procedures without considering network complexity. With RPC, remote functions can be treated like local functions. For example, while using Web APIs requires accessing a URL and writing HTTP request code, with RPC, remote functions can be invoked directly like function calls.

[0071] The system, which allows application 211 to call multiple computation-side APIs 212 via RPC, can easily and cost-effectively handle various programming languages, significantly reducing the burden on application builders.

[0072] The robot service 213 can also independently perform communication with the application 211 and with the communication control unit 111 at regular intervals. Hereinafter, communication with the application 211 will be referred to as "first communication," and communication with the communication control unit 111 will be referred to as "second communication." For example, the robot service 213 has a queue 218, which stores requests received from one or more applications 211 (requests generated by calling any of the multiple computational APIs 212) via the first communication. The robot service 213 sequentially retrieves the requests stored in the queue 218 and secures memory 214 for the response corresponding to the retrieved request. After securing memory 214, if the processing corresponding to the retrieved request includes communication with the communication control unit 111, the robot service 213 sends communication data containing the request to the communication control unit 111 via the second communication and saves the response received from the communication control unit 111 (a response to a single request or a response ID for a periodic request) to memory 214. Robot service 213 reads the response from memory 214 at intervals independent of the second communication. Robot service 213 then returns the read response to the application that made the request, corresponding to memory 214, via the first communication.

[0073] Figure 3 This is a diagram illustrating the hardware structure of the robot drive unit 100 and the computing unit 200. (See diagram for example.) Figure 3As shown, the robot drive unit 100 has circuitry 190, and the computing unit 200 has circuitry 290. Circuitry 190 includes a first CPU 191, memory 192, storage 193, communication port 194, and driver circuitry 195. Storage 193 performs periodic and aperiodic communication with the computing unit 200, storing programs for controlling the robot 10. The programs include, for example, a real-time operating system, the aforementioned robot program, and programs for configuring the robot drive unit 100 into the aforementioned plurality of controller-side APIs 112 and function blocks. Storage 193 may include, for example, one or more non-volatile storage media. Non-volatile storage media may include one or more storage devices. Examples of one or more storage devices include hard disk drives, solid-state drives, flash memory, etc. Non-volatile storage media may also include removable storage media such as optical discs.

[0074] Memory 192 temporarily stores programs loaded from memory 193. Memory 192 contains one or more volatile storage media. The volatile storage media contains one or more memory devices. As an example of one or more memory devices, random access memory can be cited. The first CPU 191 executes the program loaded into memory 192, causing the robot drive device 100 to constitute the functional blocks described above. The first CPU 191 can also temporarily store the calculation results in memory 192. The first CPU 191 is a CPU (Central Processing Unit) and contains one or more computing devices. One or more computing devices can also be one or more cores.

[0075] Communication port 194, in response to a request from the first CPU 191, establishes network communication with the computing device 200. Driver circuit 195, in response to a request from the first CPU 191, supplies drive power to the aforementioned plurality of actuators.

[0076] Circuit 290 includes a second CPU 291, memory 292, storage 293, GPU 294, communication port 295, and communication port 296. Memory 293 stores programs containing applications required to control robot 10. For example, memory 293 includes a non-real-time OS and programs for enabling robot drive unit 100 to function as the aforementioned plurality of computational APIs 212 and function blocks.

[0077] Memory 292 temporarily stores programs loaded from memory 293. Memory 292 contains one or more volatile storage media. The volatile storage media contains one or more memory devices. As an example of one or more memory devices, random access memory can be mentioned. The second CPU 291 executes the program loaded into memory 292, and, as needed, works with GPU 294 to make the computing device 200 constitute the functional blocks described above. The second CPU 291 and GPU 294 can also temporarily store the computation results in memory 292. The second CPU 291 contains one or more computing devices. One or more computing devices can be, for example, one or more central processing units (CPUs), or one or more cores contained in a CPU. GPU 294, for example, contains one or more graphics processing units (GPUs) dedicated to parallel processing.

[0078] In response to a request from the second CPU 291, communication port 295 establishes network communication with communication port 194. Thus, the second CPU 291 is able to communicate with the first CPU 191.

[0079] The second CPU 291 can also cause the GPU 294 to perform matrix operations related to the generation of the robot 10's path (e.g., the motion path described above) while the first CPU 191 is controlling the robot 10. The first CPU 191 can also cause the robot 10 to perform actions along the path based on the calculation results of the second CPU 291 and the GPU 294. During the period when the first CPU 191 is controlling the robot, the matrix operations performed by the GPU 294 can be used for the generation of the robot 10's path, thereby easily expanding the functionality of the robot 10.

[0080] As with the aforementioned matrix operations, the GPU294 can also perform image processing-related matrix operations for generating image paths based on the surrounding environment of the robot 10. This allows for the control of the robot 10 while simultaneously reflecting the image processing results onto the path.

[0081] As for the aforementioned matrix operations, the GPU294 can also perform matrix operations based on models of robot 10 and its surrounding objects to check for interference between robot 10 and the surrounding objects. This allows the robot 10 to be controlled while simultaneously reflecting the interference results between it and the surrounding objects onto the path.

[0082] [Control Steps]

[0083] As an example of a control method, the control steps executed by the control system 20 are illustrated. These control steps include: driving the robot via the robot drive device 100; executing an application 211 required by the robot drive device 100 to control the robot 10 via the computing device 200; performing processing corresponding to the called computing API 212 if any of the multiple computing APIs 212 is called by the application 211; and relaying communication between the application 211 and the robot drive device 100 based on the content of the executed processing.

[0084] The control steps are illustrated below with reference to the flowchart. The illustrated control steps include the request processing steps in the computing device 200, the non-periodic communication steps, the request processing steps in the robot drive device 100, the periodic communication steps in the robot drive device 100, the periodic communication steps in the computing device 200, and the processing steps of the controller-side API 112.

[0085] (Request processing steps in the computing device)

[0086] This step occurs during the period when the robot drive unit 100 drives the robot 10, and the computing unit 200 processes the request from the application 211. For example... Figure 4 As shown, the computing device 200 executes steps S01, S02, and S03. In step S01, the robot service 213 waits to be invoked from among multiple computing-side APIs 212. In step S02, the robot service 213 selects the processing corresponding to the invoked computing-side API 212. In step S03, the robot service 213 executes the selected processing. After executing step S03, the computing device 200 returns the processing to step S01. The computing device 200 repeats the above processing.

[0087] As described above, the processes performed by the robot service 213 in step S03 include processes that include communication with the communication control unit 111 and processes that do not include communication with the communication control unit 111. Figure 5 This is a flowchart illustrating the steps involved in the processing of communication with the communication control unit 111.

[0088] like Figure 5 As shown, the computing device 200 executes steps S11 and S12. In step S11, the robot service 213 secures memory 214 for response. In step S12, requests to be sent to the communication control unit 111 are written to queue 218. Requests written to queue 218 are sent to the communication control unit 111 in the aperiodic communication step described later. When a response to a request is received, it is written to memory 214.

[0089] Next, the computing device 200 executes steps S13 and S14. In step S13, the robot service 213 waits for a response to be written to memory 214. In step S14, the robot service 213 reads the response written to memory 214.

[0090] Next, the computing device 200 executes step S15. In step S15, the robot service 213 confirms whether the response read from memory 214 is a response ID based on periodic communication. In step S15, if it is determined that the read response is a response ID, the computing device 200 executes step S16. In step S16, the robot service 213 establishes a corresponding storage for the response ID and the request being processed.

[0091] In step S15, if it is determined that the read response is not a response ID, the computing device 200 executes step S17. In step S17, the robot service 213 returns a response to the application 211, which is the source of the request being processed. The processing including communication with the communication control unit 111 is thus completed.

[0092] (Aperiodic communication steps)

[0093] This step is a communication step performed by the computing device 200 in response to the request written to queue 218 in step S12 above. For example... Figure 6 As shown, the computing device 200 first executes steps S21 and S22. In step S21, the robot service 213 reads a request from the queue 218. In step S22, the robot service 213 sends communication data containing the read request to the communication control unit 111.

[0094] Next, the computing device 200 executes steps S23 and S24. In step S23, the robot service 213 waits for a response from the communication control unit 111. In step S24, the robot service 213 writes the response from the communication control unit 111 into memory 214. Afterward, the computing device 200 returns the processing to step S21. The computing device 200 repeats the above processing.

[0095] (Request handling steps in robot drive unit)

[0096] This step is the step by which the robot drive unit 100 processes the request sent by the robot service 213 in step S22 described above. For example... Figure 7 As shown, the robot drive unit 100 first executes steps S31 and S32. In step S31, the communication control unit 111 waits to receive a request. In step S32, the communication control unit 111 confirms whether the request is a one-off request.

[0097] In step S32, if the request is determined to be unidirectional, the robot drive unit 100 executes steps S33 and S34. In step S33, the communication control unit 111 calls the controller-side API 112 corresponding to the received communication data, causing the processing unit 114 to perform processing. In step S34, the communication control unit 111 sends the result of the processing performed by the processing unit 114 to the computing unit 200 as a response to the request.

[0098] In step S32, if the request is determined to be periodic, the robot drive unit 100 executes steps S35 and S36. In step S35, the communication control unit 111 issues a response ID for the periodic request and sends it to the robot service 213. In step S36, the communication control unit 111 appends a response to the request (e.g., the processing result of the processing unit 114) to the object included in the first periodic data. The response appended to the object is included in the first periodic data and sent via periodic communication in the periodic communication step described later. After executing steps S34 and S36, the robot drive unit 100 returns the processing to step S31. The robot drive unit 100 repeats the above processing.

[0099] (Periodic communication steps in robot drive systems)

[0100] This step is a periodic communication step performed by the robot drive unit 100. For example... Figure 8 As shown, the robot drive unit 100 executes steps S41, S42, S43, S44, and S45. In step S41, the processing unit 114 performs the aforementioned control loop and other processing. In step S42, the communication control unit 111 calls the controller-side API 112 corresponding to the processing for obtaining the object contained in the first cycle data, causing the processing unit 114 to perform processing. In step S43, the communication control unit 111 assigns an issued response ID to the processing result of the processing unit 114 and appends the processing result with the assigned response ID to the first cycle data. In step S44, the communication control unit 111 waits for the transmission timing of the first cycle data. The transmission timing of the first cycle data is, for example, the timing of the aforementioned control cycle elapsed. In step S45, the communication control unit 111 sends the first cycle data to the robot service 213. Afterward, the robot drive unit 100 returns the processing to step S41. The robot drive unit 100 repeats the above processing.

[0101] (Periodic communication steps in the computing device)

[0102] This step is a periodic communication step performed by the computing device 200. For example... Figure 9As shown, the computing device 200 executes steps S51 and S52. In step S51, the robot service 213 waits to receive the first cycle data. In step S52, in response to the receipt of the first cycle data, the robot service 213 sends the second cycle data to the communication control unit 111. Afterwards, the computing device 200 returns the processing to step S51. The computing device 200 repeats the above processing.

[0103] [Manufacturing Steps]

[0104] As an example of a manufacturing method, the steps for manufacturing robot system 1 are illustrated. This step involves manufacturing robot system 1 by installing programs in computing device 200, provided the hardware of robot 10 and control system 20 has been prepared. The manufacturing steps are illustrated below with reference to a flowchart. The illustrated manufacturing steps include the installation steps of service programs and application programs.

[0105] (Installation steps for the service program)

[0106] This step is performed after the hardware of robot 10 and control system 20 has been prepared. For example... Figure 10 As shown, the service program installation steps include steps S61, S62, S63, and S64. In step S61, IDL is generated.

[0107] IDL stands for Interface Definition Language, a language that defines interfaces for communication between different programming languages. In RPC, IDL is used to automatically generate libraries and stub code for various languages, thereby enabling seamless communication between programs written in different languages.

[0108] In step S62, if any one of the multiple computational APIs 212 is called via RPC, server-side stub code is generated based on IDL to execute in accordance with the called computational API 212. In step S63, processing corresponding to the called computational API 212 is executed, and a robot service 213 is generated to relay communication between application 211 and robot drive device 100 according to the executed processing content, as a service program containing stub code. In step S64, the service program is stored in computing device 200 in such a way that application 211, which is executed by computing device 200 that communicates with robot drive device 100 via network, executes the service program by calling computational API 212 via RPC. Storing the service program in computing device 200 may also include storing the service program in any of the one or more containers described above (e.g., the service container 202 described above).

[0109] (Application installation steps)

[0110] This step is performed when a service program is installed in the computing device 200. For example... Figure 11 As shown, the application installation steps include steps S71, S72, and S73. In step S71, based on the IDL generated in step S61, stub code for the client side used to call the service program is generated, corresponding to the specified programming language. The client-side stub code is, for example, a library that can be imported into the application's code. In step S72, using (e.g., importing) the client-side stub code (library), the application 211 is generated. In step S73, the application is stored in the computing device 200. Storing the application in the computing device 200 may also include storing the application in any of the one or more containers described above (e.g., the application container 201 described above).

[0111] 〔Summarize〕

[0112] (1) A robot system 1 comprising: a robot drive device 100 that drives a robot 10; and a computing device 200 that communicates with the robot drive device 100 via a network and is capable of executing an application 211 in the robot drive device 100 required to control the robot 10. The computing device 200 has a robot service 213 that, when any one of a plurality of computing side APIs 212 that can be called by the application 211 is invoked, performs processing corresponding to the invoked computing side API 212 and relays communication between the application 211 and the robot drive device 100 according to the content of the executed processing.

[0113] According to the robot system 1, the robot service 213 encapsulates the communication between the application 211 and the robot drive device 100, thus enabling the application 211 to be built without considering communication with the robot drive device 100. Therefore, the burden of building the application 211 can be significantly reduced.

[0114] (2) According to the robot system 1 described in (1), the robot drive device 100 includes: a communication control unit 111 that controls communication with the computing device 200; and a processing unit 114 that, when any one of a plurality of controller-side APIs 112 that can be called by the communication control unit 111 is called, performs pre-prepared processing in accordance with the called controller-side API 112; when the processing corresponding to the called computing-side API 212 includes processing in the robot drive device 100, the robot service 213 generates communication data requesting processing in the robot drive device 100 and sends it to the robot drive device 100; when the communication control unit 111 receives the communication data, it causes the processing unit 114 to execute the processing in the robot drive device 100 by calling the controller-side API 112 corresponding to the communication data.

[0115] According to the robot system 1, calls to the computation-side API 212 are translated into calls to the controller-side API 112 as needed. Therefore, instead of calling the controller-side API 112, which is constrained by the robot drive device 100, the computation-side API 212, which has fewer constraints on the robot drive device 100, can be called to perform processing within the robot drive device 100. This significantly reduces the burden on the application builder 211. Specifically, the computation-side API 212 provides good usability for suppliers building the application 211 on the computation-side device 200, while the controller-side API 112 can be a specification that maximizes the performance of the robot drive device 100 corresponding to its constraints. Therefore, it is possible to balance improvements in the performance of the robot drive device 100 with ease of use of the computation-side device 200. However, it is also possible that at least a portion of the computation-side API 212 is the same as the controller-side API 112. In this case, the robot service 213 can directly send the call to the computation-side API 212 to the robot drive unit 100, and the communication control unit 111 can also directly execute the received call to the computation-side API 212.

[0116] (3) According to the robot system 1 described in (2), the communication control unit 111 sends the result of the processing performed by the processing unit 114 in accordance with the called controller-side API 112 to the computing device 200.

[0117] According to the robot system 1, the processing results from the robot drive device 100 can be returned to the computing device 200, and the application 211 can use the processing results.

[0118] (4) According to the robot system 1 described in (2) or (3), wherein when any controller-side API among the plurality of controller-side APIs 112 is called by the controller application 113 executed within the robot drive device 100, the processing unit 114 performs processing corresponding to the called controller-side API 112 and returns the processing result to the controller application 113.

[0119] According to the robot system 1, processing that can be called by the controller-side API 112 can be used in both the controller application 113 and the application 211 of the computing device 200.

[0120] (5) The robot system 1 according to any one of (2) to (4), wherein the plurality of computational side APIs 212 have predetermined priorities respectively, and when the robot service 213 sends data to the robot drive device 100 in accordance with the called computational side API 212, the data with higher priority of the called computational side API 212 is sent to the robot drive device 100 first.

[0121] According to the robot system 1, high-priority processing can be reliably performed while multiple applications 211 utilize robot services 213.

[0122] (6) The robot system 1 according to any one of (1) to (5), wherein the plurality of computational side APIs 212 can be called by the application 211 via RPC, and the robot service 213 performs the processing corresponding to the called computational side API 212 when any of the plurality of computational side APIs 212 is called via RPC.

[0123] According to the robot system 1, it can easily and cost-effectively handle various programming languages, greatly reducing the burden on the builders of application 211.

[0124] (7) The robot system 1 according to (6), wherein the computing device 200 is manufactured by means of: generating server-side stub code based on IDL to execute in accordance with the called computing-side API 212 when any computing-side API 212 among the plurality of computing-side APIs 212 is called by RPC; generating robot service 213 to perform processing in accordance with the called computing-side API 212 as a service program containing stub code; and saving the service program in a manner that allows the application 211 to call any computing-side API 212 among the plurality of computing-side APIs 212 by RPC to execute the service program.

[0125] According to the robot system 1, it is easier to handle various programming languages.

[0126] (8) The robot system 1 according to any one of (1) to (7), wherein the computing device 200 includes one or more virtualized containers, and the application 211 is stored in any container in one or more containers.

[0127] By utilizing multiple containers, each application 211 can be executed in a virtual, independent execution environment, unconstrained by other applications 211. Within this independent execution environment, the robot service 213 can also be processed by calling multiple computation-side APIs 212. Therefore, both execution environment independence and collaboration with the robot service 213 and other applications 211 can be achieved simultaneously.

[0128] (9) The robot system 1 according to any one of (1) to (8), wherein the robot service 213 periodically communicates data with the robot drive device 100 when the content being processed requires periodic communication, and non-periodically communicates data with the robot drive device 100 when the content being processed requires unidirectional communication.

[0129] Since periodic and aperiodic communications are distinguished by robot service 213, application 211 can be built without having to consider the distinction between periodic and aperiodic communications.

[0130] (10) A manufacturing method for manufacturing a system for controlling a robot 10, wherein the method comprises: generating server-side stub code based on IDL to execute in accordance with the called computational API 212 when any of the computational APIs 212 among a plurality of computational APIs 212 is called via RPC; executing processing corresponding to the called computational API 212 to generate a robot service 213 that relays communication between the application 211 and the robot drive device 100 according to the content of the executed processing, as a service program containing stub code; and storing the service program in the computing device 200 in such a way that the application 211, which is executed by the computing device 200 that communicates with the robot drive device 100 via network, calls the computational API 212 via RPC to execute the service program.

[0131] According to this manufacturing method, it is possible to manufacture systems that can easily and cost-effectively support various programming languages, greatly reducing the burden on application builders.

[0132] (11) The manufacturing method according to (10), wherein the computing device 200 includes one or more virtualized containers, and the service program is stored in any container in the computing device 200 that stores the service program in one or more containers.

[0133] (12) The manufacturing method according to (10), wherein the manufacturing method further comprises: generating client-side stub code for calling a service program based on IDL and corresponding to a specified programming language; generating an application 211 program as application 211 using the client-side stub code; and storing the application 211 program in the computing device 200.

[0134] According to this manufacturing method, it is possible to easily manufacture a system with added functionality through the application of 211.

[0135] (13) The manufacturing method according to (12), wherein the computing device 200 includes a plurality of virtualized containers, the plurality of containers including a service container and an application 211 container that are able to communicate with each other, storing the service program in the computing device 200 includes storing the service program in the service container, and storing the application 211 in the computing device 200 includes storing the application 211 program in the application 211 container.

[0136] (14) A program that enables a computing device 200 to form a plurality of computing-side APIs 212 and a robot service 213, the computing device 200 communicating with a robot drive device 100 that drives a robot 10 via a network, and is capable of executing an application 211 in the robot drive device 100 required to control the robot 10, wherein the plurality of computing-side APIs 212 are APIs that can be called by the application 211, and the robot service 213, when any computing-side API among the plurality of computing-side APIs 212 is called, performs processing corresponding to the called computing-side API 212, and relays communication between the application 211 and the robot drive device 100 according to the content of the executed processing.

[0137] The implementation methods have been described above, but this disclosure is not limited to the above-described implementation methods, and various modifications can be made without departing from its spirit.

[0138] Label Explanation

[0139] 1 Robot System; 10 Robot; 100 Robot Drive Unit; 200 Computing Unit; 211 Application; 212 Computing-Side API; 213 Robot Service; 111 Communication Control Unit; 112 Controller-Side API; 114 Processing Unit; 113 Controller Application.

Claims

1. A robot system comprising: Robot drive unit, which drives the robot; and The computing device communicates with the robot drive unit via a network and is capable of executing applications within the robot drive unit required to control the robot. The computing device has a robot service that, when any one of a plurality of computing-side APIs that can be invoked by the application is called, performs processing corresponding to the called computing-side API and relays communication between the application and the robot drive device based on the content of the executed processing.

2. The robot system according to claim 1, wherein, The robot drive device includes: A communication control unit that controls communication with the computing device; The processing unit, when any one of a plurality of controller-side APIs that can be invoked by the communication control unit is called, performs pre-prepared processing in accordance with the called controller-side API. If the processing corresponding to the invoked computational API includes processing from the robot driver, the robot service generates communication data requesting the processing from the robot driver and sends it to the robot driver. When the communication control unit receives the communication data, it calls the controller-side API corresponding to the communication data to enable the processing unit to execute the processing in the robot drive device.

3. The robot system according to claim 2, wherein, The communication control unit sends the result of the processing performed by the processing unit in accordance with the invoked controller-side API to the computing device.

4. The robot system according to claim 2, wherein, When any of the multiple controller-side APIs is called by a controller application executed within the robot drive device, the processing unit performs the processing corresponding to the called controller-side API and returns the processing result to the controller application.

5. The robot system according to claim 2, wherein, The multiple computation-side APIs each have a predetermined priority. When the robot service sends data to the robot driving device in accordance with the invoked computational side API, it prioritizes sending data with higher priority from the invoked computational side API to the robot driving device.

6. The robot system according to claim 1, wherein, The various computing-side APIs can be invoked by the application via RPC. When any of the multiple computational APIs is invoked via RPC, the robot service performs the corresponding processing for the invoked computational API.

7. The robot system according to claim 6, wherein, The computing device is manufactured by a method comprising: When any of the multiple computation-side APIs is called via RPC, server-side stub code is generated based on IDL to execute in accordance with the called computation-side API. Generate the robot service that performs the processing corresponding to the invoked computation-side API as a service program containing the stub code; and The service program is stored in a manner that allows the application to execute the service program by calling any of the plurality of computation-side APIs via RPC.

8. The robot system according to any one of claims 1 to 6, wherein, The computing device includes one or more virtualized containers. The application is stored in any of the more than one containers.

9. The robot system according to any one of claims 1 to 6, wherein, When the content being processed requires periodic communication, the robot service periodically communicates data with the robot drive device. When the content being processed requires one-off communication, the robot service performs non-periodic data communication with the robot drive device.

10. A manufacturing method for manufacturing a system for controlling a robot, wherein, The manufacturing method includes: When any of the multiple computation-side APIs is called via RPC, server-side stub code is generated based on IDL to execute in accordance with the called computation-side API. Execute the processing corresponding to the invoked computation-side API, and generate a robot service that relays communication between the application and the robot drive device based on the executed processing content, as a service program containing the stub code; and The service program is stored in the computing device in such a way that the application, which is capable of being executed by a computing device that communicates with the robot drive device via a network, executes the service program by calling the computing-side API through RPC.

11. The manufacturing method according to claim 10, wherein, The computing device includes one or more virtualized containers. Storing the service program in the computing device includes storing the service program in any of the one or more containers.

12. The manufacturing method according to claim 10, wherein, The manufacturing method further includes: Based on IDL, stub code is generated on the client side for calling the service program, corresponding to the specified programming language; The application is generated using the stub code on the client side; and The application is stored in the computing device.

13. The manufacturing method according to claim 12, wherein, The computing device includes multiple virtualized containers. The multiple containers include service containers and application containers that can communicate with each other. Storing the service program in the computing device includes storing the service program in the service container. Saving the application in the computing device includes saving the application in the application container.

14. A program that enables a computing device to configure multiple computing-side APIs and robot services, the computing device communicating via a network with a robot actuator that drives a robot, and is capable of executing applications in the robot actuator required to control the robot. The aforementioned multiple computation-side APIs are APIs that can be called by the application. When any of the multiple computational APIs is invoked, the robot service performs the corresponding processing for the invoked computational API and relays the communication between the application and the robot drive device based on the content of the executed processing.

Images