Robot application management device, system, method and program

Abstract

The present invention executes a robot application by executing multiple virtual containers in a cooperative manner. Therefore, a robot application management device (100), at least one robot device (300) and at least one computer device (400) are connected via a local area network (600). A device group including these devices is managed as a cluster for executing the robot application, and each virtual container is configured in any device in the device group constituting the cluster and started.

Description

Technical Field

[0001] The present invention relates to a technology for implementing a robot system using a distributed computing system, and more particularly to a mechanism for managing robot applications in the system. Background Art

[0002] In recent years, the use of robot-oriented middleware for a distributed computing system called ROS (Robot Operating System) has increased in the development of service robot software. The ecosystem and rich library group provided by ROS have improved the development efficiency of service robots (for example, Non-Patent Document 1).

[0003] On the other hand, distributed computing systems are one of the ways of thinking that have been used in the field of computer science. Usually, a mechanism is provided for bundling multiple computers that constitute a system and controlling them as a cluster. They include mechanisms for automating most of the operation / monitoring, making development more efficient, and reducing quality control costs. This mechanism is achieved by combining various technologies based on various network technologies and virtualization technologies (for example, non-patent document 2).

[0004] Prior art literature

[0005] Non-patent literature

[0006] Non-patent document 1: "ROS Programming" by Qian Fei, Morihoku Publishing Co., Ltd. (published on March 30, 2016)

[0007] Non-patent document 2: "Docker Practical Guide" by Masazumi Koga, Impress Co., Ltd. (published on December 21, 2015) Summary of the invention

[0008] FP201894JP Second telephone notification after OA1 Modification

[0009] Problems to be solved by the invention

[0010] Usually, a robot system is composed of multiple computers and implemented through a distributed computing system, but ROS does not define the management and control of multiple computers. Therefore, it is possible that ROS randomly uses a large number of machines, processes and other resources, or that ROS applications are restricted by the network environment (time synchronization, address assignment, name resolution, etc.).

[0011] Currently, in order to avoid such a situation, the developer or manager of the robot system must manually log in to each computer that constitutes the robot system and execute and maintain the processes for the robot separately. In addition, how to handle applications with physical constraints on execution, such as robot systems, in distributed computing systems varies from developer to manager, making continuous development difficult, and there are many cases where prototype production and demonstration experiments are stopped.

[0012] Although the technology for developing, operating, monitoring, and quality management of distributed computing systems has been cultivated in the field of computer science, virtualization technology, which is an important aspect of it, has not been utilized in robot systems because it is currently centered on the hypervisor type. This is because it has been observed that robot hardware cannot be recognized in the hypervisor type environment.

[0013] The purpose of the present invention is to flexibly utilize the technologies for developing, operating / monitoring and quality management of distributed computing systems in the field of computer science for continuous optimization in robot systems, thereby alleviating the trouble of managing or controlling computing resources and network environments for developers or managers of robot systems.

[0014] Means used to solve problems

[0015] One method based on the principles of the present invention is a robot application management device, which is used to execute robot applications by enabling multiple virtual containers to execute in a collaborative manner. The robot application management device comprises: a unit that manages a device group as a cluster for executing the robot application, the device group including at least one robot device and at least one computer device connected to the robot application management device via a local area network; and a unit that configures each of the multiple virtual containers in any device in the device group constituting the cluster and starts it.

[0016] Another method based on the principles of the present invention is a system comprising: a robot application management device for executing a robot application by enabling a plurality of virtual containers to be executed collaboratively; and at least one robot device and at least one computer device connected to the robot application management device via a local area network. The system further comprises: a unit for managing a group of devices possessed by the system as a cluster for executing the robot application; and a unit for configuring each of the plurality of virtual containers in any device in the group of devices constituting the cluster and starting it.

[0017] Another method based on the principles of the present invention is a robot application management method, which is used to execute robot applications by enabling multiple virtual containers to execute collaboratively, wherein a device group is managed as a cluster for executing the robot application, the device group includes at least one robot device and at least one computer device connected to the device executing the robot application management method via a local area network, and each of the multiple virtual containers is configured in any device in the device group constituting the cluster and started.

[0018] Another method based on the principles of the present invention is a robot application management program, which is used to execute robot applications by enabling multiple virtual containers to execute collaboratively. The robot application management program comprises: a program code for managing a device group as a cluster for executing the robot application, the device group including at least one robot device and at least one computer device connected to the device on which the robot application management program is installed via a local area network; and a program code for configuring each of the multiple virtual containers on any device in the device group constituting the cluster and starting it.

[0019] In the above-mentioned various modes based on the principles of the present invention, there are a first virtual container and a second virtual container among the multiple virtual containers. The first virtual container can select any device as a device for executing the virtual container. Since the second virtual container requires a physical connection in a robot device, there are constraints in the selection of a device for executing the virtual container. The first virtual container and the second virtual container operate in a loosely coupled manner. For the second virtual container, a device that satisfies the constraints is selected to perform the configuration.

[0020] FP201894JP Second telephone notification after OA1 Modification

[0021] Effects of the Invention

[0022] According to the present invention, it is possible to reduce the trouble of managing or controlling computing resources and network environment for developers or managers of robot systems, and to optimally utilize computer resources of a distributed computing system in a robot system that has, for example, physical constraints. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 This is a diagram showing an example of the configuration of a system according to an embodiment of the present invention (hereinafter referred to as “this system”).

[0024] Figure 2 This is a diagram showing another example of the structure of this system.

[0025] Figure 3This is a diagram showing an example of use of this system.

[0026] Figure 4 This is a diagram showing an installation example of this system.

[0027] Figure 5 This is a diagram showing an example of the flow of operations of the communication module unit and the wireless communication base station providing unit of the robot application management device.

[0028] Figure 6 This is a diagram showing an example of the flow of operations of the public information distribution unit of the robot application management device.

[0029] Figure 7 This is a diagram showing an example of the flow of operations of the robot application management device and the group execution type logical container virtualization environment providing unit of the terminal computer device.

[0030] Figure 8 This is a diagram showing an example of the flow of operations of the history management unit of the robot application management device.

[0031] Fig. 9 This is a diagram showing an example of a configuration structure for realizing a virtual container with constraints on the selection of devices executed in this system.

[0032] Fig.10 This is a diagram showing an example of an action to be taken when any device in the system malfunctions.

[0033] Fig.11 This is a diagram showing an example of a mechanism for configuring a robot system in which devices to which the virtual container technology has been introduced and devices to which the virtual container technology has not been introduced coexist in the present system.

[0034] Fig.12 This is a diagram showing an example of the configuration of virtual containers in this system. DETAILED DESCRIPTION

[0035] FP201894JP Second telephone notification after OA1 Modification

[0036] Hereinafter, embodiments of the present invention will be described. However, the following descriptions are intended to illustrate specific examples of the present invention and do not limit the scope of the present invention.

[0037] In the above-described embodiment based on the principle of the present invention, it may be configured such that at least one cloud service device connected to the robot application management device via an external network is included in the device group constituting the cluster.

