Robot system, manufacturing method, and program

Abstract

To provide a system effective for function expansion of a robot.SOLUTION: The robot system 1 includes the robot driving device 100 that drives the robot 10, and the arithmetic device 200 that performs network communication with the robot driving device 100 and is capable of executing the application 211 necessary for controlling the robot 10 in the robot driving device 100, and the arithmetic device 200 includes the robot service 213 that, when any of a plurality of arithmetic API212, which are APIs that can be called by the application 211, is called, executes processing according to the called arithmetic API212 and relays communication between the application 211 and the robot driving device 100 according to the content of the processing to be executed.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] The present disclosure relates to a robot system, a manufacturing method, and a program. [Background technology]

[0002] Patent Document 1 discloses a motion control device that has a non-real-time OS and a real-time OS installed and that controls the motion of a device to be controlled. The motion control device has a shared memory that can be accessed and written to by both the functional units on the non-real-time OS side and the functional units on the real-time OS side. [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Japanese Patent Application Publication No. 2019-220135 Summary of the Invention [Problem to be solved by the invention]

[0004] According to the present disclosure, a system that is effective for expanding the functionality of a robot can be provided. [Means for solving the problem]

[0005] A robot system according to one aspect of the present disclosure includes a robot driving device that drives a robot, and a computing device that communicates with the robot driving device over a network and is capable of executing an application required to control the robot in the robot driving device, and when one of a plurality of computing-side APIs that are APIs that can be called by an application is called, the computing device executes processing according to the called computing-side API and has a robot service that relays communication between the application and the robot driving device depending on the content of the processing to be executed.

[0006] A manufacturing method according to another aspect of the present disclosure is a method for manufacturing a system for controlling a robot, the method including: generating, based on an IDL, server-side stub code that is executed in accordance with the called calculation-side API when any of a plurality of calculation-side APIs is called by RPC; generating a robot service as a service program including the stub code that executes processing in accordance with the called calculation-side API and relays communication between an application and a robot driving device in accordance with the content of the processing to be executed; and storing the service program in the computing device so that the calculation-side API can be called by RPC from an application executed by the computing device that communicates over a network with the robot driving device and the service program can be executed.

[0007] A program according to yet another aspect of the present disclosure configures a computing device that communicates over a network with a robot driving device that drives a robot and is capable of executing an application necessary for controlling the robot in the robot driving device, and the computing device is configured to: configure a plurality of computing-side APIs that are APIs that can be called by the application; and configure a robot service that, when one of the plurality of computing-side APIs is called, executes processing according to the called computing-side API and relays communication between the application and the robot driving device according to the content of the processing to be executed. [Effects of the Invention]

[0008] The present disclosure provides a system that is effective for expanding the functionality of a robot. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram schematically illustrating a configuration of a robot system. [Figure 2] FIG. 2 is a block diagram illustrating the functional configuration of a computing device and a robot driving device. [Figure 3] FIG. 2 is a block diagram illustrating an example of a hardware configuration of a computing device and a robot driving device. [Figure 4]10 is a flowchart illustrating a request handling procedure in a computing device. [Figure 5] 10 is a flowchart illustrating a processing procedure including communication with a robot driving device. [Figure 6] 1 is a flowchart illustrating an example aperiodic communication procedure. [Figure 7] 10 is a flowchart illustrating a request handling procedure in a robot driving device. [Figure 8] 10 is a flowchart illustrating a periodic communication procedure in a robot driving device. [Figure 9] 10 is a flowchart illustrating a periodic communication procedure in a computing device. [Figure 10] 10 is a flowchart illustrating an example of a procedure for implementing a service program. [Figure 11] 10 is a flowchart illustrating an example of an implementation procedure for an application. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, the embodiments will be described in detail with reference to the drawings. In the description, the same elements or elements having the same functions are denoted by the same reference numerals, and redundant description will be omitted.

[0011] [Robot System] The robot system 1 shown in FIG. 1 is a system that causes a robot 10 to perform various tasks. Examples of tasks that the robot 10 is caused to perform include transporting workpieces in an industrial production line, machining workpieces, and assembling workpieces. For example, the robot system 1 includes a robot 10 and a control system 20. The robot 10 is, for example, a vertical articulated robot, and includes a base 11, an articulated arm 12, and an end effector 13. The base 11 is installed on the floor, wall, or ceiling of a work area where the robot 10 is to work. The base 11 may also be installed 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 in sequence from the base 11 at multiple joints 14. The end effector 13 is connected to the tip of the articulated arm 12 and acts on the workpiece for the above-mentioned tasks. Examples of the end effector 13 include a hand that grips a workpiece, a suction portion that sucks the workpiece, a tool that processes the workpiece, and a tool that assembles the workpiece (e.g., a fastening tool, a welding tool, etc.). The articulated arm 12 changes the position and posture of the end effector 13 by changing the angle of each of the multiple joints 14 using an actuator, such as an electric actuator. The configuration of the robot 10 is an example and can be changed. For example, the robot 10 may be a SCARA type robot.

[0012] The control system 20 is a system that controls the robot 10. For example, the control system 20 includes a robot driving device 100 and a computing device 200. The robot driving device 100 drives the robot 10. For example, the robot driving device 100 drives the multiple joints 14 of the articulated arm 12 and the end effector 13. For example, the robot driving device 100 repeats a control cycle at a constant driving period, the control cycle including obtaining feedback information representing the state of the robot 10 (for example, the angles of each of the multiple joints 14) and driving the robot 10 so as to reduce the difference between a target state of the robot 10 and the state of the robot 10 based on the feedback information. Driving the robot 10 includes, for example, supplying driving power to multiple actuators that respectively drive the multiple joints 14. Driving the robot 10 includes maintaining a constant posture of the robot 10 by supplying driving power to the multiple actuators.

[0013] The arithmetic device 200 performs network communication with the robot driving device 100. The arithmetic device 200 can execute applications required for controlling the robot 10 in the robot driving device 100. Network communication is digital communication in which the other party is identified by addressing using an IP address, a MAC address, or the like. 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.

[0014] An application required for controlling the robot 10 is an application that generates information required to execute the desired control. The application is executed, for example, while the robot driving device 100 is driving the robot 10. The period during which the robot driving device 100 is driving the robot 10 refers to the period during which the servo is on, and includes the period during which the robot 10 is maintained in a certain posture by supplying driving power to multiple actuators.

[0015] For example, an application is a program that executes processing not included in the program executed by the robot driving device 100 (hereinafter referred to as the "robot program"). Examples of applications include a vision application, a haptic application, and a path generation application, which are shown below. The vision application is an application that performs image processing on images captured by a camera installed on the robot 10 or a camera installed in the vicinity of the robot 10 to extract information necessary for controlling the robot. Examples of information necessary for controlling the robot include the position of a workpiece and the positions of peripheral devices of the robot 10. The information extracted by image processing is used to generate a motion path for the robot 10. The motion path is information that determines the transition of the position and posture of the end effector 13. The image processing may include matrix operations suitable for execution by a GPU (Graphics Processing Unit). The haptic application is an application that generates a motion to be executed by the robot 10 in accordance with a force detected by a force sensor. The path generation application is an application that generates a motion path for the robot 10 to execute a task by performing a simulation (e.g., interference check) based on a task to be executed by the robot 10 and a three-dimensional model of the robot 10 and surrounding objects. Simulations such as collision checks may include matrix operations suitable for execution by a GPU (Graphics Processing Unit).

[0016] In the illustrated example, the control system 20 includes a robot driving device 100, a computing device 200, and a network switch 300 housed in a housing 21 of the robot system 1, and a programming pendant 400 that can be used at a location remote from the housing 21. The robot driving device 100 may be unitized by a sub-housing 22 or the like so that it can be inserted and removed together with the housing 21. Similarly, the computing device 200 may be unitized by a sub-housing 23 or the like so that it can be inserted and removed together with the housing 21. The programming pendant 400 is a device operated by an operator to teach the robot driving device 100 the operations to be performed by the robot 10. The programming pendant 400 may be configured with hardware specialized for operation teaching, or may be configured with a general-purpose computer such as a tablet computer and a teaching application. The network switch 300 is connected to the robot driving device 100, the computing device 200, and the programming pendant 400 via LAN cables or the like, and transfers network communication data between the robot driving device 100, the computing device 200, and the programming pendant 400. For example, the network switch 300 transfers data based on MAC addresses at the network interface layer of the TCP / IP model. In addition to being connected via the network switch 300, the robot driving device 100 and the computing device 200 may also be directly connected to each other. For example, the robot driving device 100 and the computing device 200 may also be directly connected to each other by a LAN cable that is separate from the LAN cable that connects the robot driving device 100 and the network switch 300 and the LAN cable that connects the computing device 200 and the network switch 300.

[0017] According to the control system 20, resources required for robot control can be expanded from the robot driving device 100 to the arithmetic device 200. This makes it possible to easily build various applications required for robot control, exceeding the resource constraints of the robot driving device 100. However, building an application on the arithmetic device 200 requires not only coding the functions to be implemented but also specialized coding for communication between the robot driving device 100 and the arithmetic device 200 in accordance with the real-time nature of the robot driving device 100. In contrast, when one of multiple arithmetic-side APIs that can be called by an application is called, the arithmetic device 200 executes processing according to the called arithmetic-side API and relays communication between the application and the robot driving device 100 according to the content of the processing to be executed. This encapsulates communication between the application and the robot driving device 100, allowing applications to be built without having to be aware of communication with the robot driving device 100. This significantly reduces the burden of building applications.

[0018] For example, as shown in FIG. 2 , the arithmetic device 200 has the above-mentioned application 211 and multiple calculation-side APIs 212. The arithmetic device 200 may have multiple applications 211. Furthermore, the arithmetic device 200 has a robot service 213 as a functional component (hereinafter referred to as a "functional block"). Each of the multiple calculation-side APIs 212 is an API (Application Programming Interface) that can be called from the application 211. When one of the multiple calculation-side APIs 212 is called, the robot service 213 executes processing according to the called calculation-side API. For example, the robot service 213 executes processing according to the called calculation-side API while the robot driving device 100 is driving the robot 10. The arithmetic device 200 may have multiple different applications 211, and the multiple calculation-side APIs 212 may be callable from each of the multiple applications 211.

[0019] A plurality of processes with mutually different contents correspond to the plurality of applications 211. The plurality of 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 include the following. Example 1) A process in which the robot service 213 notifies the application 211 of information that it already holds. Example 2) A process of notifying the application 211 of information acquired by the robot service 213 from another application 211. The process including communication may include a process that requires periodic communication with the communication control unit 111 and a process that requires one-off communication with the communication control unit 111.

[0020] Examples of processes that require periodic communication include: Example 1-1) A process of notifying the application 211 of the above-mentioned feedback information, driving power information, etc. for each control cycle. Example 1-2) Processing for notifying the application 211 of the status of processing being executed by the robot driving device 100 in response to a request from the application 211 for each control cycle. Example 1-3) A process of transmitting a target posture of the robot 10 based on the motion path generated by the application 211 to the robot driving device 100 for each control cycle.

[0021] Examples of processes that require one-off communication include the following: Example 2-1) A process of acquiring configuration information of the robot 10 and notifying the application 211. Example 2-2) Processing for writing settings from the application 211 to the robot driving device 100. Example 2-3) Processing for requesting servo-on from the application 211 to the robot driving device 100. Example 2-4) An example is a data set in which the application 211 requests a one-shot operation from the robot driving device 100. A data set requesting a one-shot operation is, for example, an operation command requesting that the robot 10 be moved to a target posture.

[0022] The robot service 213 relays communication between the application 211 and the robot driving device 100 when the content of the processing corresponding to the application 211 called by the application 211 is communication. The robot service 213 may periodically communicate data with the robot driving device 100 when the content of the processing requires periodic communication, and may non-periodically communicate data with the robot driving device 100 when the content of the processing requires one-off 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." The robot service 213 can distinguish between periodic communication and non-periodic communication, so the application 211 can be constructed without having to be aware of the distinction between periodic communication and non-periodic communication.