[0038] Thus, in addition to being able to bundle multiple computer devices (robot devices, robot application management devices, and devices with computer resources) that constitute a system within a local area network, cloud service devices on the other side of the external network can also be bundled and processed as a cluster, thereby further improving the optimal use of computer resources. For example, a virtual container that performs tasks such as request response speed can be configured in a device within the local area network, and a virtual container that performs tasks such as parsing large amounts of data can be configured in a cloud service device.

[0039] In the above-mentioned method based on the principle of the present invention, it can also be constructed that there is a third virtual container among the multiple virtual containers. Since the third virtual container requires a given processing power or storage capacity, there are other constraints in the selection of a device to execute the virtual container. The third virtual container and the first virtual container and the second virtual container operate in a loosely coupled manner. For the third virtual container, a device that meets the other constraints is selected to perform the configuration.

[0040] Thus, for example, a virtual container that performs work that requires direct connection to physical elements such as motors and sensors mounted on a robot device (for example, USB connection, etc.) can be configured on the robot device, and on the other hand, a virtual container that performs work that requires actions on a computer device with specific performance can be configured on such a computer device (for example, a device with a GPU (Graphics Processing Unit) or a device with abundant memory, etc.).

[0041] In addition, loose coupling between these virtual containers can be easily achieved, for example, through the topic communication model of ROS.

[0042] FP201894JP Second telephone notification after OA1 Modification

[0043] In the above-mentioned aspect based on the principle of the present invention, it may be configured to further include a unit for storing a step of configuring and activating each of the plurality of virtual containers in any one of the device groups constituting the cluster.

[0044] This can relieve the developer or manager of the robot system from the task of manually logging into each device constituting the robot system and individually executing and maintaining a process, for example.

[0045] In the above-described aspect based on the principle of the present invention, a configuration may be further provided with means for storing information indicating which constraint each device constituting the device group of the cluster satisfies.

[0046] Thus, for example, as the above-mentioned step, a virtual container for which there are constraints on the selection of an executing device is stored, and the step is described as configuring the virtual container on a device that satisfies the constraint and starting it. When executing this step, the device for configuring the virtual container can be automatically selected by referring to information indicating which constraint each device satisfies.

[0047] In the above-mentioned mode based on the principle of the present invention, it can also be configured to further include the following unit: storing a program executable by the virtual container so that a device configuring each of the multiple virtual containers can obtain the program executable by the virtual container.

[0048] As a result, for example, each device can automatically obtain the entity of the virtual container specified for the device through the above steps, that is, the executable program (sometimes also called an image), thereby enabling the configuration and startup of each virtual container without the developer or administrator of the robot system having to manually log in to each device.

[0049] In the above-mentioned method based on the principle of the present invention, it can also be constructed that the program that can be executed by the virtual container is a package of the application program and OS that constitute the robot application, and a separated space is formed for each virtual container on the host OS of each device, which is executed from the host OS in a manner that looks like a process.

[0050] FP201894JP Second telephone notification after OA1 Modification

[0051] Thus, in a manner consistent with the principles of the present invention, container-type virtualization techniques can be utilized in a robotic system.

[0052] In addition, the virtual container can be implemented using the existing virtual container runtime technology. The so-called virtual container runtime is a container management software body that can automate the deployment (configuration on a computer to start) of applications in software containers (which are called virtual containers). In a method based on the principles of the present invention, a robot application is executed by making multiple virtual containers cooperate to execute, so the application in the software container equivalent to a virtual container realizes part of the functions of the robot application.

[0053] In addition, the configuration and startup of each virtual container relative to the multiple devices constituting the cluster can be achieved using the technology of the existing virtual container orchestration tool. The so-called virtual container orchestration tool is a tool that can automatically set, build, and deploy virtual containers relative to multiple computer devices (also called nodes or hosts), thereby also being able to achieve process survival monitoring, automatic restart, and simplified update distribution. In a method based on the principles of the present invention, it is preferred to use, for example, a tool technology that can set a given degree of constraints for each automatic configuration destination using labels.

[0054] As the technology for executing the virtual container, for example, “Docker” of Docker Inc., “Rkt” of CoreOS Inc., “LXC” of Linux (registered trademark) Foundation, “Hyper-V” of Microsoft Inc., etc. can be used.

[0055] As the technology of the virtual container orchestration tool mentioned above, for example, "Docker Swarm" (see Non-Patent Document 2), "Kubernetes", "Rancher", "fleet", etc. can be used.

[0056] In the above-mentioned method based on the principle of the present invention, it can also be configured to further include the following unit: when any device in the device group constituting the cluster malfunctions, the virtual container started by the malfunctioning device is reconfigured to another device constituting the cluster and started, thereby continuing the execution of the robot application, wherein the reconfiguration is modified by the second telephone notification after FP201894JP OA1

[0057] In the virtual container having a restriction on selection of the execution device, a device satisfying the restriction is selected for execution, and if there is no device satisfying the restriction other than the malfunctioning device, execution of the robot application is stopped.