[0023] The periodic communication may be periodic communication that satisfies a periodic communication standard (e.g., EtherCAT (registered trademark)), but it does not necessarily have to be periodic communication that strictly satisfies the periodic communication standard. For example, the periodic communication may be communication that is performed at a roughly regular interval based on a system timer of at least one of the robot driving device 100 and the arithmetic device 200. Furthermore, it is sufficient that the periodic communication is performed at least in a period in which there is data to be transmitted, and may be omitted in periods in which there is no data to be transmitted. In periodic communication, the communication control unit 111 may repeatedly transmit first periodic data to the robot service 213. The robot service 213 may repeatedly transmit second periodic data to the communication control unit 111.

[0024] The robot driving device 100 may have multiple controller-side APIs 112. Furthermore, the robot driving device 100 may have, as functional blocks, a communication control unit 111 and a processing unit 114. The communication control unit 111 controls communication with the arithmetic device 200. The multiple controller-side APIs 112 are APIs (Application Programming Interfaces) that can be called by the communication control unit 111. When one of the multiple controller-side APIs 112 is called, the processing unit 114 executes a process that has been prepared in advance according to the called controller-side API 112.

[0025] A plurality of processes with mutually different contents correspond to the plurality of controller-side APIs 112. Examples of the plurality of processes include the following. (Example 3-1) Processing for moving the robot 10 to a target posture. (Example 3-2) Processing to read feedback information, drive power information, etc. (Example 3-3) Processing for reading setting information of the robot driving device 100 (for example, setting information of control parameters) and the like. (Example 3-4) Processing for reading the contents of the memory of the robot driving device 100 (for example, memory for input / output between external devices).

[0026] When processing corresponding to the called calculation-side API 212 includes processing in the robot driving device 100, the robot service 213 may generate communication data requesting processing in the robot driving device 100 and transmit the generated communication data to the robot driving device 100. Upon receiving the communication data, the communication control unit 111 may cause the processing unit 114 to execute processing in the robot driving device 100 by calling the controller-side API 112 corresponding to the communication data. Since the call of the calculation-side API 212 is translated into a call of the controller-side API 112 as necessary, instead of calling the controller-side API 112 that is subject to the constraints of the robot driving device 100, the calculation-side API 212 that is less subject to the constraints of the robot driving device 100 can be called to execute processing in the robot driving device 100. This significantly reduces the burden on application developers. In other words, the calculation-side API 212 can be made user-friendly for vendors who build applications for the calculation device 200, and the controller-side API 112 can be configured to maximize the performance of the robot driving device 100 in accordance with the constraints of the robot driving device 100. Therefore, it is possible to improve the performance of the robot driving device 100 and improve the ease of use of the computing device 200 at the same time.

[0027] The communication data is data that requests one of a plurality of processes corresponding to each of a plurality of controller-side APIs 112. The communication data may also be data that specifies one of the plurality of controller-side APIs 112. However, at least some of the calculation-side APIs 212 may be the same as the controller-side APIs 112. In this case, the robot service 213 may transmit the communication data representing the call of the calculation-side API 212 to the robot driving device 100 as is, and the communication control unit 111 may execute the received communication data as is as a call of the controller-side API 112.

[0028] The communication data may be data requesting that one of a plurality of processes be executed and that the processing result be transmitted to the robot service 213. In this case, the communication control unit 111 may transmit the processing result executed by the processing unit 114 in response to the called controller-side API 112 to the arithmetic device 200. The processing result on the robot driving device 100 side can be returned to the arithmetic device 200, and the processing result can be used by an application.

[0029] The communication data may be a one-off request or a periodic request to execute any one of a plurality of processes and transmit the processing result to the robot service 213. A one-off request is a request to execute any one of a plurality of processes once and transmit the processing result to the robot service 213. A periodic request is a request to repeatedly execute any one of a plurality of processes and transmit the processing result to the calculation-side API 212 each time the process is executed.

[0030] The robot service 213 may transmit communication data to the robot driving device 100 using the aperiodic communication described above. When the communication data includes a one-off request, the communication control unit 111 transmits the processing result by the processing unit 114 to the arithmetic device 200. For example, in aperiodic communication in which communication data is transmitted, the communication control unit 111 transmits the processing result to the arithmetic device 200, including the processing result in a response to the communication data. When the communication data includes a periodic request, the communication control unit 111 repeatedly transmits the processing result by the processing unit 114 to the arithmetic device 200. For example, the communication control unit 111 issues a response ID in response to the periodic request, and in aperiodic communication in which communication data is transmitted, includes the response ID in a response to the communication data and transmits it to the arithmetic device 200. Thereafter, each time processing is performed by the processing unit 114, the communication control unit 111 assigns the issued response ID to the processing result, and transmits the processing result with the assigned response ID included in first periodic data to the robot service 213. Each time the robot service 213 receives first periodic data, it extracts the processing result with the assigned response ID from the first periodic data. The robot service 213 returns the processing result to the application of the request source (the source of the periodic request corresponding to the response ID) based on the response ID.

[0031] When one of the multiple controller-side APIs 112 is called by a controller application executed in the robot driving device 100, the processing unit 114 may execute processing according to the called controller-side API 112 and return the processing result to the controller application. Processing that can be called by the controller-side API 112 can be used in common by the controller application and the application of the computing device.

[0032] For example, the robot driving device 100 may further include a controller application 113, and multiple controller-side APIs 112 may be callable from the controller application 113. The robot driving device 100 may include multiple controller applications 113, and multiple controller-side APIs 112 may be callable from each of the multiple controller applications 113. The controller application 113 is a program that executes processing that is not included in the robot program described above. If the robot driving device 100 has surplus resources, the controller application 113 can also expand the functions of the robot driving device 100. Therefore, as shown in the following use examples 1 to 4, various selections are possible depending on the content to be executed by the robot 10. Usage example 1) Operate the robot 10 using only the robot program. Usage example 2) The functions of the robot driving device 100 are expanded by the controller application 113 within the range of the resources of the robot driving device 100 to operate the robot 10. Usage example 3) The resources of the arithmetic device 200 are expanded, and the functions are expanded by the application 211 to operate the robot 10. Usage example 4) The existing controller application 113 is combined with a newly constructed application 211 in the arithmetic device 200 to expand the functionality and operate the robot 10.

[0033] Each of the multiple calculation-side APIs 212 has a predetermined priority, and when transmitting data to the robot driving device 100 in response to the called calculation-side API 212, the robot service 213 may preferentially transmit data of the called calculation-side API 212 with a higher priority to the robot driving device 100. It is possible to reliably execute high-priority processing while enabling the use of the robot service from multiple applications 211.

[0034] The robot service 213 may perform network communication with the application 211 in addition to network communication with the communication control unit 111. For example, the computing device 200 may include one or more virtualized containers, and the application 211 may be stored in one of the one or more containers. The one or more containers may include an application container 201 capable of network communication with the robot service 213, and the application 211 may be stored in the application container 201. When the computing device 200 has multiple applications 211, the multiple applications 211 may include two or more applications 211 stored in different application containers 201. The one or more containers may further include a service container 202 capable of network communication with the application container 201, and the robot service 213 may be stored in the service container 202.

[0035] A container is a virtual execution environment that collects libraries, configuration files, and the like required for application operation into a single package, enabling the application to be executed independently from other containers or a host system (e.g., an operating system). By using one or more containers, each application 211 can be executed in an execution environment that is virtually independent from other applications 211, without being restricted by the other applications 211. Even in an independent execution environment, processing by the robot service 213 can be executed by calling multiple calculation-side APIs 212. Therefore, it is possible to achieve both independence of the execution environment and cooperation with the robot service 213 and other applications 211.

[0036] Each of the multiple calculation-side APIs 212 may be callable by RPC from the application 211. When one of the multiple calculation-side APIs 212 is called by RPC, the robot service 213 executes processing according to the called calculation-side API 212.

[0037] RPC (Remote Procedure Call) is a protocol for calling programs on different computers over a network, allowing remote functions or procedures to be executed as if they were running locally. RPC is language-independent, allowing communication between programs written in different programming languages. RPC abstracts the details of communication, allowing application builders to call remote procedures without being aware of the complexities of the network. RPC allows remote functions to be treated like local functions. For example, using a Web API requires accessing a URL and coding an HTTP request, but RPC allows remote functions to be called simply like a function call.

[0038] A system in which each of a plurality of calculation-side APIs 212 can be called from the application 211 by RPC can easily support a variety of programming languages ​​at low cost, significantly reducing the burden on application developers.

[0039] The robot service 213 may execute communication with the application 211 and communication with the communication control unit 111 at timings independent of each other. 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, and stores requests (requests made by calling any of the multiple calculation-side APIs 212) received from one or more applications 211 through the first communication in the queue 218. The robot service 213 sequentially releases the requests stored in the queue 218 from the queue 218 and reserves memory 214 for responses corresponding to the released requests. After reserving the memory 214, if the processing corresponding to the released request includes communication with the communication control unit 111, the robot service 213 transmits communication data including the request to the communication control unit 111 through the second communication, and stores the response received from the communication control unit 111 (a response to a one-off request or a response ID to a periodic request) in the memory 214. The robot service 213 reads the response from the memory 214 at a timing independent of the second communication. The robot service 213 returns the read response to the requesting application corresponding to the memory 214 via the first communication.

[0040] FIG. 3 illustrates the hardware configuration of the robot driving device 100 and the computing device 200. As shown in FIG. 3, the robot driving device 100 includes a circuit 190, and the computing device 200 includes a circuit 290. The circuit 190 includes a first CPU 191, a memory 192, a storage 193, a communication port 194, and a driver circuit 195. The storage 193 executes periodic and aperiodic communication with the computing device 200 and stores programs for controlling the robot 10. The programs include, for example, a real-time OS, the robot program described above, and a program for configuring the multiple controller-side APIs 112 and function blocks described above in the robot driving device 100. The storage 193 includes, for example, one or more nonvolatile storage media. The nonvolatile storage medium includes one or more storage devices. Examples of the one or more storage devices include a hard disk drive, a solid-state drive, and a flash memory. The nonvolatile storage medium may also include a portable storage medium such as an optical disk.