[0058] As a result, it is possible to optimally utilize the computer resources of a distributed computing system in a robot system with physical constraints, and in the event that a part of the devices constituting the cluster malfunctions (for example, due to a failure of the computer device itself, the robot device being out of the communication range of the local area network, the cloud service device's communication being interrupted via the external network, etc., making it impossible to confirm whether the device is functioning normally), if the virtual container on the device can be reconfigured to another device, the robot system will automatically continue to operate; if reconfiguration is not possible, the robot system will automatically stop.

[0059] In the above-mentioned method based on the principle of the present invention, it can also be configured that the virtual container with constraints on the selection of the executing device is set as a stateless virtual container, and when any device in the device group constituting the cluster malfunctions and the execution of the robot application is stopped, the virtual container is configured and started after the malfunctioning device or a device replacing it is restored as a device constituting the cluster, thereby restarting the execution of the robot application.

[0060] Thus, for example, when a robot device is out of the communication range of the local area network and the robot system stops, the robot system can be automatically restarted after the robot device enters the communication range of the local area network again. As another example, when a robot device fails and the robot system stops, the robot system can be automatically restarted by starting a replacement robot device within the communication range of the local area network.

[0061] In the above-mentioned embodiment based on the principle of the present invention, it can also be configured to further include: a unit for stopping the virtual container when the device that is starting the virtual container is not a device constituting the cluster; and a unit for storing steps for stopping the virtual container.

[0062] Thus, for example, it is possible to automatically perform the second telephone notification modification after FP201894JPOA1 stops the virtual container when a certain condition is met.

[0063] By operating, when a part of the devices constituting the cluster leaves the cluster due to malfunction, the virtual container on the device corresponding to the cluster is automatically stopped (and the virtual container is discarded from the device), thereby improving security.

[0064] In the above-mentioned method based on the principle of the present invention, it can also be constructed to further include the following unit: collecting information indicating which device each of the multiple virtual containers is configured on and which state it is in, including being started or stopped, and sending the information to at least one of the services that display the information to the user or the services that store the history.

[0065] Thus, for example, in a terminal connected to the robot application management device via a local area network or an external network, the status of each device constituting the robot system can be displayed at once, reducing the burden on the developer or manager (user) of the robot system. In addition, in a storage connected to the robot application management device via a local area network or an external network, a detailed log of the control performed on the robot system and the action of the robot system can be saved. These terminals or storages can be set as devices that do not constitute a cloud.

[0066] In the above-mentioned method based on the principle of the present invention, it can also be constructed to further include the following unit: supporting network connection so that each virtual container in each device constituting the cluster can communicate via the local area network, and at least a part of the unit is set by configuring one of the multiple virtual containers on this device and starting it.

[0067] This can relieve the developer or administrator of the robot system from the task of manually performing network connection settings (time synchronization, address assignment, name resolution, etc.) on each device constituting the robot system. Communication between virtual containers on each device that has performed the settings can also be assisted by the technology of the virtual container runtime / virtual container orchestration tool.

[0068] In the above-mentioned method based on the principle of the present invention, it can also be constructed that the at least one robot device includes a mobile robot device, and at least the connection part of the local area network connected to the mobile robot device is constructed in a wireless manner, and also has at least one of the access point function or multi-hop function for the wireless connection.

[0069] FP201894JP Second telephone notification after OA1 Modification

[0070] The access point function enables the mobile robot and various devices (sensors, computers) to be connected to form a robot system, and the multi-hop function enables the flexible deployment of wireless LANs in accordance with the mobile robot's range of movement. As a result, the mobile robot can move around without worrying about the radio wave coverage.

[0071] In the above-described embodiment based on the principle of the present invention, at least one secondary robot application management device including at least a part of the units included in the robot application management device may be included in the device group constituting the cluster.

[0072] Thus, even if the main robot application management device stops working, the robot system can continue to operate by replacing it with the secondary robot application management device. In addition, the secondary robot application management device can be used to deploy the aforementioned wireless multi-hop function. Moreover, when multiple robot systems are running, the main robot application management device is shared, and by providing a secondary robot application management device with the aforementioned wireless access point function for each robot system, each robot device can use a nearby access point for wireless communication.

[0073] In the above-mentioned mode based on the principle of the present invention, the robot application management device may be located at the boundary between the local area network and the external network, and further include a unit for protecting each device connected to the local area network from the influence of the external network.

[0074] Thus, by isolating the local area network used for the robot system from the external network and protecting it (for example, using network address translation, firewall, etc.), security can be improved. For example, when the secondary robot application management device is set for each robot system, it is preferable to set the network separation protection function in the main robot application management device shared by multiple robot systems.

[0075] In addition, security can be ensured even in this case by using VPN (Virtual Private Network) to connect the robot application management device with the network separation protection function to the cloud service device on the other side of the external network. Alternatively, encrypted communication protocols such as HTTPS and MQTTS can be used for communication.

[0076] FP201894JP Second telephone notification after OA1 Modification

[0077] In the above-mentioned method based on the principle of the present invention, it can also be constructed that the robot application management device also has a sensor for inputting physical environment data for the robot application, and the virtual container that controls the sensor is configured in this device as one of the multiple virtual containers and started.

[0078] Thus, for example, it is possible to control the robot system taking into account both information from a sensor mounted on the robot device (sensing while moving) and information from a sensor mounted on the robot application management device (sensing the environment of the robot device's moving range). When the sub-robot application management device is provided for each robot system, a sensor may also be provided in the sub-robot application management device.

[0079] In the above-mentioned method based on the principle of the present invention, it can also be constructed to further include the following unit: assigning an address for network connection so that at least one virtual container in at least one device constituting the cluster can communicate with a device not constituting the cluster via the local area network.

[0080] As a result, a robot system can be constructed by mixing devices that have introduced the virtual container technology with devices that have not introduced the virtual container technology, so the development or management of the robot system can be started from the introduction of partial virtualization technology.

[0081] The above-mentioned various methods can also be different types of methods, or combined into other methods, or partially extracted into other methods. For example, a program installed in any device constituting the system in order to execute the above-mentioned method, a device other than the robot application management device constituting the above-mentioned system, a method executed in the device and a program for executing the method, and a storage medium storing the program for any of the above-mentioned programs can each be a method according to the principle of the present invention.

[0082] In addition, the above-mentioned method based on the principle of the present invention includes the processing of virtual containers with constraints on the selection of the execution device, but the method obtained by adding the various units described above to the method of processing virtual containers with constraints on the selection of the execution device that is not included in the second telephone notification after FP201894JP OA1 can also become an invention (an invention independent of the present invention).

[0083] Hereinafter, as an example, a system according to an embodiment of the present invention (hereinafter referred to as "this system") is described using the accompanying drawings. In the following example, Docker is used as a virtual container runtime, and Docker Swarm is used as a virtual container orchestration tool.

[0084] Figure 1 The illustrated system includes: a robot (physical elements such as sensors and motors); a robot application management device (master) 100, which is an edge computer for the purpose of providing network environment construction support and program development / execution environment required for the development of the robot system or program execution through a local area network (LAN600); a robot application management device (slave) 200, which repeatedly bears at least part of the functions of the robot application management device (master) 100; and multiple computer resources (terminal computer devices) 300, 400, which can become the management / control objects of the robot application management device (slave) 200.

[0085] The terminal computer device A (300) is a robot-connected type, equipped with a sensor 306 and a drive device 307. The terminal computer device B (400) is a single computer. The robot application management device and the terminal computer device are devices that have introduced virtual container technology, and each has a virtualization environment providing unit 103, 203, 303, 403 for group execution type logical container, and multiple virtual containers operating on them cooperate to execute one robot application (activate one robot system).

[0086] The present system can also accommodate a computer device 500 (e.g., a smartphone, a personal computer, etc.) on a LAN 600 that does not introduce the virtual container technology. In this example, the robot application management device (master) 100 has a function of connecting the LAN 600 to the Internet 700. A computer device (display / storage) 800 that does not introduce the virtual container technology can also be accommodated in the present system via the Internet 700.

[0087] Internet 700 is a computer that can access external resources (in Figure 1 In the example of the computer device 800), the communication network can be a mobile phone network such as LTE, a public WiFi, etc. The robot application management device (main) 100 has an Internet connection unit 108 (for example, a network interface card for modifying the wired LAN connection after the second telephone notification of FP201894JP OA1, etc.), such as Figure 3 As shown in the example of , it is possible to connect to the Internet 700 via the broadband router 109.

[0088] In addition, Figure 1 In the example, the robot application management device (master) 100 is connected to the display / storage 800 via the Internet 700, but the display / storage 800 can also be set on the LAN 600 and the system can be enclosed in the LAN.

[0089] The robot application management device, the terminal computer device, and the computer device without the introduction of the virtual container technology are respectively equipped with communication module parts 101, 201, 301, 401, and 501 for connecting to the LAN 600. Each communication module part can be connected via a wired network, but it is preferred that at least the computer device 300 directly connected to the mobile robot and other devices are connected via a wireless network such as WiFi. WiFi can process large-capacity data such as images, sounds, and point clouds, and is also a realistic option in that it is strong indoors.

[0090] Furthermore, in order to provide a multi-hop WiFi access point environment, not only the robot application management device (main) 100 but also the robot application management device (sub) 200 is provided with wireless communication base station providing units 102, 202 (for example, a wireless LAN adapter in accordance with the Wireless Distribution System (WDS) standard, etc.). WDS supports a function for expanding the range of communication by transmitting and receiving wireless LAN signals and relaying them. Thus, as long as there is a power supply, the entire range of movement of the mobile robot can be covered by the WiFi network.

[0091] The group execution type logical container virtualization environment providing unit 103 of the robot application management device (master) 100 includes a manager function (Docker Swarm Manager) of a virtual container orchestration tool, and manages the device group constituting the robot system by bundling (clustering) the device group into a cluster with reference to the operation procedure log storage unit 105. The group execution type logical container virtualization environment providing units 303 and 304 in each device on the managed side include an agent function (Docker Swarm Agent) of the virtual container orchestration tool.

[0092] The group execution type logical container virtualization environment providing unit 203 of the robot application management device (secondary) 200 includes a manager function of a virtual container orchestration tool, and manages the device group constituting the robot system with reference to the operation procedure log storage unit 205, based on the shared function with the robot application management device FP201894JP OA1 after the second telephone notification modification (primary) 100. It is also possible to use the computer resources of the robot application management device and the computer resources of the terminal computer device for the execution of the robot application. In this case, the group execution logical container virtualization environment providing units 103 and 104 also include the proxy function of the virtual container orchestration tool.

[0093] The group execution type logical container virtualization environment providing unit 103 of the robot application management device (master) 100 also has an image record book storage unit (Docker registry) 104, which manages the entity of the virtual container that enables each device constituting the robot system to operate, that is, the executable program (Docker image). The group execution type logical container virtualization environment providing unit 203 of the robot application management device (slave) 200 can also store all or part of the image record book.

[0094] The group execution type logical container virtualization environment providing unit 103 of the robot application management device (master) 100 can collect the standard output / standard error output of each virtual container in one place, and can start / configure / stop multiple virtual containers across hosts (devices constituting the cluster) as described in the setting file (operation procedure logbook) with only one command. In addition, as described later, by setting it as a stateless application, it is easy to scale up / scale down each service.

[0095] In addition, the status display unit 107 of the robot application management device (master) 100 can obtain the operating status of the services running in each virtual container across hosts (devices constituting the cluster) as a list through the action of the group execution type logical container virtualization environment providing unit 103. This list can be confirmed by the user of the robot system on the display 800 or the like.

[0096] Thus, by providing a robot application management device, virtual containers distributed across multiple hosts can be centrally processed, thereby improving operation and monitoring.

[0097] Furthermore, the robot application management device (master) 100 may also be provided with a public information distribution unit 106 (including a public information record storage unit not shown) to construct a network environment for the robot system. At least a part of the network environment may also be constructed after the robot application management device (master) FP201894JP OA1 is notified by telephone for the second time.

[0098] 100 or other clustered devices through a virtual container.

[0099] The network environment constructed in this way may include, for example, time synchronization (automatic time synchronization using the Network Time Protocol), name resolution (address resolution based on host names using the Domain Name System), address assignment (automatic assignment of IP addresses using the Dynamic Host Configuration Protocol, etc.), directory services (centralized management of account information using the Lightweight Directory Access Protocol, etc.), etc. In this way, the network application executed by the virtual container on the robot application management device can automatically synchronize the time of all computers even when the robot system is constructed in an enterprise network that restricts connection to a public NTP server.

[0100] In addition, the robot application management device (main) or (slave) may also be equipped with a sensor 206. The sensor 206 is, for example, an environmental sensor, a camera or other information collection device, and may be equipped with multiple sensors. These sensors can be controlled by a virtual container that operates for each sensor, and through the cooperation of these virtual containers, a sensor network can also be formed.

[0101] The robot application management device may also include a robot application development environment. In addition, it may also include a mechanism for detecting position information of a moving robot and a server function for distributing a map.

[0102] The robot application management device can set the mobile robot using ROS as the main target. In this case, it is also possible to provide an environment based on network / virtualization technology in a seamless manner as a WiFi access point.

[0103] exist Figure 2 In the illustrated system, the robot application management device (master) 100 is connected to a cloud service device (e.g., IaaS) 900 having a virtualization environment providing unit 903 for group execution type logical containers via the Internet 700. The cloud service device 900 also serves as one of the devices in the device group constituting the robot system, and enables the virtual container to operate.

[0104] In addition, ordinary cloud services (for example, PaaS, SaaS, etc.) that have not introduced virtual container technology can also be connected to the robot application management device (host) 100 via the Internet 700. For example, all or part of the information related to the control and action status of the robot system collected by the history management unit 107 from the communication module 101 can be saved in the storage 800 provided by the cloud service.

[0105] exist Figure 2 In the example, the robot application management device (host) 100 functions as an edge device between the cloud service and the robot. Since the robot application management device (host) 100 can construct the local area network used by the robot system as an environment separated from other networks, it is possible to optimally allocate computer resources, such as configuring virtual containers for services that require response speed and communication security in the local area network, and configuring virtual containers for other services in the cloud service device.

[0106] If the Internet connection unit 108 of the robot application management device (master) 100 and the Internet connection unit 908 of the cloud service device 900 have the function of a VPN gateway, the security of communication can be ensured even when using external computer resources.

[0107] exist Figure 2 In the example of , although the robot application management device (sub) 200 is not provided, it is of course possible to provide the device. Figure 1 In the example, a structure in which the robot application management device (sub) 200 is not provided may be adopted.

[0108] Figure 3 An example of using the present system to operate robot system A for robot device 1 (300-1) and robot system B for robot device 2 (300-2) is shown. In the figure, WiFi (AP) means a wireless access point, and WiFi (CL) means a wireless client. Robot device 2 wirelessly communicates with robot application management device (sub) 200-2, which is the nearest access point, but through the multi-hop function of robot application management device (sub) 200-1, it can also wirelessly communicate with robot application management device (main) 100 located outside the coverage of WiFi radio waves.

[0109] Here, for example, the robot system A can be composed of a robot application management device (master) 100, a robot application management device (slave) 200-1, a robot device 300-1, and a computer device 400 not shown in the figure, and the robot system B can be composed of a robot application management device (master) 100, a robot application management device (slave) 200-2, a robot device 300-2, and a computer device 400 not shown in the figure (that is, a host to be the action object is designated for each cluster).

[0110] FP201894JP Second telephone notification after OA1 Modification

[0111] When robot system A and robot system B are service robots that perform the same action, a virtual container group for robot system A and a virtual container group for robot system B are also generated separately. For example, virtual containers that perform the same service in computer device 400 are divided into two groups, one for robot system A and one for robot system B.

[0112] Figure 4 An example of installing the system using Docker technology is shown. A cluster environment consisting of virtual containers using "Docker" as a virtual container runtime and "DockerSwarm" as a virtual container orchestration tool is constructed on multiple computer resources such as a robot application management device (sometimes referred to as "RDB") 100 / 200, other computer devices 400, and a robot device 300, and a robot system is constructed by running a virtual container for robots ("ROS Container For RDB-APPS" in the figure).

[0113] exist Figure 4 In the example, the execution devices of the multiple computer devices (hosts) constituting the cluster include "Docker", "RDB-APPS", and "ROS Container for RDB-APPS". "RDB-APPS" is a daemon process that operates on the upper layer of "Docker" to operate virtual containers individually for various robots. The host with "Docker" and "RDB-APPS" installed has Figures 1-2 The "virtualization environment providing unit for group execution type logical container" described in.

[0114] The computer device that functions as a robot application management device may also include: a public information distribution unit 106 that builds the above-mentioned network environment (with functions such as NTP, DNS, and DHCP) as a "ROS Container for RDB-APPS" on "Docker" and "RDB-APPS"; a functional unit that performs a health check on the robot environment, a status display unit / history management unit 107 that collects information related to the robot's operating status and sends it to a display / storage; and a functional unit that provides a robot application development environment, etc. Thus, by simply setting the robot application management device between the Internet and the service robot, a robot-specific local area network and development support environment can be built.

[0115] In addition to the above functions, the "RDB-APPS" installed on each host can also take on the driver management of robot hardware. For example, when the "RDB-APPS" starts the virtual container FP201894JP OA1 on its host and notifies the modification by phone for the second time, if the virtual container is bound to hardware such as motors (actuators) and various sensors, the version of the hardware can be specified and the driver for running the hardware can be set on the host. As a result, since the device file is directly accessed, the advantage of container-type virtualization is that it is less likely to cause problems in the connection with the hardware compared to the hypervisor type.

[0116] exist Figure 4 In the example, "ROS Container For RDB-APPS" ( Figures 1-2 The Docker registry on the robot application management device is configured with a standard "ROS container" corresponding to "RDB-APPS", and the user of the robot system can implement the robot system development centered on the Docker container based on the standard ROS container. The Docker registry also allows any number of identical ROS environments to be replicated instantly.

[0117] In the development of the robot system described above, the Docker container image after the OS and middleware are set up is saved in the Docker registry. When developing the robot application, only the difference is installed based on the container image, which can improve the efficiency of the modification work. In addition, by setting one Docker image as one package, environmental pollution can be prevented.

[0118] In more detail, first, the template image stored in the virtual container image record storage unit 104 ("Docker registry") is used, and only the difference between the template image and the virtual container creation step record (also called "Dockerfile") is described. Then, using this Dockerfile, the command to create the virtual container image is executed, and the newly created image is given a name and saved in the Docker registry.

[0119] Each Docker container ( Figures 1-2 The virtual container) is comprehensively monitored by the application "Docker Swarm Manager" (included in the "Virtualization Environment Providing Unit for Group Execution Type Logical Containers" 103 / 203) residing on the robot application management device.

[0120] Each computer device is given a label to clarify its role, and each computer's "Group Execution FP201894JPOA1" is modified after the second telephone notification.

[0121] The row-type logical container virtualization environment providing unit (including the application "DockerSwarm Agent" residing on each computer device) stores the assigned labels. The "Docker Swarm Manager" refers to the labels assigned to each computer device, selects the computer device ("Docker SwarmAgent") with a label suitable for the execution of each virtual container, and distributes tasks.

[0122] Thus, the startup / monitoring of each computer device (node) or each virtual container (process) and the standard output from it can be processed uniformly in the robot application management device. Therefore, no matter how many related computer devices are added, the user of the robot system can operate as if it were one.

[0123] In addition, here, an example in which the robot application management device becomes a manager is described, but other computer devices constituting the cluster can also become managers. In this case, when each computer device participates in the cluster, it is selected whether the device functions as a "Docker Swarm Manager" or a "Docker Swarm Agent". Which one should be selected is stored in the "group execution type logical container virtualization environment providing unit" of each computer device.

[0124] Furthermore, cloud services useful for robots can be used through the robot application management device using various protocols such as VPN, HTTPS, and MQTT. For example, SaaS (Vision API, Voice API, machine learning, and other services) required for robot operation can be used.

[0125] Dump data such as rosbag can also be stored in the storage 800 with high data integrity and availability provided as the above-mentioned cloud service. Various data required for the management of robot actions can also be extracted (filtered) from the collected data and saved.

[0126] In addition, the robot application management device does not force the development of robot systems based on Docker containers. Even if the previous ROS development method is used, the various network infrastructure functions provided by the robot application management device can be enjoyed. In addition, only part of the functions can be Dockerized, which can be flexibly used according to the situation of the user of the robot system.

[0127] FP201894JP Second telephone notification after OA1 Modification

[0128] Figure 5 The wireless communication base station providing unit 102 / 202 (WiFi access point) and the communication module unit 201 (WiFi client) for the robot application management device 100 / 200 are shown as follows Figure 3 This is an example of the flow of operations for expanding the coverage of WiFi radio waves by using the multi-hop function as shown.

[0129] Figure 6 An example of an action flow is shown for enabling the public information distribution unit 106 of the robot application management device 100 (or a virtual container that executes network environment construction), the robot application management device 200, and the communication module units 201, 301, 401 of the terminal computer device 300 / 400 to cooperate to enable multiple computer devices constituting a cluster to communicate via a local area network.

[0130] Figure 7An example of the flow of actions when the system is installed using Docker technology is shown. In this example, the group execution type logical container virtualization environment providing units 103, 203, 303, 403, 903 of the robot application management device 100 / 200 and the terminal computer device 300 / 400 / 900 constitute a cluster that implements one or more robot systems (the information of the device group constituting the cluster is also stored in the "group execution type logical container virtualization environment providing unit"). The manager operates on the robot application management device 100 / 200 to create (S72) or destroy (S76) each Docker container on multiple agents.

[0131] As for the deployment (configuration and startup instructions) of each Docker container on each computer device, the operation steps (e.g., yml description) stored in the virtual container operation step record book storage unit 105 are read in and performed by the manager (S71). Through this "Docker Swarm Manager", the computer resources of the subordinate (belonging to the same cluster) "Docker Swarm Agent" are monitored (pooled) across hosts, and the configuration of virtual containers is transparently managed thereon (S73). Therefore, when a device belonging to the cluster leaves (S75), the virtual containers that can continue to operate in other devices among the virtual containers running in the device are reconfigured and started to the device of the destination. At this time, the virtual container running in the device of the move source is stopped and discarded as needed.

[0132] Figure 8 FIG. 1 shows an example of the operation flow of the history management unit 107 of the robot application management device 100 when the system is installed using the Docker technology. Figure 7 (S74) FP201894JP OA1 Second telephone notification modification

[0133] This system provides a function that enables implementation that matches the design policy for optimally utilizing computer resources in a cluster environment based on virtual container technology, even when devices (robots, etc.) with certain constraints are included.

[0134] Fig. 9 An example of a configuration for realizing a virtual container with restrictions on the selection of an execution device when the present system is installed using the Docker technology is shown.

[0135] In the default behavior of "Docker Swarm Manager" (an application deployment automation tool), since computer resources are handled transparently, the host selection for executing the virtual container is the one determined by the manager to be the best.

[0136] At this time, in the following cases, the corresponding virtual container is deployed on the intended host computer instead of the host computer selected by default.

[0137] 1. A virtual container for an application with a physical connection (USB connection, etc.).

[0138] 2. A virtual container for applications that require a GPU or require abundant memory and need to operate on computer resources with specific functions.

[0139] like Fig. 9 As illustrated in (a), the label function is used to configure the virtual container on the intended host computer. In "Docker Swarm", each agent (node) is pre-assigned a label (stored in the "Virtualization Environment Provider for Group Execution Type Logical Containers" when the cluster is established). In the figure, the label item "environment" is assigned any one of the labels "dev, test, prod", and the label item "storage" is assigned any one of the labels "disk, ssd". Although not shown in the figure, sometimes a label such as whether it is an edge device (as another example of a computer resource with the above-mentioned specific functions) is also specified.

[0140] Then, when executing the application, refer to Fig. 9 The yml description shown in (b) deploys the virtual container. The yml description contains the definition of labels related to the execution node, etc., which is only modified by the second telephone notification after FP201894JP OA1

[0141] The agent with the same label as specified by "service / db / deploy / placement / constraints / node.labels.storage" (in this case, "ssd") becomes the host on which the virtual container can operate. Fig. 9 In (a), there are 3 out of 5 proxies that are hosts that meet the condition, and a virtual container for a service called "db" is deployed on only one of these 3 proxies. This allows the host that performs the action to be controlled (the action is performed only on a specific node).

[0142] In order to minimize the impact of the constraints of physical connections that exist in large numbers in the robot system, it is preferable to create a virtual container with physical connection constraints as one that does not have a state (stateless) (for example, when it is necessary to maintain a state, the outside of the virtual container is made to have a state). In addition, the idea of ​​separating computer resources that cannot be mounted on the robot (for example, those that require weight or a large-capacity power supply) and limiting the use of computer resources on the robot to the minimum required can also be a design idea that should be adopted when creating a virtual container in the robot system.

[0143] Fig.10 The following is an example of the actions that the system takes to deal with a situation where any device (host) constituting a cluster fails to function properly (for example, when the heartbeat of the "Docker Swarm Manager" disappears) when the system is installed using Docker technology. This allows restarting of virtual containers running on a failed node, specifying an end option, restarting a failed node on a different host, and the like.

[0144] First, if there is only one agent with the same defined label in the virtual container running in the node that is in a malfunction (S90 is yes), the system cannot be restored until the corresponding agent is restored (S93). Figure 7 Stop or abandon the virtual container in (S76).

[0145] However, by setting the virtual container assigned as the processing object as a virtual container without a state (stateless), the system can be restored immediately after the agent is restored. That is, the "part that depends on the constraint" is composed of the minimum unit required for the operation, and the "part that depends on the constraint" and the "part that does not depend on the constraint" operate in a loosely coupled manner, so that the system can be restored with less downtime.

[0146] FP201894JP Second telephone notification after OA1 Modification

[0147] On the other hand, if there are two or more agents with the same defined label for the virtual container running in the node that is in a malfunction (S90 is No), the virtual container can be immediately started on another agent (S91) through the action of "Docker Swarm", so that the robot system recovers (S92). Therefore, for processing that can be executed anywhere, such as image processing and action planning, by making it run on any agent, even if a host device stops working, the process can be automatically restarted in other hosts that have already formed a cluster.

[0148] However, even if it can be restored immediately in appearance, if the virtual container is a virtual container with a state (stateful), the state may be reset. In this case, by setting it as a construction that keeps the state outside the virtual container, a system without downtime can be realized.

[0149] The fact that any device constituting the cluster is separated from the cluster due to malfunction can be detected by the function residing in the "RDB-APPS" installed in each device. For example, the "RDB-APPS" of the terminal computer device regularly checks whether it is connected to the valid wireless base station providing unit by regularly monitoring the communication module unit of the device. And when the communication with the wireless base station is interrupted for a certain period of time (communication interruption occurs), the virtual container (robot application) started by RDB-APPS is stopped.

[0150] On the other hand, the "RDB-APPS" of the robot application management device periodically monitors the wireless base station providing unit of the device to periodically confirm whether each device in the list of devices constituting the cluster (list of devices connected together via wireless) is effectively connected. This list is stored by "RDB-APPS" and updated based on the periodic monitoring results (such as Fig.10 If another device forms a cluster, as in S91 of FIG. 1 , the device stored in the list is changed).

[0151] Then, when the communication between the "RDB-APPS" of the robot application management device and a certain device is interrupted and a certain period of time has passed (communication interruption occurs), for example, Fig.10 If there is no device that can be used to replace the device that has experienced communication interruption, the virtual container (robot application) is stopped based on the operation procedure log managed by the virtualization environment providing unit for the group execution type logical container. Thereafter, when the above-mentioned periodic monitoring detects that the device connected via wireless FP201894JP OA1 is disconnected, the second telephone notification is modified.

[0152] When a certain period of time has passed since the device is added (a device with communication interruption has occurred or a device replacing the device is reconnected), a virtual container (robot application) is started on the connected device based on the operation sequence record book.

[0153] The following is a summary of design guidelines for realizing the requirements of a "system with constraints" such as a robot system and making optimal use of computer resources.

[0154] A. Pool computer resources across hosts through virtual container orchestration tools and manage the configuration of virtual containers on them.

[0155] B. Separate the system with constraints into "parts that depend on the constraints" and "parts that do not depend on the constraints" (the so-called "constraints" mean that the host that executes the virtual container is restricted).

[0156] C. The "constraint-dependent part" consists of the smallest unit required for the action.

[0157] D. The “constraint-dependent part” and the “constraint-independent part” act in a loosely coupled manner (e.g., utilizing the topic communication model of ROS).

[0158] Through the mechanism for realizing this design policy and the installation coordinated therewith, even if a part of the computer resources becomes unusable, it can be automatically replaced by other computer resources, and even if a part of the system stops working, the impact on other parts can be minimized, thereby preventing the chain shutdown of other systems. In addition, the part of the system that stops working can be automatically restored as long as the conditions are met, thereby minimizing the impact of the constraints.

[0159] The above description focuses on the example of applying this system to the field of network service robots that implement continuous development / application, but this system can also be applied to the IoT field that processes large-volume data such as images / sounds / 3D data, the field of providing network infrastructure as a multi-functional WiFi access point, the sharing economy of hardware devices via cloud services or the charging system accompanying this, etc.

[0160] FP201894JP Second telephone notification after OA1 Modification

[0161] In addition to the above functions, the "RDB-APPS" installed on each host can also have a function for partially introducing virtual container technology into the system. This allows even users who are not familiar with Docker to achieve low-cost startup of container-type virtualization, and allows bare-metal hybrid environments in cases where various hardware connections that Docker cannot recognize are required.

[0162] Fig.11An example of a structure for mixing devices that have introduced virtual container technology and devices that have not introduced virtual container technology to form a system in the present system when the present system is installed using Docker technology is shown. In the case of a virtual container B that only requires collaboration between virtual containers, when the virtual container B is started, a private IP address for Docker (eth0: 199.0.2.3) is allocated and converted to the IP address (203.0.113.5) of the host OS of the node where the virtual container B is configured, thereby performing communication via the local area network.

[0163] On the other hand, in the case of virtual container A that requires collaboration with a device that has not introduced the virtual container technology, when starting the virtual container A, in addition to the private IP address (eth0: 192.0.2.6) for Docker, an unassigned IP address (eth1: 203.0.113.7) of the same LAN segment as the host OS of the node where the virtual container A is configured is also assigned. eth0 converts the assigned IP address to the IP address (203.0.113.5) of the host OS where the virtual container A is configured to communicate via the LAN, while eth1 directly uses the assigned IP address to communicate with the device ( Figures 1-2 500) to communicate with the computer device.

[0164] In order to implement the above-mentioned mechanism, for example, "RDB-APPS" includes a function for detecting the startup of a virtual container configured on this device (whether it is automatically started by Swarm or manually started by the user, and whether it is configured and started at the beginning of the execution of the robot application or reconfigured and started from other settings during the execution of the robot application), and performing the following processing in conjunction with the detection.

[0165] First, refer to the flag assigned to the virtual container to determine whether an IP address of the same LAN segment as the host OS should be assigned (i.e., determine whether it is a request or a second telephone notification modification after FP201894JP OA1 that does not introduce virtual container technology).

[0166] devices).

[0167] Then, if it is necessary to allocate, allocate a virtual interface (eth*) other than the virtual interface (eth0) for Docker to the started virtual container, allocate a physical address (MAC address) generated by hashing the host name of the started virtual container, use the physical address and the host name of the virtual container to request the issuance of an IP address to the DHCP server or router, and allocate the issued IP address to the virtual interface (eth*). After the IP address is allocated, communication confirmation to the LAN or WAN can also be implemented.

[0168] Fig.12 An example of the system constructed using Docker technology is shown for a mobile robot for image inspection equipped with multiple cameras (a robot that moves to any position by autonomous driving and takes high-resolution images, and performs real-world analysis through image analysis, referred to here as a "real robot").

[0169] Fig.12 The distributed computing system in the example is composed of a robot application management device ("RDB") and three other computers. The other three are the low-power "Computer A (Computer_A)" and "Computer B (Computer_B)" installed in the real robot, and the "High_CPU_Computer" dedicated to computing with a high-performance CPU. The computers are connected to each other via a WiFi network provided by the RDB.

[0170] In addition, a daemon process ("RDB-APPS") for operating a separate container for robots is introduced in each computer, and a Docker container (ROS container for RDB-APPS "ROS Container For RDB-APPS") is running on each computer. This Docker container is a container obtained by integrating ROS applications in units of nodes based on the standard ROS container. Then, the robot service is provided through the collection of integrated Docker containers.

[0171] Computer_A is connected to USB cameras, mobile robots, and audio devices such as speakers or microphones. To control these physically connected devices from the Docker container, Fig.12 In the example, "DockerCompose" is used to install the virtual container that performs this control. This can also be achieved by using "Docker Swarm" to select the execution node function based on the tag "docker-compose.yml" specified when the container is started.

[0172] The virtual container deployed on Computer_A includes, for example, a laser distance measuring device (Ethernet (registered trademark) connection) action container "urg_node", a plurality of camera (USB connection) action container "usb_cam", a speaker / microphone (audio jack connection) container "audio_common", and a mobile robot (USB connection) driver container "turtlebot_bringup". Although "urg_node" is a virtual container that can be configured to start on another computer, "usb_cam", "audio_common" and "turtlebot_bringup" are virtual containers that control physically connected devices, so they need to be configured on Computer_A to start.

[0173] In a virtual container deployed on Computer_B, another computer resource mounted on the real robot, there is, for example, a container "ros_eye" for screen (serial bus connection) control.

[0174] In the virtual container deployed on High_CPU_Computer, a computer resource set in a place different from the real robot, there is, for example, a container "amcl" for path search calculation of the mobile robot, a container "web_video_server" for converting the dynamic image captured by the "usb_cam" on Computer_A into HTML5, a container "kobuki_auto_docking" for calculating the path from the current position of the mobile robot to the charger, containers "roswww" and "ros_bridge_server" for processing ROS in HTML5, a container "image_transport" for compressing images of the "usb_cam" on Computer_A, a container "robot_pose_publisher" for calculating / publishing the posture (quaternion) of the mobile robot, and a container "bridge_ojtalk_audio" for sound synthesis.

[0175] In this example, from the perspective of creating a virtual container with no state (stateless) that is constrained by a physical connection, the saving of the content captured by the "usb_cam" container is performed by other containers such as "web_video_server" or "image_transport". These other containers are not constrained by a physical connection and are therefore deployed on High_CPU_Computer instead of Computer_A.

[0176] FP201894JP Second telephone notification after OA1 Modification

[0177] In the virtual container deployed on the RDB, which is also a computer resource, there is a container "roscore" for address resolution of ROS participating nodes. The specifications of the CPU, memory, disk, etc. of the RDB can be increased or decreased by the services of the Docker container operating on the RDB. If you want to make the RDB perform advanced calculations, you can use a computer with higher specifications or a computer equipped with a GPU.

[0178] In addition, RDB may also have a temperature sensor, an air pressure sensor, and a humidity sensor. In this case, the Docker container for controlling the temperature sensor, the Docker container for controlling the air pressure sensor, and the Docker container for controlling the humidity sensor are virtual containers that control devices with physical connections, so they are deployed on the RDB as virtual containers that need to be configured on the RDB to start.

[0179] The embodiments of the present invention have been described above. It is obvious that those skilled in the art can implement the above embodiments by various modifications, improvements, applications, etc., and such embodiments are also included in the scope of the present invention.

Claims

1. A robot application management device for executing a robot application by causing a plurality of virtual containers to be executed in a collaborative manner, the robot application management device comprising: A unit for managing a device group as a cluster for executing the robot application, the device group including at least one robot device and at least one computer device connected to the robot application management device via a local area network; and a unit for configuring each of the plurality of virtual containers in any device in the device group constituting the cluster and activating the device; Among the plurality of virtual containers, there are a first virtual container and a second virtual container. The first virtual container can select any device as a device for executing the virtual container, while the second virtual container requires a physical connection in a robot device, so there is a restriction in the selection of a device for executing the virtual container. The first virtual container and the second virtual container operate in a loosely coupled manner. For the second type of virtual container, a device satisfying the constraint is selected to perform the configuration. The virtual container having the restriction on the selection of the execution device is set as a stateless virtual container, When any device in the device group constituting the cluster malfunctions and the execution of the robot application stops, the virtual container is configured and started after the malfunctioning device or a device replacing it is restored as a device constituting the cluster, thereby restarting the execution of the robot application.

2. The robot application management device according to claim 1, characterized in that: At least one cloud service device connected to the robot application management device via an external network is included in a device group constituting the cluster.

3. The robot application management device according to claim 1 or 2, characterized in that: There is a third type of virtual container among the plurality of virtual containers. Since the third type of virtual container requires corresponding processing power or storage capacity, there are other constraints in the selection of a device for executing the virtual container. The third virtual container operates in a loosely coupled manner with the first virtual container and the second virtual container. For the third type of virtual container, a device satisfying the other constraints is selected to perform the configuration.

4. The robot application management device according to claim 1 or 2, characterized in that: The robot application management device further includes a unit that stores a procedure for configuring and activating each of the plurality of virtual containers in any one of the device groups constituting the cluster.

5. The robot application management device according to claim 1 or 2, characterized in that: The robot application management device further includes a unit that stores information indicating which constraint each device in the device group constituting the cluster satisfies.

6. The robot application management device according to claim 1 or 2, characterized in that: The robot application management device further includes a unit for storing executable programs in such a manner that a device configuring each of the plurality of virtual containers can obtain the executable programs of the virtual container.

7. The robot application management device according to claim 1 or 2, characterized in that: The program that can be executed by the virtual container is a package of the application program and the operating system, i.e., the OS, that constitute the robot application. A space separated for each virtual container is formed on the host OS of each device. The program that can be executed by the virtual container appears to be executed as a process from the host operating system.

8. The robot application management device according to claim 1 or 2, characterized in that: The robot application management device further includes a unit that, when any device in the device group constituting the cluster malfunctions, relocates a virtual container started by the malfunctioning device to another device constituting the cluster and starts the virtual container, thereby continuing the execution of the robot application. For the virtual container having constraints on selection of the executing device, a device satisfying the constraints is selected for the reconfiguration, and when there is no device satisfying the constraints other than the malfunctioning device, execution of the robot application is stopped.

9. The robot application management device according to claim 1 or 2, characterized in that: The robot application management device also has: means for stopping the virtual container when the device on which the virtual container is started is not a device constituting the cluster; and Means for storing steps for stopping the virtual container.

10. The robot application management device according to claim 1 or 2, characterized in that: The robot application management device further includes a unit that collects information indicating which device each of the plurality of virtual containers is configured in and which state it is in, including being started or stopped, and transmits the information to at least one of a service that displays the information to a user and a service that stores the history.

11. The robot application management device according to claim 1 or 2, characterized in that: The robot application management device further comprises a unit that supports network connection so that each virtual container in each device constituting the cluster can communicate via the local area network. At least a part of the unit is set by configuring one of the plurality of virtual containers in the device and activating the virtual container.

12. The robot application management device according to claim 1 or 2, characterized in that: The at least one robotic device comprises a mobile robotic device, At least the connection part of the local area network connected to the mobile robot device is constructed in a wireless manner, The robot application management device further includes at least one of an access point function or a multi-hop function for the wireless connection.

13. The robot application management device according to claim 1 or 2, characterized in that: At least one secondary robot application management device including at least a part of the units included in the robot application management device is included in the device group constituting the cluster.

14. The robot application management device according to claim 1 or 2, characterized in that: The robot application management device is located at the boundary between the local area network and the external network. The robot application management device further includes a unit for protecting each device connected to the local area network from the influence of the external network.

15. The robot application management device according to claim 1 or 2, characterized in that: The robot application management device further comprises a sensor, which is used to input physical environment data for the robot application. A virtual container for controlling the sensor is configured in the device as one of the plurality of virtual containers and started.

16. The robot application management device according to claim 1 or 2, characterized in that: The robot application management device further includes a unit that assigns an address for network connection so that at least one virtual container in at least one device constituting the cluster can communicate with a device not constituting the cluster via the local area network.

17. A robot application management system, comprising: A robot application management device for executing a robot application by causing a plurality of virtual containers to be executed in a collaborative manner; and At least one robot device and at least one computer device are connected to the robot application management device via a local area network, The system is characterized by comprising: A unit for managing a group of devices included in the system as a cluster for executing the robot application; and a unit for configuring each of the plurality of virtual containers in any device in the device group constituting the cluster and activating the device; Among the plurality of virtual containers, there are a first virtual container and a second virtual container. The first virtual container can select any device as a device for executing the virtual container, while the second virtual container requires a physical connection in a robot device, so there is a restriction in the selection of a device for executing the virtual container. The first virtual container and the second virtual container operate in a loosely coupled manner. For the second type of virtual container, a device satisfying the constraint is selected to perform the configuration. The virtual container having the restriction on the selection of the execution device is set as a stateless virtual container, When any device in the device group constituting the cluster malfunctions and the execution of the robot application stops, the virtual container is configured and started after the malfunctioning device or a device replacing it is restored as a device constituting the cluster, thereby restarting the execution of the robot application.

18. A robot application management method for executing a robot application by causing a plurality of virtual containers to execute in cooperation, the robot application management method being characterized in that: managing a device group as a cluster for executing the robot application, the device group including at least one robot device and at least one computer device connected to the device executing the robot application management method via a local area network, Among the plurality of virtual containers, there are a first virtual container and a second virtual container. The first virtual container can select any device as a device for executing the virtual container, while the second virtual container requires a physical connection in a robot device, so there is a restriction in the selection of a device for executing the virtual container. The first virtual container and the second virtual container operate in a loosely coupled manner. each of the plurality of virtual containers is configured in any device in the device group constituting the cluster and started; For the second type of virtual container, a device satisfying the constraint is selected to perform the configuration. The virtual container having the restriction on the selection of the execution device is set as a stateless virtual container, When any device in the device group constituting the cluster malfunctions and the execution of the robot application stops, the virtual container is configured and started after the malfunctioning device or a device replacing it is restored as a device constituting the cluster, thereby restarting the execution of the robot application.

19. A robot application management program for executing a robot application by causing a plurality of virtual containers to be executed in cooperation, the robot application management program comprising: program code for managing a device group as a cluster for executing the robot application, the device group including at least one robot device and at least one computer device connected to a device on which the robot application management program is installed via a local area network; and program code for configuring each of the plurality of virtual containers in any device in the device group constituting the cluster and starting the virtual container, Among the plurality of virtual containers, there are a first virtual container and a second virtual container. The first virtual container can select any device as a device for executing the virtual container, while the second virtual container requires a physical connection in a robot device, so there is a restriction in the selection of a device for executing the virtual container. The first virtual container and the second virtual container operate in a loosely coupled manner. For the second type of virtual container, a device satisfying the constraint is selected to perform the configuration. The virtual container having the restriction on the selection of the execution device is set as a stateless virtual container, When any device in the device group constituting the cluster malfunctions and the execution of the robot application stops, the virtual container is configured and started after the malfunctioning device or a device replacing it is restored as a device constituting the cluster, thereby restarting the execution of the robot application.

Images