[0041] The memory 192 temporarily stores the program loaded from the storage 193. The memory 192 includes one or more volatile storage media. The volatile storage media includes one or more memory devices. An example of the one or more memory devices is a random access memory. The first CPU 191 configures the above-mentioned functional blocks in the robot driving device 100 by executing the program loaded in the memory 192. The first CPU 191 may temporarily store the calculation results in the memory 192. The first CPU 191 is a CPU (Central Processing Unit) and includes one or more arithmetic devices. The one or more arithmetic devices may be one or more cores.

[0042] The communication port 194 performs network communication with the arithmetic device 200 in response to a request from the first CPU 191. The driver circuit 195 supplies drive power to the above-mentioned plurality of actuators in response to a request from the first CPU 191.

[0043] The circuit 290 has a second CPU 291, a memory 292, a storage 293, a GPU 294, and a communication port 295. The storage 293 stores programs including applications necessary for controlling the robot 10. For example, the programs stored in the storage 293 include a non-real-time OS and a program for configuring the above-mentioned multiple calculation-side APIs 212 and function blocks in the calculation device 200.

[0044] The memory 292 temporarily stores a program loaded from the storage 293. The memory 292 includes one or more volatile storage media. The volatile storage medium includes one or more memory devices. An example of the one or more memory devices is a random access memory. The second CPU 291 executes the program loaded in the memory 292, cooperating with the GPU 294 as necessary to configure the above-mentioned functional blocks in the arithmetic device 200. The second CPU 291 and the GPU 294 may temporarily store the results of the calculations in the memory 292. The second CPU 291 includes one or more arithmetic devices. The one or more arithmetic devices may be, for example, one or more central processing units, or one or more cores included in one central processing unit. The GPU 294 includes, for example, one or more graphics processing units specialized for parallel processing.

[0045] The communication port 295 performs network communication with the communication port 194 in response to a request from the second CPU 291. This enables the second CPU 291 to communicate with the first CPU 191.

[0046] The second CPU 291 may cause the GPU 294 to execute matrix operations related to the generation of a path (for example, the above-mentioned movement path) of the robot 10 while the first CPU 191 is controlling the robot 10. The first CPU 191 may cause the robot 10 to execute an operation along the path based on the results of the operations by the second CPU 291 and the GPU 294. By making the matrix operations by the GPU 294 available for generating a path for the robot 10 while the first CPU 191 is controlling the robot, the functionality of the robot 10 can be easily expanded.

[0047] As the matrix calculation, the GPU 294 may perform a matrix calculation related to image processing for generating a path based on an image of the surrounding environment of the robot 10. The robot 10 can be controlled while reflecting the image processing results in the path.

[0048] As the matrix calculation, the GPU 294 may perform a matrix calculation to check for interference between the robot 10 and a peripheral object based on a model of the robot 10 and the peripheral object of the robot 10. The robot 10 can be controlled while reflecting the result of interference between the robot 10 and the peripheral object in the path.

[0049] [Control procedure] As an example of a control method, a control procedure executed by the control system 20 is illustrated. This control procedure includes driving the robot by the robot driving device 100, executing, by the arithmetic device 200, an application 211 required for controlling the robot 10 in the robot driving device 100, and when one of a plurality of arithmetic-side APIs 212 is called by the application 211, executing processing according to the called arithmetic-side API 212, and relaying communication between the application 211 and the robot driving device 100 according to the content of the processing to be executed.

[0050] The control procedure will be exemplified below with reference to a flowchart. The exemplified control procedure includes a request handling procedure in the arithmetic device 200, a non-periodic communication procedure, a request handling procedure in the robot driving device 100, a periodic communication procedure in the robot driving device 100, a periodic communication procedure in the arithmetic device 200, and a processing procedure by the controller-side API 112.

[0051] (Request handling procedures in computing devices) In this procedure, the arithmetic device 200 handles requests from the application 211 while the robot driving device 100 is driving the robot 10. As shown in FIG. 4, the arithmetic device 200 executes steps S01, S02, and S03. In step S01, the robot service 213 waits for one of the multiple calculation-side APIs 212 to be called. In step S02, the robot service 213 selects a process according to the called calculation-side API 212. In step S03, the robot service 213 executes the selected process. After executing step S03, the arithmetic device 200 returns the process to step S01. The arithmetic device 200 repeats the above process.

[0052] As described above, the processing executed by the robot service 213 in step S03 includes processing that includes communication with the communication control unit 111 and processing that does not include communication with the communication control unit 111. Figure 5 is a flowchart illustrating the procedure of processing that includes communication with the communication control unit 111.

[0053] 5, the arithmetic device 200 executes steps S11 and S12. In step S11, the robot service 213 allocates memory 214 for responses. In step S12, the robot service 213 writes a request to be sent to the communication control unit 111 into a queue 218. The request written into the queue 218 is sent to the communication control unit 111 in a non-periodic communication procedure, which will be described later. When a response to the request is received, it is written into memory 214.

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

[0055] Next, the arithmetic device 200 executes step S15. In step S15, the robot service 213 checks whether the response read from the memory 214 is the response ID of a response by periodic communication. If it is determined in step S15 that the read response is the response ID, the arithmetic device 200 executes step S16. In step S16, the robot service 213 stores the response ID in association with the request being handled.

[0056] If it is determined in step S15 that the read response is not a response ID, the arithmetic device 200 executes step S17. In step S17, the robot service 213 returns a response to the application 211 that is the request source of the request being handled. This completes the process including communication with the communication control unit 111.

[0057] (Acyclic Communication Procedure) This procedure is a communication procedure that the arithmetic device 200 executes in response to the request written to the queue 218 in step S12 described above. As shown in Fig. 6, the arithmetic device 200 first executes steps S21 and S22. In step S21, the robot service 213 reads the request from the queue 218. In step S22, the robot service 213 transmits communication data including the read request to the communication control unit 111.

[0058] Next, the arithmetic 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 to the memory 214. Thereafter, the arithmetic device 200 returns the process to step S21. The arithmetic device 200 repeats the above processes.

[0059] (Request handling procedure in robot drive unit) This is a procedure by which the robot driving device 100 handles the request sent by the robot service 213 in step S22 described above. As shown in Fig. 7, the robot driving device 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 checks whether the request is a one-off request.

[0060] If it is determined in step S32 that the request is a one-off request, the robot driving device 100 executes steps S33 and S34. In step S33, the communication control unit 111 calls the controller-side API 112 according to the received communication data and causes the processing unit 114 to execute processing. In step S34, the communication control unit 111 transmits the result of the processing executed by the processing unit 114 to the arithmetic device 200 as a response to the request.

[0061] If it is determined in step S32 that the request is periodic, the robot driving unit 100 executes steps S35 and S36. In step S35, the communication control unit 111 issues a response ID for the periodic request and transmits it to the robot service 213. In step S36, the communication control unit 111 adds the response to the request (for example, the processing result by the processing unit 114) to the targets to be included in the first periodic data. The response added to the targets is included in the first periodic data and transmitted by periodic communication in the periodic communication procedure described below. After executing steps S34 and S36, the robot driving unit 100 returns the process to step S31. The robot driving unit 100 repeats the above processes.

[0062] (Cyclic communication procedure for robot drive units) This procedure is a periodic communication procedure executed by the robot driving device 100. As shown in FIG. 8, the robot driving device 100 executes steps S41, S42, S43, S44, and S45. In step S41, the processing unit 114 executes the above-described control cycle and other processes. In step S42, the communication control unit 111 calls the controller-side API 112 corresponding to the process for acquiring the target to be included in the first periodic data, causing the processing unit 114 to execute the process. In step S43, the communication control unit 111 assigns the issued response ID to the processing result by the processing unit 114 and adds the processing result with the assigned response ID to the first periodic data. In step S44, the communication control unit 111 waits for the timing to send the first periodic data. The timing to send the first periodic data is, for example, the timing when the above-described control period elapses. In step S45, the communication control unit 111 transmits the first periodic data to the robot service 213. After that, the robot driving device 100 returns the process to step S41. The robot driving device 100 repeats the above process.

[0063] (Periodic communication procedure in computing devices) This procedure is a periodic communication procedure executed by the arithmetic device 200. As shown in FIG. 9, the arithmetic device 200 executes steps S51 and S52. In step S51, the robot service 213 waits to receive first periodic data. In step S52, in response to receiving the first periodic data, the robot service 213 transmits second periodic data to the communication control unit 111. Thereafter, the arithmetic device 200 returns the process to step S51. The arithmetic device 200 repeats the above process.

[0064] [Manufacturing Procedure] As an example of a manufacturing method, a procedure for manufacturing the robot system 1 will be illustrated. This procedure is a procedure for manufacturing the robot system 1 by installing a program in the arithmetic device 200 when the hardware of the robot 10 and the control system 20 is already prepared. The manufacturing procedure will be illustrated below with reference to a flowchart. The illustrated manufacturing procedure includes a procedure for installing a service program and a procedure for installing an application program.

[0065] (Service program implementation procedure) This procedure is executed in a state where the hardware of the robot 10 and the control system 20 is prepared. As shown in Fig. 10, the procedure for implementing a service program includes steps S61, S62, S63, and S64. In step S61, an IDL is generated.

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

[0067] In step S62, when one of the multiple calculation-side APIs 212 is called by RPC, server-side stub code that is executed in accordance with the called calculation-side API 212 is generated based on the IDL. In step S63, a robot service 213 that executes processing in accordance with the called calculation-side API 212 and relays communication between the application 211 and the robot driving device 100 in accordance with the content of the processing to be executed is generated as a service program including the stub code. In step S64, the service program is stored in the calculation device 200 so that the application 211 executed by the calculation device 200 that communicates over a network with the robot driving device 100 can call the calculation-side API 212 by RPC and execute the service program. Storing the service program in the calculation device 200 may include storing the service program in one or more of the containers described above (for example, the above-mentioned service container 202).

[0068] (Application program implementation procedure) This procedure is performed with the service program installed in the computing device 200. As shown in FIG. 11, the application program installation procedure includes steps S71, S72, and S73. In step S71, client-side stub code for calling the service program is generated, corresponding to the specified programming language, based on the IDL generated in step S61. The client-side stub code is, for example, a library that can be imported when coding the application program. In step S72, the client-side stub code (library) is used (for example, imported) to generate an application program as the application 211. In step S73, the application program is stored in the computing device 200. Storing the application program in the computing device 200 may include storing the application program in one or more of the containers described above (for example, the application container 201 described above).

[0069] 〔summary〕 (1) A robot system 1 includes a robot driving device 100 that drives a robot 10, and a computing device 200 that communicates with the robot driving device 100 over a network and is capable of executing an application 211 required for controlling the robot 10 on the robot driving device 100, wherein the computing device 200, when one of a plurality of computing-side APIs 212 that are APIs that can be called by the application 211, executes processing according to the called computing-side API 212, and has a robot service 213 that relays communication between the application 211 and the robot driving device 100 according to the content of the processing to be executed. According to this robot system 1, the robot service 213 encapsulates the communication between the application 211 and the robot driving device 100, so the application 211 can be constructed without being aware of the communication with the robot driving device 100. This significantly reduces the burden of constructing the application 211.

[0070] (2) The robot driving device 100 has a communication control unit 111 that controls communication with the calculation device 200, and a processing unit 114 that, when one of a plurality of controller-side APIs 112 that are APIs that can be called by the communication control unit 111, executes pre-prepared processing in accordance with the called controller-side API 112. When the processing in accordance with the called calculation-side API 212 includes processing in the robot driving device 100, the robot service 213 generates communication data requesting processing in the robot driving device 100 and transmits it to the robot driving device 100. When the communication control unit 111 receives the communication data, it calls the controller-side API 112 in accordance with the communication data, causing the processing unit 114 to execute the processing in the robot driving device 100. This is the robot system 1 described in (1). According to this robot system 1, a call to the calculation-side API 212 is translated into a call to the controller-side API 112 as necessary. Therefore, instead of calling the controller-side API 112, which is subject to the constraints of the robot driving device 100, the calculation-side API 212, which is less subject to the constraints of the robot driving device 100, can be called to execute processing in the robot driving device 100. This significantly reduces the burden on the developer of the application 211. In other words, the calculation-side API 212 can be made easy to use for vendors who build applications 211 on the calculation device 200 side, and the controller-side API 112 can be designed to bring out the performance of the robot driving device 100 in accordance with the constraints of the robot driving device 100. This makes it possible to achieve both improved performance, etc. of the robot driving device 100 and ease of use of the calculation device 200. However, at least some of the calculation-side APIs 212 may be the same as the controller-side APIs 112. In this case, the robot service 213 may send the call of the calculation-side APIs 212 to the robot driving device 100 as is, and the communication control unit 111 may execute the received call of the calculation-side APIs 212 as is.

[0071] (3) The robot system 1 according to (2), wherein the communication control unit 111 transmits the result of the processing executed by the processing unit 114 in response to the called controller-side API 112 to the arithmetic device 200. According to this robot system 1, the processing results on the robot driving device 100 side can be returned to the arithmetic device 200, and the application 211 can use the processing results.

[0072] (4) In the robot system 1 described in (2) or (3), when one of a plurality of controller-side APIs 112 is called by the controller application 113 executed within the robot driving device 100, the processing unit 114 executes processing according to the called controller-side API 112 and returns the processing result to the controller application 113. According to this robot system 1, the processes that can be called by the controller-side API 112 can be used in common by the controller application 113 and the application 211 of the arithmetic device 200.

[0073] (5) The robot system 1 described in any one of (2) to (4), wherein each of the plurality of calculation-side APIs 212 has a predetermined priority, and when transmitting data to the robot driving device 100 in accordance with the called calculation-side API 212, the robot service 213 transmits data of a higher priority of the called calculation-side API 212 to the robot driving device 100 preferentially. According to this robot system 1, it is possible to enable a plurality of applications 211 to use the robot service 213, while ensuring that high-priority processing is executed.

[0074] (6) The robot system 1 described in any one of (1) to (5), wherein each of the plurality of calculation-side APIs 212 can be called from the application 211 by RPC, and when one of the plurality of calculation-side APIs 212 is called by RPC, the robot service 213 executes processing according to the called calculation-side API 212. This robot system 1 can easily support a variety of programming languages ​​at low cost, significantly reducing the burden on the application 211 developer.

[0075] (7) The robot system 1 described in (6) is a device manufactured by a method including: generating, based on an IDL, server-side stub code that is executed in accordance with the called calculation-side API 212 when any of the multiple calculation-side APIs 212 is called by RPC; generating a robot service 213 that executes processing in accordance with the called calculation-side API 212 as a service program including the stub code; and storing the service program so that the application 211 can call any of the multiple calculation-side APIs 212 by RPC and execute the service program. This robot system 1 can more easily support various programming languages.

[0076] (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 one of the one or more containers. By using multiple containers, each application 211 can be executed in an execution environment that is virtually independent from the other applications 211, without being restricted by the other applications 211. Even in an independent execution environment, processing by the robot service 213 can be executed by calling multiple calculation-side APIs 212. Therefore, it is possible to achieve both independence of the execution environment and cooperation with the robot service 213 and other applications 211.

[0077] (9) The robot system 1 described in any one of (1) to (8), wherein the robot service 213 periodically communicates data with the robot driving device 100 when the content of the processing requires periodic communication, and non-periodically communicates data with the robot driving device 100 when the content of the processing requires one-off communication. Since the robot service 213 can distinguish between periodic communication and aperiodic communication, the application 211 can be constructed without being aware of the distinction between periodic communication and aperiodic communication.

[0078] (10) A method for manufacturing a system for controlling a robot 10, the manufacturing method including: generating, based on an IDL, a server-side stub code that is executed in accordance with the called calculation-side API 212 when any of a plurality of calculation-side APIs 212 is called by RPC; generating, as a service program including the stub code, a robot service 213 that executes processing in accordance with the called calculation-side API 212 and relays communication between an application 211 and a robot driving device 100 in accordance with the content of the processing to be executed; and storing the service program in the calculation device 200 so that the application 211 executed by the calculation device 200 that communicates over a network with the robot driving device 100 can call the calculation-side API 212 by RPC and execute the service program. According to this manufacturing method, it is possible to manufacture a system that can easily support a variety of programming languages ​​at low cost and that significantly reduces the burden on the application 211 developer.

[0079] (11) The manufacturing method described in (10), wherein the computing device 200 includes one or more virtualized containers, and storing the service program in the computing device 200 includes storing the service program in any of the one or more containers.

[0080] (12) The manufacturing method described in (10), further including: generating client-side stub code corresponding to a specified programming language based on the IDL and for calling the service program; generating an application 211 program as the application 211 using the client-side stub code; and storing the application 211 program in the computing device 200. According to this manufacturing method, a system to which functions are added by the application 211 can be easily manufactured.

[0081] (13) A 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 can communicate with each other, storing a 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.

[0082] (14) A program that configures a computing device 200 that communicates over a network with a robot driving device 100 that drives the robot 10 and can execute an application 211 required for controlling the robot 10 in the robot driving device 100, with the following components: a plurality of computing-side APIs 212 that are APIs that can be called by the application 211; and a robot service 213 that, when one of the plurality of computing-side APIs 212 is called, executes processing according to the called computing-side API 212 and relays communication between the application 211 and the robot driving device 100 according to the content of the processing to be executed.

[0083] Although the embodiments have been described above, the present disclosure is not necessarily limited to the above-described embodiments, and various modifications are possible without departing from the spirit of the present disclosure. [Explanation of symbols]

[0084] 1...robot system, 10...robot, 100...robot driving device, 200...computing device, 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 driving device that drives the robot; a computing device that communicates with the robot driving device through a network and is capable of executing an application required for controlling the robot in the robot driving device; Equipped with The computing device A robot service that, when one of a plurality of APIs on the calculation side that are APIs that can be called by the application is called, executes processing according to the called API on the calculation side, and relays communication between the application and the robot driving device according to the content of the processing to be executed. having Robot system.

2. The robot driving device a communication control unit that controls communication with the arithmetic unit; a processing unit that, when one of a plurality of controller-side APIs that are APIs that can be called by the communication control unit is called, executes a process that has been prepared in advance in accordance with the called controller-side API; and When the processing according to the called calculation-side API includes processing in the robot driving device, the robot service generates communication data requesting processing in the robot driving device and transmits the communication data to the robot driving device; When the communication control unit receives the communication data, the communication control unit calls a controller-side API corresponding to the communication data, thereby causing the processing unit to execute processing in the robot driving device. The robot system according to claim 1 .

3. The communication control unit transmits a result of the processing executed by the processing unit in response to the called controller-side API to the arithmetic device. The robot system according to claim 2 .

4. When one of the plurality of controller-side APIs is called by a controller application executed in the robot driving device, the processing unit executes processing according to the called controller-side API and returns a processing result to the controller application. The robot system according to claim 2 .

5. each of the plurality of calculation-side APIs has a predetermined priority; When transmitting data to the robot driving device in response to the called calculation-side API, the robot service preferentially transmits data having a higher priority to the robot driving device. The robot system according to claim 2 .

6. each of the plurality of calculation-side APIs can be called from the application by RPC; When any one of the plurality of calculation-side APIs is called by an RPC, the robot service executes a process corresponding to the called calculation-side API. The robot system according to claim 1 .

7. The computing device generating, based on an IDL, a server-side stub code that is executed in response to the called API when any of the plurality of APIs is called by an RPC; generating the robot service that executes processing according to the called calculation-side API as a service program including the stub code; storing the service program so that the application can call any one of the plurality of computing-side APIs by RPC to execute the service program; 10. The robotic system of claim 6, wherein the robotic system is an apparatus manufactured by a method comprising:

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

9. The robot service If the content of the process requires periodic communication, periodically communicate data with the robot driving device; When the content of the process requires one-off communication, data is communicated non-periodically with the robot driving device. The robot system according to any one of claims 1 to 6.

10. 1. A method of manufacturing a system for controlling a robot, comprising: When any one of a plurality of APIs on the calculation side is called by RPC, a stub code on the server side is generated based on an IDL to be executed in response to the called API on the calculation side; generating a robot service as a service program including the stub code, which executes processing according to the called calculation-side API and relays communication between an application and a robot driving device according to the content of the processing to be executed; storing the service program in a computing device that communicates with the robot driving device over a network so that the application executed by the computing device can call the computing-side API by RPC to execute the service program; A manufacturing method comprising:

11. the computing device includes one or more virtualized containers; storing the service program on the computing device includes storing the service program in one of the one or more containers. The method of claim 10.

12. generating a client-side stub code corresponding to the specified programming language based on the IDL, for invoking the service program; generating an application program as the application using the client-side stub code; storing the application program on the computing device; Further comprising: The method of claim 10.

13. the computing device includes a plurality of virtualized containers; the plurality of containers include a service container and an application container that can communicate with each other; storing the service program in the computing device includes storing the service program in the service container; storing the application on the computing device includes storing the application program in the application container. The method of claim 12.

14. a computing device that communicates via a network with a robot driving device that drives a robot and that can execute an application required for controlling the robot in the robot driving device; a plurality of APIs on the computing side that are APIs that can be called by the application; a robot service that, when any one of the plurality of calculation-side APIs is called, executes a process corresponding to the called calculation-side API and relays communication between the application and the robot driving device according to the content of the process to be executed; A program that configures the following.

Images