WO2019146763A1 - ロボットアプリケーション管理装置、システム、方法及びプログラム - Google Patents

ロボットアプリケーション管理装置、システム、方法及びプログラム Download PDF

Info

Publication number
WO2019146763A1
WO2019146763A1 PCT/JP2019/002517 JP2019002517W WO2019146763A1 WO 2019146763 A1 WO2019146763 A1 WO 2019146763A1 JP 2019002517 W JP2019002517 W JP 2019002517W WO 2019146763 A1 WO2019146763 A1 WO 2019146763A1
Authority
WO
WIPO (PCT)
Prior art keywords
robot
virtual container
robot application
virtual
application management
Prior art date
Application number
PCT/JP2019/002517
Other languages
English (en)
French (fr)
Inventor
福田　竜也
緑里 濱田
康二 林
Original Assignee
株式会社インテック
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社インテック filed Critical 株式会社インテック
Priority to US16/964,286 priority Critical patent/US11327856B2/en
Priority to CN201980010102.2A priority patent/CN111656320A/zh
Publication of WO2019146763A1 publication Critical patent/WO2019146763A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters 
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
    • B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
    • B25J9/00—Programme-controlled manipulators
    • B25J9/16—Programme controls
    • B25J9/1602—Programme controls characterised by the control system, structure, architecture
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
    • B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
    • B25J9/00—Programme-controlled manipulators
    • B25J9/16—Programme controls
    • B25J9/1615—Programme controls characterised by special kind of manipulator, e.g. planar, scara, gantry, cantilever, space, closed chain, passive/active joints and tendon driven manipulators
    • B25J9/162—Mobile manipulator, movable base with manipulator arm mounted on it
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2023—Failover techniques
    • G06F11/203—Failover techniques using migration
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/202—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant
    • G06F11/2035—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where processing functionality is redundant without idle spare hardware
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3089—Monitoring arrangements determined by the means or processing involved in sensing the monitored data, e.g. interfaces, connectors, sensors, probes, agents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G06F9/4856—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration
    • G06F9/4862—Task life-cycle, e.g. stopping, restarting, resuming execution resumption being on a different machine, e.g. task migration, virtual machine migration the task being a mobile agent, i.e. specifically designed to migrate
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45591—Monitoring or debugging support
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks

Definitions

  • the present invention relates to a technology for realizing a robot system by a distributed computing system, and more particularly to a mechanism for managing robot applications in the system.
  • ROS Robot Operating System
  • a mechanism for bundling a plurality of computers constituting a system into one cluster is generally provided. They include mechanisms for automating much of operation / monitoring, advancing development efficiently, and lowering quality control costs. This mechanism is realized by combining various network technologies and various technologies based on virtualization technology (for example, non-patent document 2).
  • ROS does not define management and control of a plurality of computers. Therefore, the ROS may use resources such as a large amount of machines and processes randomly, or the application of the ROS may be limited depending on the network environment (time synchronization, address assignment, name resolution, etc.).
  • robot system developers and administrators manually log in to each of the computers constituting the robot system to individually execute and execute robot processes. I have no choice. Furthermore, it is difficult for continuous development because individual developers and administrators change how to handle applications with physical limitations on execution, such as robot systems, in distributed computing systems. There are many cases in which the creation of prototypes and demonstration experiments are stopped.
  • the present invention utilizes a technique for continuously optimizing development and operation / monitoring and quality control of distributed computing system in the computer science field in a robot system, and a developer or manager of the robot system
  • the purpose is to reduce the burden of managing and controlling computing resources and the network environment.
  • One aspect in accordance with the principles of the present invention is a robot application management apparatus for executing a robot application by executing a plurality of types of virtual containers in cooperation, and via the robot application management apparatus and a local area network
  • means for placing and activating any of the devices is a robot application management apparatus for executing a robot application by executing a plurality of types of virtual containers in cooperation, and via the robot application management apparatus and a local area network
  • a unit for managing a group of devices including at least one robot device and at least one computer device to be connected as a cluster for executing the robot application, and each of the plurality of types of virtual containers constitute the cluster
  • means for placing and activating any of the devices are examples of the devices.
  • Another aspect in accordance with the principles of the present invention is a robot application management device for executing a robot application by executing a plurality of types of virtual containers in cooperation, and the robot application management device is connected to the robot via a local area network.
  • a system comprising at least one robot device and at least one computer device, wherein the device group of the system is managed as a cluster for executing the robot application; And means for arranging and activating each of the devices in any of the device groups constituting the cluster.
  • Yet another aspect in accordance with the principles of the present invention is a robot application management method for executing a robot application by executing a plurality of types of virtual containers in cooperation, an apparatus for executing the robot application management method and a local
  • An apparatus group including at least one robot apparatus and at least one computer apparatus connected via an area network is managed as a cluster for executing the robot application, and each of the plurality of types of virtual containers is Deploy and start on any of the device groups that make up the cluster.
  • Yet another aspect in accordance with the principles of the present invention is a robot application management program for executing a robot application by executing a plurality of types of virtual containers in cooperation, and a device in which the robot application management program is installed
  • the plurality of types of virtual containers include a first type of virtual container which may select any device as a device for executing the virtual container, and There is a second type of virtual container that restricts selection of a device that executes the virtual container to require dynamic connection, and the first type of virtual container and the second type of virtual container are Operating in a loosely coupled manner, the placement being performed for the second type of virtual container by selecting devices that satisfy the constraints.
  • the present invention it is possible to reduce the burden of managing and controlling computing resources and the network environment by a developer or manager of a robot system, and, for example, in a robot system having physical restrictions, it is a distributed type It becomes possible to optimally utilize the computer resources of the computing system.
  • history management part of a robot application management apparatus The figure which shows an example of the mechanism for implement
  • At least one cloud service device connected to the robot application management device via an external network may be included in the device group configuring the cluster.
  • a cloud service device on the other side of the external network is By bundling, it becomes possible to treat it as one cluster, and can further evolve the optimal use of computer resources. For example, virtual containers that perform tasks that require high response speed are placed on devices in the local area network, and virtual containers that perform tasks such as analyzing a large amount of data are placed on cloud service devices. It is possible.
  • the plurality of virtual containers requires a processing capacity or a storage capacity greater than a predetermined level, and thus has another limitation on the selection of an apparatus for executing the virtual containers.
  • There is a virtual container and the third type of virtual container and the first and second type of virtual containers operate in loose coupling, and the arrangement is the third type of virtual container May be performed by selecting a device that satisfies the other constraint.
  • a virtual container performing work requiring direct connection for example, USB connection etc.
  • a physical element such as a motor or a sensor mounted on a robot device
  • Virtual containers that perform tasks requiring operations on computing devices with the following capabilities should be placed on such computing devices (eg, devices with GPU (Graphics Processing Unit), devices with abundant memory, etc.) Becomes possible.
  • the apparatus further comprises means for storing a procedure for arranging and activating each of the plurality of types of virtual containers in any of the devices constituting the cluster. It is also good.
  • the apparatus may further comprise means for storing information indicating which device of each of the device group configuring the cluster satisfies which constraint.
  • the procedure described to arrange and start the virtual container in the device satisfying the restriction is stored.
  • the apparatus further comprises means for storing an executable program of the virtual container so that an apparatus in which each of the plurality of types of virtual containers is arranged can acquire the executable program of the virtual container. You may do so.
  • each device to automatically obtain, for example, an executable program (sometimes called an image) that is an entity of a virtual container specified for the device according to the above-described procedure.
  • an executable program sometimes called an image
  • the robot system developer or administrator can arrange and start each virtual container without manually logging in to each device.
  • the executable program of the virtual container is obtained by packaging an application program constituting the robot application and the OS, and each virtual container is executed on the host OS of each device.
  • a separate space may be formed to be executed as a process to the host OS.
  • containerized virtualization technology can be utilized in a robotic system.
  • the virtual container can be realized using existing virtual container runtime technology.
  • the virtual container runtime is a main body of container management software, which is capable of automating the deployment of an application (referred to as a virtual container) in the software container (placement and activation on a computer).
  • a virtual container an application
  • placement and activation on a computer a computer
  • one robot application is executed by executing a plurality of types of virtual containers in cooperation with one another, so that an application in a software container corresponding to one virtual container is a robot application. It will realize some functions.
  • each virtual container with respect to a plurality of devices configuring a cluster can be realized using the technology of the existing virtual container orchestration tool.
  • the virtual container orchestration tool is capable of automating setting, construction and deployment of virtual containers for multiple computer devices (also called nodes or hosts), which enables process alive monitoring and automatic restart. It is also possible to realize simplification of update distribution and the like.
  • Examples of the technology of the virtual container orchestration tool described above include “Docker Swarm” (see Non-Patent Document 2), “Kubernetes” (see https://kubernetes.io/), and “Rancher” (https: // You can use “fleet” (see https://coreos.com/fleet/docs/latest/launching-containers-fleet.html) etc.
  • a virtual container activated by the device in failure is constituted by the cluster.
  • the apparatus further comprises means for continuing execution of the robot application by relocating to another device and activating the relocation, and the relocation satisfies the constraint for a virtual container that has a constraint on selection of the device to be executed.
  • the execution of the robot application may be stopped when there is no device other than the device that has suffered the operation failure, which is performed by selecting the device and the device satisfying the restriction is present.
  • the virtual container having a restriction in the selection of the device to be executed is made stateless, and any one of the devices constituting the cluster falls into operation, and the robot application is executed.
  • the execution of the robot application is resumed by arranging and starting the virtual container.
  • the robot system in the case where the robot apparatus has left the communication range of the local area network and the robot system is stopped, if the robot apparatus enters the communication area of the local area network again, the robot system is automatically It will be possible to resume.
  • the robot system may be automatically restarted by launching an alternative robot device within the communication range of the local area network. It will be possible.
  • means for stopping the virtual container when the device in which the virtual container is activated is no longer a device configuring the cluster, and a procedure for stopping the virtual container And means for storing may be further provided.
  • the plurality of types of virtual containers disposed in what device collects information indicating what kind of state including whether being stopped or is starting
  • the information processing apparatus may further comprise means for transmitting to at least one of a service to be displayed to the user or a service to store the history.
  • the state of each device constituting the robot system is collectively displayed, and the developer or manager of the robot system ( It is possible to reduce the burden on the user).
  • the storage connected to the robot application management apparatus via the local area network or the external network it is possible to save the detailed log of the control performed on the robot system and the operation of the robot system.
  • the apparatus further comprises means for supporting network connection so that each virtual container in each device constituting the cluster can communicate via the local network, at least a part of the means being Alternatively, one of the plurality of types of virtual containers may be provided by being placed in the device and activated.
  • the robot system developer or administrator is freed from the task of manually setting (time synchronization, address assignment, name resolution, etc.) for network connection to each device configuring the robot system.
  • Communication between virtual containers on each device with this setting may be assisted by the technology of virtual container runtime / virtual container orchestration tool.
  • the at least one robot apparatus includes a moving robot apparatus, and at least a connection portion to the moving robot apparatus of the local network is configured wirelessly.
  • the mobile terminal may further include at least one of an access point function or a multi-hop function for the wireless connection.
  • This access point function makes it possible to connect the mobile robot and various devices (sensors and computers) to configure the robot system, and the multi-hop function allows wireless local flexibility according to the movement range of the mobile robot. It is possible to extend the area network. As a result, the mobile robot can move around without worrying about the radio wave coverage.
  • At least one secondary robot application management device including at least a part of the means provided in the robot application management device may be included in the group of devices constituting the cluster.
  • the robot system can continue its operation by substituting the secondary robot application management device. Also, it becomes possible to deploy the above-mentioned wireless multi-hop function using the secondary robot application management device. Furthermore, when moving a plurality of robot systems, the main robot application management device is common, and by installing the secondary robot application management device having the above-mentioned wireless access point function for each robot system, each robot device is an access point nearby It is possible to communicate wirelessly using
  • the robot application management device is located at the boundary between the local area network and the external network, and means for protecting each device connected to the local area network from the external network. It may further be provided.
  • this network separation protection function may be provided to the main robot application management device common to a plurality of robot systems.
  • a robot application management device provided with this network separation and protection function is connected to a cloud service device on the other side of the external network using a VPN (Virtual Private Network), security can also be realized there. It will be possible to secure.
  • communication may be performed using an encrypted communication protocol such as HTTPS or MQTTS.
  • the robot application management device further comprises a sensor for inputting data of a physical environment for the robot application, and a virtual container for controlling the sensor is the plurality of virtual As one of the containers, it may be arranged in the own device and activated.
  • the secondary robot application management device may be provided with a sensor.
  • an address for network connection so that at least one virtual container in at least one device constituting the cluster can communicate with the device not constituting the cluster via the local network. It may further comprise means for applying
  • a robot system can be configured by mixing devices that have introduced virtual container technology and devices that do not, it is possible to start development and management of robot systems from partial introduction of virtualization technology. Become.
  • a program installed in any device that configures the system to execute the above method may be in one aspect in accordance with the principles of the present invention, such as a storage medium storing the program.
  • the present system a system according to an embodiment of the present invention (hereinafter, referred to as “the present system”) will be described with reference to the drawings.
  • the present system a system according to an embodiment of the present invention (hereinafter, referred to as “the present system”) will be described with reference to the drawings.
  • Docker is used as a virtual container runtime
  • Docker Swarm is used as a virtual container orchestration tool.
  • the present system illustrated in FIG. 1 is a robot (physical elements such as sensors and motors) and a network environment construction support and program development / execution environment necessary for robot system development and program execution using a local network (LAN 600).
  • a robot application management apparatus (main) 100 which is an edge computer for the purpose of providing, a robot application management apparatus (sub) 200 which redundantly carries out at least a part of its functions, and a plurality of management / control targets And computer resources (terminal computer devices) 300, 400.
  • the terminal computer device A (300) is a robot connection type and mounts 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 end computer device are devices to which virtual container technology is introduced, and each includes a group execution type logical container virtualization environment providing unit 103, 203, 303, 403, and The plurality of virtual containers operating in step together cooperate to execute one robot application (operate one robot system).
  • the present system can also accommodate the computer device 500 (for example, a smart phone, a personal computer, etc.) on the LAN 600 in which the virtual container technology is not introduced.
  • the function of connecting the LAN 600 and the Internet 700 is provided in the robot application management device (main) 100 in this example. It is also possible to accommodate a computer device (display / storage) 800 without virtual container technology installed in the system via the Internet 700.
  • the Internet 700 may be a communication network accessible to an external computer resource (the computer apparatus 800 in the example of FIG. 1), and may be a cellular phone network such as LTE, public WiFi, or the like.
  • the robot application management apparatus (main) 100 includes an Internet connection unit 108 (for example, a network interface card for wired LAN connection), and as shown in the example of FIG. Can be connected to
  • the robot application management apparatus (main) 100 and the display / storage 800 are connected via the Internet 700, but the display / storage 800 is provided on the LAN 600 and this system is in the LAN. It is also possible to configure closed.
  • the robot application management apparatus, the terminal computer apparatus, and the computer apparatus without virtual container technology introduced have communication module units 101, 201, 301, 401, and 501 for connecting to the LAN 600, respectively.
  • Each communication module unit may be connectable via a wired network, but at least between the computer device 300 directly connected to the moving robot and other devices, it is connected via a wireless network such as WiFi. It is preferable to make it possible. WiFi can handle large amounts of data such as images, sounds, point clouds, etc., and is a realistic option as it is strong indoors.
  • the robot application management apparatus (main) 100 not only the robot application management apparatus (main) 100 but also the robot application management apparatus (sub) 200 are wireless communication base station providing units 102, 202 (for example, Wireless Distribution).
  • a wireless LAN adapter etc. compliant with the System (WDS) standard is provided. WDS supports functions to extend the communicable range by transmitting and receiving signals of wireless LAN and relaying. This makes it possible to cover the entire range traveled by the mobile robot with a WiFi network, as long as there is only a power supply.
  • the group execution type logical container virtualization environment providing unit 103 of the robot application management apparatus (main) 100 includes a manager function (Docker Swarm Manager) of a virtual container orchestration tool, and refers to the operation procedure ledger storage unit 105.
  • a group of devices constituting a robot system are bundled (clustered) and managed as a cluster.
  • the group execution type logical container virtualization environment providing unit 303, 304 in each managed device includes an agent function (Docker Swarm Agent) of a virtual container orchestration tool.
  • the group execution type logical container virtualization environment provision unit 203 of the robot application management apparatus (secondary) 200 includes a manager function of a virtual container orchestration tool, and performs operation after sharing functions with the robot application management apparatus (main) 100. Management of devices constituting the robot system is performed with reference to the procedure ledger storage unit 205. It is also possible to use the computer resources of the robot application management apparatus for executing the robot application as well as the computer resources of the terminal computer apparatus, in which case the group execution type logical container virtualization environment providing unit 103, 104 also includes the agent function of virtual container orchestration tool.
  • the virtual environment providing unit 103 for group execution type logical containers of the robot application management apparatus (main) 100 also includes an image ledger storage unit (Docker registry) 104, and is a virtual container operated by each device constituting the robot system. Manage an executable program (Docker image) that is an entity.
  • the group execution type logical container virtualization environment providing unit 203 of the robot application management apparatus (secondary) 200 may store all or part of the image ledger.
  • the group execution type logical container virtualization environment provision unit 103 of the robot application management apparatus (main) 100 enables collection of standard output and standard error output of each virtual container in one place, and only one command. Then, as described in the setting file (operation procedure ledger), it becomes possible to start, place and stop a plurality of virtual containers across host machines (devices constituting a cluster). Also, as described later, by using a stateless application, it is possible to easily scale up and down each service.
  • the status display unit 107 of the robot application management apparatus (main) 100 operates in each virtual container across host machines (devices forming a cluster) by the function of the group execution logical container virtualization environment providing unit 103. It is possible to obtain the operating status of the service in a list. The list can be confirmed by the user of the robot system or the like on the display 800 or the like.
  • the robot application management apparatus (main) 100 may construct a network environment for the robot system by providing the common information distribution unit 106 (including a common information ledger storage unit not shown). At least a part of the construction of this network environment can also be performed by a virtual container on the robot application management apparatus (main) 100 or other clustered apparatus.
  • time synchronization (automatic time synchronization is performed using a network time protocol), name resolution (address resolution based on a host name using a domain name system), and the like are performed to construct a network environment performed as such.
  • Address assignment (automatic assignment of IP address using dynamic host configuration protocol etc.), directory service (centralized management of account information using light weight directory access protocol etc.), etc. may be included.
  • time synchronization of all computers is automatically performed. Will be able to
  • the robot application management device (main) or (sub) may include the sensor 206.
  • the sensor 206 is, for example, an information collecting device such as an environment sensor or a camera, and may be provided in plurality. These sensors can be controlled by a virtual container operating for each of them, and by cooperation of the virtual containers, a sensor network can also be configured.
  • the robot application management apparatus may further include a robot application development environment. Further, a mechanism for detecting position information of a moving robot or a server function for distributing a map may be provided.
  • the robot application management apparatus described above can use a mobile robot in which a ROS is used as a main target. At that time, it is possible to provide an environment based on network and virtualization technology as well as acting as a WiFi access point.
  • the robot application management apparatus (main) 100 is a cloud service apparatus (for example, IaaS) 900 including the group execution type logical container virtualization environment providing unit 903 via the Internet 700.
  • the cloud service device 900 also operates a virtual container as one of a group of devices constituting a robot system.
  • a general cloud service for example, PaaS, SaaS, etc.
  • the robot application management apparatus (main) 100 via the Internet 700, and, for example, the history management unit 107 communicates All or part of the information on control and operation of the robot system collected from the module 101 may be stored in the storage 800 provided by the cloud service.
  • the robot application management apparatus (main) 100 acts as an edge device between the cloud service and the robot. Since the robot application management apparatus (main) 100 can construct a local area network for the robot system as an environment separated from other networks, it operates services that require high response speed and communication security.
  • the virtual containers are arranged in the local area network, and the virtual containers for moving other services are arranged in the cloud service device, which enables optimal allocation of computer resources.
  • the Internet connection unit 108 of the robot application management apparatus (main) 100 and the Internet connection unit 908 of the cloud service device 900 have the function of the VPN gateway, communication security can be achieved even when using external computer resources. It is possible to secure.
  • the robot application management apparatus (sub) 200 is not provided in the example of FIG. 2, it is of course possible to provide this. Conversely, in the example of FIG. 1, the robot application management apparatus (sub) 200 may not be provided.
  • FIG. 3 shows an example in which a robot system A for the robot apparatus 1 (300-1) and a robot system B for the robot apparatus 2 (300-2) are operating using this system.
  • WiFi (AP) means a wireless access point
  • WiFi (CL) means a wireless client.
  • the robot apparatus 2 wirelessly communicates with the robot application management apparatus (sub) 200-2, which is the nearest access point, but is out of the reach of the WiFi radio waves by the multi-hop function of the robot application management apparatus (sub) 200-1.
  • the robot application management apparatus (main) 100 can communicate wirelessly.
  • the robot system A includes a robot application management apparatus (main) 100, a robot application management apparatus (sub) 200-1, a robot apparatus 300-1, and a computer apparatus 400 (not shown).
  • System B includes robot application management apparatus (main) 100, robot application management apparatus (sub) 200-2, robot apparatus 300-2, and computer apparatus 400 (not shown). Can be specified for each cluster).
  • FIG. 4 shows an example of implementing this system using Docker technology.
  • Virtual container runtime “Docker” and virtual container orchestration on multiple computer resources such as robot application management device (sometimes referred to as “RDB”) 100/200 and other computer devices 400 and robot device 300
  • RDB robot application management device
  • FIG. 4 builds a clustering environment with virtual containers using the tool “Docker Swarm”, move a virtual container for robots ("ROS Container For RDB-APPS" in the figure), and build a robot system.
  • RDB robot application management device
  • the execution devices of each of the plurality of computer devices (host machines) configuring the cluster include “Docker”, “RDB-APPS”, and “ROS Container For RDB-APPS”.
  • “RDB-APPS” is a daemon that operates on the upper layer of "Docker” to operate virtual containers individually for various robots.
  • the host machine on which “Docker” and “RDB-APPS” are installed includes the “group execution type logical container virtualization environment providing unit” described with reference to FIGS.
  • the computer device acting as a robot application management device constructs the network environment described above as “ROS Container For RDB-APPS” on “Docker” and “RDB-APPS” (functions such as NTP, DNS, DHCP, etc.
  • Common information distribution unit 106 a functional unit for performing a health check of the robot environment, a status display unit / history management unit 107 for collecting information on the operation status of the robot and transmitting it to the display / storage, a robot application development environment May be provided. This makes it possible to build a robot-specific local area network and a development support environment simply by installing the robot application management device between the Internet and the service robot.
  • the “RDB-APPS” installed in each host machine can also be responsible for robot hardware driver management and the like in addition to the functions described above.
  • RDB-APPS starts a virtual container on the host machine
  • the virtual container is tied to hardware such as a motor (actuator) or various sensors
  • the version of the hardware To allow drivers to be set up on the host machine to run the hardware.
  • the advantage of container type virtualization is also taken into consideration that connection with hardware is less likely to occur compared to the hypervisor type.
  • ROS Container For RDB-APPS (virtual container of FIGS. 1 and 2) can be at least partially created by the implementation of the user of the robot system.
  • a standard "ROS Container” corresponding to "RDB-APPS” is placed in the Docker registry on the robot application management device, and the user of the robot system is based on this standard ROS container and a robot centering on the Docker container System development can be implemented.
  • the Docker registry also allows instant replication of any number of complete identical ROS environments.
  • Each Docker container (virtual container in FIGS. 1 and 2) on each computer device (a robot application management device and another computer device installed in a local area network or installed on a cloud) constituting a cluster is And integrated monitoring by a “Docker Swarm Manager” (included in “group execution type logical container virtualization environment providing unit” 103/203) which is an application resident on the robot application management apparatus.
  • a label for clarifying the role is given to each computer device, and the “group execution type logical container virtualization environment providing unit” of each computer device (“Docker Swarm Agent, which is an application resident on each computer device”) Contains the label given).
  • Docker Swarm Manager refers to the label given to each computer device, selects a computer device (“Docker Swarm Agent”) having a label suitable for execution of each virtual container, and performs task assignment.
  • the robot application management apparatus is a manager
  • other computer apparatuses configuring a cluster become a manager.
  • each computer device participates in a cluster, it selects whether it operates as a "Docker Swarm Maneger” or as a "Docker Swarm Agent”. Which one to select is stored in the “virtual execution environment provision unit for county execution logical containers” of each computer device.
  • cloud services useful for robots can be used via the robot application management device using protocols such as VPN, HTTPS, and MQTT.
  • protocols such as VPN, HTTPS, and MQTT.
  • SaaS Vision API, Voice API, services such as machine learning, etc.
  • the robot application management device does not force robot system development based on the Docker container, and various network infrastructure functions provided by the robot application management device, etc., even when using a conventional ROS development method. Many conveniences can be enjoyed. Moreover, it is also possible to make only a part of the functions into Docker container, and can be used properly according to the convenience of the user of the robot system.
  • the wireless communication base station providing unit 102/202 (WiFi access point) and the communication module unit 201 (WiFi client) of the robot application management apparatus 100/200 are WiFi by the multi-hop function as illustrated in FIG. An example of the flow of operation for extending the reach of radio waves is shown.
  • the common information distribution unit 106 (or virtual container for executing network environment construction) of the robot application management apparatus 100, and the communication module units 201, 301, and 401 of the robot application management apparatus 200 and the terminal computer 300/400.
  • An example of an operation flow for cooperatively enabling a plurality of computer devices constituting a cluster to communicate via a local area network is shown.
  • FIG. 7 shows an example of the flow of operations in the case of implementing this system using Docker's technology.
  • the robot application management apparatus 100/200 and the virtual environment providing unit 103, 203, 303, 403, 903 for the group execution type logical container of the end computer device 300/400/900 are one or more robot systems.
  • the information of the device group that composes the cluster is also stored in the “Ground execution type logical container virtualization environment provision unit” that realizes one), and the manager on the robot application management device 100/200 It operates and creates (S72) or destroys (S76) each Docker container on a plurality of agents.
  • Deployment (instructions of placement and activation) of each Docker container on each computer device is performed by the manager reading the operation procedure (for example, yml description) stored in the virtual container operation procedure ledger storage unit 105 (S71) .
  • This "Docker Swarm Manager” monitors (pools) the computer resources of the "Docker Swarm Agent” under it (belongs to the same cluster) beyond the host machine, and on top of that, the placement of the virtual container is managed transparently (S73). Therefore, when a device belonging to a cluster leaves (S75), among virtual containers operated by the device, those that can be continuously operated by another device are relocated to the destination device and activated. To be done. At that time, the virtual container that was operating in the migration source device is stopped and discarded as necessary.
  • FIG. 8 shows an example of the flow of the operation of the history management unit 107 of the robot application management apparatus 100 when the system is implemented using Docker technology.
  • An operation example of the state display unit 107 of the robot application management apparatus 100 is shown in FIG. 7 (S74).
  • FIG. 9 shows an example of a mechanism for realizing the arrangement of a virtual container which is restricted in the selection of the device to be executed when the system is implemented using Docker's technology.
  • the corresponding virtual container is not placed on the host computer selected by default, but placed on the intended host computer.
  • a label function is used as illustrated in FIG. 9A.
  • each agent node
  • a label is given a label in advance (stored in "group execution type logical container virtualization environment providing unit” at the time of cluster setup).
  • one of the labels "dev, test, prod” is given to the label item "environment” and one of the labels “disk, ssd” is given to the label item "storage”.
  • a label may be designated as to whether or not it is an edge device (another example of the computer resource having the specific function described above).
  • the virtual container is deployed with reference to the yml description illustrated in FIG. 9B.
  • the yml description describes the label definition for the execution node, etc., and only the agent that matches the label specified in "service / db / deploy / placement / constraints / node.labels.storage” (in this case "ssd” ) Is the host machine on which the virtual container can operate.
  • the agent that matches the label specified in "service / db / deploy / placement / constraints / node.labels.storage” (in this case "ssd” ) Is the host machine on which the virtual container can operate.
  • three of the five agents are host machines that satisfy this condition, and the virtual container of the service "db" is deployed only in one of these three. This makes it possible to control the operating host machine (make it operate only at a specific node).
  • Fig. 10 shows that, when this system is implemented using Docker technology, if any device (host machine) that composes the cluster malfunctions (for example, the heartbeat of "Docker Swarm Manager" is lost. Once, we have shown an example of the action the system takes to address it. As a result, it is possible to restart a virtual container operating on a node that has malfunctioned, specify an end option, and restart a node that has malfunctioned on a different host machine.
  • host machine for example, the heartbeat of "Docker Swarm Manager”
  • stop and discard (S76) of the virtual container in FIG. 7 may be performed.
  • Constraint-dependent part consists of the minimum units necessary for operation, and "Constraint-dependent part” and “Constraint-independent part” follow the design guideline to operate in a loose coupling, System recovery with less downtime is possible.
  • the virtual container is not affected by the function of "Docker Swarm". Immediately, it can be activated on another agent (S91), and the robot system returns (S92). Therefore, for processing that can be executed anywhere, such as image processing and operation planning, by running on any agent, even if one host machine goes down, another host machine that has already configured a cluster. , The process will be restarted automatically.
  • the state may be reset. Also in such a case, it is possible to realize a system without downtime by maintaining the state outside the virtual container.
  • RDB-APPS Remote Access Security
  • “RDB-APPS” of the terminal computer device periodically checks whether it is connected to a valid wireless base station providing unit by periodically monitoring the communication module unit of its own device. Then, when communication with the wireless base station is discontinued and a predetermined time elapses (communication disconnection occurs), the virtual container (robot application) activated via the RDB-APPS is stopped.
  • RDB-APPS of the robot application management device periodically monitors the wireless base station providing unit of its own device, thereby listing the devices that constitute the cluster (list of devices connected via wireless) Periodically check whether each device in is connected effectively. This list is stored in “RDB-APPS” and updated based on the periodic monitoring result (If another device forms a cluster as in S91 of FIG. 10, it is stored in the list. Devices will be changed).
  • RDB-APPS of the robot application management device performs, for example, the operation of FIG. If there is no available device in place of the device where the communication interruption occurred, stop the virtual container (robot application) based on the operation procedure ledger managed by the group execution type logical container virtualization environment provider. . After that, it is detected that the number of devices connected via wireless connection has increased (the device where the communication has been interrupted or the device that has replaced the device has been connected again) by the periodic monitoring described above, and a certain period of time is detected. When it passes, a virtual container (robot application) is started on the connected device based on the operation procedure register.
  • the virtual container orchestration tool is used to pool computing resources beyond the host machine and manage the placement of virtual containers on it.
  • Constraint-dependent part and “constraint-independent part” operate in loose coupling (eg, using the topic communication model of ROS).
  • the mechanism for realizing this design guideline and its implementation make it possible to automatically substitute other computer resources even if some of the computer resources become unavailable. Even if one part goes down, the influence on others can be minimized, and it is possible to prevent the chaining down that involves other systems. Also, some of the down systems can be restored automatically if the conditions are met, and the impact of constraints can be minimized.
  • this system is an IoT field that handles large volumes of data such as video, audio and 3D data.
  • the present invention can be applied to the field of providing network infrastructure as a multifunctional WiFi access point, sharing economy of hardware devices via cloud service, charging system associated therewith, and the like.
  • the "RDB-APPS" installed in each host machine can also have a function for partially introducing virtual container technology into the system, in addition to the functions described above. This enables small-scale container-type virtualization even for users who are not familiar with Docker handling, and allows a bare-metal mixed environment when various hardware connections that can not be recognized from Docker are necessary. Become.
  • FIG. 11 shows an example of a mechanism for configuring a system by mixing an apparatus in which the virtual container technology is introduced and an apparatus in which the virtual container technology is not mixed in the case of implementing the present system using Docker's technology.
  • virtual container B which only requires cooperation between virtual containers
  • a private IP address eth0: 199.0.2.3 for Docker is assigned, and the virtual container B is arranged.
  • Communication is performed via the local area network by converting it to the IP address (203.0.113.5) of the host OS of the target node.
  • the private IP address (eth0: 192.0.2.6) for Docker is used.
  • 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 disposed is assigned.
  • eth0 converts the assigned IP address to the IP address (203.0.113.5) of the host OS of the node where virtual container A is arranged, and performs communication via LAN
  • eth1 is assigned IP The address is used as it is to communicate with the device (the computer apparatus 500 of FIGS. 1 and 2) of the LAN segment.
  • RDB-APPS does not activate the virtual container disposed on its own device (whether it is activated automatically by Swarm or manually by the user. Also, it includes an application for detecting whether or not the robot application is placed and started at the start of execution of the robot application or whether it is relocated and started from another device during execution, and in conjunction with this detection, Execute the following processing.
  • a virtual interface (eth *) other than the virtual interface (eth0) for Docker is allocated to the activated virtual container, and the physical address (MAC address) generated by hashing the host name of the activated virtual container Request the DHCP server or router to issue an IP address using this physical address and the host name of the virtual container, and assign the issued IP address to the virtual interface (eth *).
  • the communication confirmation to the LAN or WAN may be performed.
  • FIG. 12 shows a mobile robot for image inspection equipped with a plurality of cameras (a robot that moves to an arbitrary place by autonomous traveling to capture a high resolution image and performs analysis of the real world by image analysis. An example of constructing this system using Docker's technology is shown.
  • the distributed computing system in the example of FIG. 12 is configured of a robot application management device ("RDB”) and three other computers.
  • the other three are the low power consumption "Computer_A” and “Computer_B” mounted on the real robot, and the "High_CPU_Computer” specialized for calculation by operating a high-performance CPU.
  • Each computer is mutually connected by the WiFi network provided by RDB.
  • RDB-APPS daemon
  • ROS Container For RDB-APPS a Docker container
  • This Docker container is based on the standard ROS container, with ROS applications integrated on a per-node basis.
  • a set of integrated Docker containers provide robot services.
  • a USB camera Connected to the Computer_A are a USB camera, a mobile robot, and audio devices such as a speaker and a microphone.
  • a virtual container that performs the control is implemented using “Docker Compose” in the example of FIG. This may be implemented by a function of selecting an execution node according to a label "docker-compose.yml” specified at container startup using "Docker Swarm”.
  • the virtual container deployed on this Computer_A includes, for example, a container “urg_node” for operating a laser ranging device (Ethernet (registered trademark), a container “usb_cam” for operating multiple cameras (USB connection), a speaker microphone ( There is an audio jack connection) container “audio_common” and a mobile robot (USB connection) driver container “turtlebot_bringup”.
  • a container “urg_node” for operating a laser ranging device (Ethernet (registered trademark)
  • a container “usb_cam” for operating multiple cameras (USB connection)
  • speaker microphone There is an audio jack connection
  • audio_common and a mobile robot (USB connection) driver container “turtlebot_bringup”.
  • "Urg_node” is a virtual container that may be deployed and started on another computer, but "usb_cam”, “audio_common” and “turtlebot_bringup” are virtual containers that control devices with physical connections
  • a virtual container deployed on Computer_B which is another computer resource mounted on a real robot
  • a container for controlling a screen (serial bus connection).
  • the virtual container deployed on High_CPU_Computer which is a computer resource provided in a different place from the real robot, includes, for example, a container “amcl” for path search calculation of the mobile robot, and an HTML5 image taken by “usb_cam” on Computer_A.
  • Container “web_video_server” for converting to, container “kobuki_auto_docking” for calculating the route from the mobile robot's current location to the charger, container “roswww” and “ros_bridge_server” for handling ROS in HTML5, “usb_cam” on Computer_A
  • container “image_transport” for compressing an image
  • robot_pose_publisher for calculating and publishing a posture of a mobile robot (quaternion)
  • bridge_ojtalk_audio for speech synthesis.
  • a virtual container deployed on RDB which is itself a computer resource, is, for example, a container "roscore" for performing address resolution of a ROS participating node.
  • the specifications of the RDB CPU, memory, disk, etc. can be increased or decreased depending on the Docker container service operated on the RDB. If you want the RDB to execute advanced calculations, a higher spec computer or GPU is installed. You just have to use a computer.
  • the RDB may also include, for example, an air temperature sensor, an air pressure sensor, and a humidity sensor, in which case, a Docker container for controlling the air temperature sensor, a Docker container for controlling the air pressure sensor, and a humidity sensor Since the Docker container for controlling the device is a virtual container for controlling a device having a physical connection, it is deployed on the RDB as a container that needs to be placed and activated in the RDB.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Computing Systems (AREA)
  • Robotics (AREA)
  • Mechanical Engineering (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mathematical Physics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Orthopedic Medicine & Surgery (AREA)
  • Automation & Control Theory (AREA)
  • Manipulator (AREA)
  • Hardware Redundancy (AREA)

Abstract

複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行する。このため、ロボットアプリケーション管理装置（１００）と、少なくとも一つのロボット装置（３００）と、少なくとも一つのコンピュータ装置（４００）とを、ローカルエリアネットワーク（６００）を介して接続する。これらを含む装置群を、ロボットアプリケーションを実行するためのクラスタとして管理し、各仮想コンテナを、クラスタを構成する装置群のいずれかに配置して起動させる。

Description

ロボットアプリケーション管理装置、システム、方法及びプログラム
　本発明は、ロボットシステムを分散型計算システムによって実現する技術に関し、特に、当該システムにおいてロボットアプリケーションの管理を行う機構に関する。
　近年、サービスロボットのソフトウェアの開発において、ＲＯＳ（Ｒｏｂｏｔ　Ｏｐｅｒａｔｉｎｇ　Ｓｙｓｔｅｍ）と呼ばれる分散型計算システムを指向したロボット向けミドルウェアが使われることが、多くなっている。ＲＯＳによって提供されるエコシステム及び豊富なライブラリ群によって、サービスロボットの開発効率は、向上している（例えば、非特許文献１）。
　一方、分散型計算システムは、元々、コンピュータ・サイエンス分野において、古くから使われている考え方の一つである。システムを構成する複数のコンピュータを束ねて、一つのクラスタとして捉えるための仕組みが、一般的に提供されている。それらは、運用／監視の多くを自動化し、開発を効率的に進め、品質管理コストを下げるための仕組みを内包している。この仕組みは、各種ネットワーク技術や仮想化技術をベースとした様々な技術を組み合わせることにより、実現される（例えば、非特許文献２）。
銭飛著「ＲＯＳプログラミング」森北出版株式会社（２０１６年３月３０日発行） 古賀政純著「Ｄｏｃｋｅｒ実践ガイド」株式会社インプレス（２０１５年１２月２１日発行）
　ロボットシステムを複数台のコンピュータで構成して分散型計算システムによって実現することが、一般的になってきているが、ＲＯＳでは、複数台のコンピュータの管理や制御については定義されていない。そのため、ＲＯＳによって無秩序に大量のマシンやプロセス等のリソースが使われたり、ＲＯＳの適用がネットワーク環境（時刻同期、アドレス付与、名前解決等）に依存して制限されたりすることが起こり得る。
　現状では、そのようなことが起こらないように、ロボットシステムの開発者や管理者が、ロボットシステムを構成する各コンピュータに、手動でログインして、ロボット用のプロセスの実行やメンテナンスを個別に行わざるを得ない。しかも、個々の開発者や管理者によって、ロボットシステムのように実行に物理的な制約のあるアプリケーションを、分散型計算システムにおいてどのように扱うかが変わってくるため、継続的な開発が難しく、プロトタイプの作成と実証実験止まりとなってしまう例が多発している。
　分散型計算システムの開発と運用／監視と品質管理とを継続的に最適化するための技法は、コンピュータ・サイエンス分野では培われてきているが、その重要な一つである仮想化技術は、従来、ハイパーバイザー型が中心であったため、ロボットシステムでは利用されてこなかった。ハイパーバイザー型の環境下では、ロボットハードウェアを認識できないケースが見られたためである。
　本発明は、コンピュータ・サイエンス分野における分散型計算システムの開発と運用／監視と品質管理とを継続的に最適化するための技法を、ロボットシステムにおいて活用し、ロボットシステムの開発者や管理者が計算リソースとネットワーク環境の管理や制御を行う煩わしさを、軽減することを目的とする。
　本発明の原理に従う一つの態様は、複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理装置であって、前記ロボットアプリケーション管理装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置と少なくとも一つのコンピュータ装置とを含む装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理する手段と、前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させる手段とを備える。
　本発明の原理に従う別の態様は、複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理装置と、前記ロボットアプリケーション管理装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置及び少なくとも一つのコンピュータ装置とを備えるシステムであって、前記システムの備える装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理する手段と、前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させる手段とを備える。
　本発明の原理に従うまた別の態様は、複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理方法であって、前記ロボットアプリケーション管理方法を実行する装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置と少なくとも一つのコンピュータ装置とを含む装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理し、前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させる。
　本発明の原理に従うさらに別の態様は、複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理プログラムであって、前記ロボットアプリケーション管理プログラムがインストールされる装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置と少なくとも一つのコンピュータ装置とを含む装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理するためのプログラムコードと、前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させるためのプログラムコードとを備える。
　上述した本発明の原理に従う各態様において、前記複数種類の仮想コンテナには、該仮想コンテナを実行する装置としていずれの装置を選択してもよい第一の種類の仮想コンテナと、ロボット装置における物理的接続を要するために該仮想コンテナを実行する装置の選択に制約がある第二の種類の仮想コンテナとがあり、前記第一の種類の仮想コンテナと、前記第二の種類の仮想コンテナとは、疎結合で動作するものであり、前記配置は、第二の種類の仮想コンテナについては、前記制約を満たす装置を選択して行われる。
　本発明によれば、ロボットシステムの開発者や管理者が計算リソースとネットワーク環境の管理や制御を行う煩わしさを、軽減することができるとともに、例えば、物理的な制約のあるロボットシステムにおいて分散型計算システムのコンピュータリソースを最適に利用することが可能になる。
本発明の一実施形態に係るシステム（以下、「本システム」という）の構成の一例を示す図。 本システムの構成の別の例を示す図。 本システムの利用例を示す図。 本システムの実装例を示す図。 ロボットアプリケーション管理装置の通信モジュール部及び無線通信基地局提供部の動作の流れの一例を示す図。 ロボットアプリケーション管理装置の共通情報配信部の動作の流れの一例を示す図。 ロボットアプリケーション管理装置及び末端コンピュータ装置の郡実行型論理コンテナ用仮想化環境提供部の動作の流れの一例を示す図。 ロボットアプリケーション管理装置の履歴管理部の動作の流れの一例を示す図。 本システムにおいて実行する装置の選択に制約のある仮想コンテナの配置を実現するための機構の一例を示す図。 本システムにおいていずれかの装置が動作不良に陥った場合に対処する動作の一例を示す図。 本システムにおいて仮想コンテナ技術を導入した装置とそうでない装置とを混在させてロボットシステムを構成するための機構の一例を示す図。 本システムにおける仮想コンテナの配置例を示す図。
　以下、本発明の実施の形態について説明するが、以下の説明は、本発明の具体例を示すものであって、本発明の範囲を限定するものではない。
　上述した本発明の原理に従う態様において、前記ロボットアプリケーション管理装置と外部ネットワークを介して接続される少なくとも一つのクラウドサービス装置を、前記クラスタを構成する装置群に含めるようにしてもよい。
　これにより、ローカルエリアネットワーク内でシステムを構成する複数のコンピュータ装置（ロボット装置も、ロボットアプリケーション管理装置も、コンピュータリソースを有する装置である）に加えて、外部ネットワークの向こう側にあるクラウドサービス装置をも束ねて、一つのクラスタとして扱うことが可能になり、コンピュータリソースの最適な利用をさらに進化させることができる。例えば、レスポンスの速さが要求されるような仕事を行う仮想コンテナは、ローカルエリアネットワーク内の装置に配置し、大量のデータを解析するような仕事を行う仮想コンテナは、クラウドサービス装置に配置することが可能である。
　上述した本発明の原理に従う態様において、前記複数の仮想コンテナには、所定以上の処理能力又は記憶容量を要するために該仮想コンテナを実行する装置の選択に別の制約がある第三の種類の仮想コンテナがあり、前記第三の種類の仮想コンテナと、前記第一及び第二の種類の仮想コンテナとは、疎結合で動作するものであり、前記配置は、第三の種類の仮想コンテナについては、前記別の制約を満たす装置を選択して行われるものであってもよい。
　これにより、例えば、ロボット装置に搭載されたモータやセンサ等の物理的な要素との直接接続（例えば、ＵＳＢ接続等）を要する仕事を行う仮想コンテナは、そのロボット装置に配置する一方で、特定の性能を有するコンピュータ装置上での動作を要する仕事を行う仮想コンテナは、そのようなコンピュータ装置（例えば、ＧＰＵ（Ｇｒａｐｈｉｃｓ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）を有する装置や、潤沢なメモリを有する装置等）に配置することが可能になる。
　なお、これらの仮想コンテナ間の疎結合は、例えば、ＲＯＳのトピック通信モデルによって、容易に実現することができる。
　上述した本発明の原理に従う態様において、前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させるための手順を、記憶する手段をさらに備えるようにしてもよい。
　これにより、例えば、ロボットシステムを構成する各装置に、手動でログインして個別にプロセスの実行やメンテナンスを行う作業から、ロボットシステムの開発者や管理者を解放することが可能になる。
　上述した本発明の原理に従う態様において、前記クラスタを構成する装置群の各装置がどの制約を満たすものかを示す情報を記憶する手段をさらに備えるようにしてもよい。
　これにより、例えば、上述した手順として、実行する装置の選択に制約がある仮想コンテナについては、その制約を満たす装置にその仮想コンテナを配置して起動させるように記述した手順を記憶しておき、その手順を実行する際に、各装置がどの制約を満たすものかを示す情報を参照することによって、仮想コンテナを配置する装置を自動的に選択することが可能になる。
　上述した本発明の原理に従う態様において、前記複数種類の仮想コンテナのそれぞれが配置される装置が該仮想コンテナの実行可能なプログラムを取得できるように、該実行可能なプログラムを記憶する手段をさらに備えるようにしてもよい。
　これにより、例えば、上述した手順によって自装置に対して指定された仮想コンテナの実体である実行可能なプログラム（イメージと呼ばれることもある）を、各装置が自動的に入手することが可能になり、ロボットシステムの開発者や管理者が各装置に手動でログインすることなく、各仮想コンテナの配置と起動ができるようになる。
　上述した本発明の原理に従う態様において、前記仮想コンテナの実行可能なプログラムは、前記ロボットアプリケーションを構成するアプリケーションプログラムとＯＳとがパッケージ化されたものであり、各装置のホストＯＳ上に仮想コンテナごとに分離した空間が形成され、該ホストＯＳからはプロセスとして見えるように実行されるものであるようにしてもよい。
　このように、本発明の原理に従う態様では、コンテナ型の仮想化技術を、ロボットシステムにおいて利用することが可能になる。
　なお、仮想コンテナは、既存の仮想コンテナランタイムの技術を利用して実現することができる。仮想コンテナランタイムとは、コンテナ管理ソフトウェア本体であり、ソフトウェアコンテナ内のアプリケーション（これを仮想コンテナと呼ぶ）のデプロイメント（コンピュータに配置して起動させること）を自動化することが可能なものである。本発明の原理に従う態様においては、複数種類の仮想コンテナを連携させながら実行することにより、一つのロボットアプリケーションが実行されるため、一つの仮想コンテナに相当するソフトウェアコンテナ内のアプリケーションは、ロボットアプリケーションの一部の機能を実現するものとなる。
　また、クラスタを構成する複数の装置に対する各仮想コンテナの配置及び起動は、既存の仮想コンテナオーケストレーションツールの技術を利用して実現することができる。仮想コンテナオーケストレーションツールとは、複数のコンピュータ装置（ノードあるいはホストとも呼ばれる）に対する仮想コンテナの設定、構築、配備を自動化することが可能なものであり、これによって、プロセスの死活監視、自動再起動、アップデート配信の簡略化等を実現することも可能である。本発明の原理に従う態様においては、例えば、ラベル等を使って自動配置先につき所定程度の制約を設けることができるツールの技術を利用することが望ましい。
　上述した仮想コンテナランタイムの技術としては、例えば、Ｄｏｃｋｅｒ社の「Ｄｏｃｋｅｒ」、ＣｏｒｅＯＳ社の「Ｒｋｔ」、Ｌｉｎｕｘ（登録商標）　Ｆｏｕｎｄａｔｉｏｎの「ＬＸＣ」、Ｍｉｃｒｏｓｏｆｔ社の「Ｈｙｐｅｒ－Ｖ」等を利用することができる。
　上述した仮想コンテナオーケストレーションツールの技術としては、例えば、「Ｄｏｃｋｅｒ　Ｓｗａｒｍ」（非特許文献２を参照）、「Ｋｕｂｅｒｎｅｔｅｓ」（https://kubernetes.io/を参照）、「Ｒａｎｃｈｅｒ」（https://rancher.com/を参照）、「ｆｌｅｅｔ」（https://coreos.com/fleet/docs/latest/launching-containers-fleet.htmlを参照）等を利用することができる。
　上述した本発明の原理に従う態様において、前記クラスタを構成する装置群のいずれかが動作不良に陥った場合に、該動作不良に陥った装置で起動されている仮想コンテナを、前記クラスタを構成する他の装置に再配置して起動させることにより、前記ロボットアプリケーションの実行を継続する手段をさらに備え、前記再配置は、前記実行する装置の選択に制約がある仮想コンテナについては、該制約を満たす装置を選択して行われるものであり、該制約を満たす装置が前記動作不良に陥った装置以外に存在しない場合には、前記ロボットアプリケーションの実行を停止するようにしてもよい。
　これにより、物理的な制約のあるロボットシステムにおいて分散型計算システムのコンピュータリソースを最適に利用しながら、クラスタを構成する一部の装置が動作不良（例えば、コンピュータ装置自体の故障や、ロボット装置のローカルエリアネットワークの通信範囲内からの離脱や、クラウドサービス装置の外部ネットワークを介した通信の途絶等により、当該装置が正常に機能しているという確認がとれなくなった状態）に陥った場合に、その装置上の仮想コンテナが他の装置上に再配置してもよいものであれば自動的にロボットシステムを動作させ続け、再配置不可のものであれば自動的にロボットシステムを停止させることが可能になる。
　上述した本発明の原理に従う態様において、前記実行する装置の選択に制約がある仮想コンテナを、ステートレスなものとし、前記クラスタを構成する装置群のいずれかが動作不良に陥り、前記ロボットアプリケーションの実行が停止された場合に、該動作不良に陥った装置又はそれに代わる装置が前記クラスタを構成する装置として復活したら、前記仮想コンテナの配置及び起動を行うことにより、前記ロボットアプリケーションの実行を再開するようにしてもよい。
　これにより、例えば、ロボット装置がローカルエリアネットワークの通信範囲内から離脱して、ロボットシステムが停止した場合に、当該ロボット装置が再びローカルエリアネットワークの通信範囲内に入ったら、自動的にロボットシステムを再開するようなことが可能になる。別の例として、ロボット装置が故障して、ロボットシステムが停止した場合に、代わりのロボット装置をローカルエリアネットワークの通信範囲内で立ち上げることにより、自動的にロボットシステムを再開するようなことも可能になる。
　上述した本発明の原理に従う態様において、前記仮想コンテナが起動されている装置が前記クラスタを構成する装置でなくなった場合に、該仮想コンテナを停止させる手段と、前記仮想コンテナを停止させるための手順を、記憶する手段とをさらに備えるようにしてもよい。
　これにより、例えば、ある条件が満たされたら仮想コンテナを停止させるということを自動的に行えるようになり、クラスタを構成する一部の装置が動作不良のためにクラスタから外れる場合に、そのクラスタに対応する当該装置上の仮想コンテナを自動的に停止する（さらに仮想コンテナを当該装置から廃棄する）ことによって、安全性を高めることが可能になる。
　上述した本発明の原理に従う態様において、前記複数種類の仮想コンテナのそれぞれがどの装置に配置され、起動中であるか停止中であるかを含めどのような状態であるかを示す情報を収集し、ユーザに表示するサービス又は履歴を記憶するサービスの少なくとも一方へ送信する手段をさらに備えるようにしてもよい。
　これにより、例えば、ロボットアプリケーション管理装置にローカルエリアネットワーク又は外部ネットワークを介して接続される端末において、ロボットシステムを構成する各装置の状態が一括して表示され、ロボットシステムの開発者や管理者（ユーザ）の負担を軽減することが可能になる。また、ロボットアプリケーション管理装置にローカルエリアネットワーク又は外部ネットワークを介して接続されるストレージにおいて、ロボットシステムに対して行った制御やロボットシステムの動作の詳細ログを保存しておくことが可能になる。これらの端末やストレージは、クラウドを構成しない装置としてよい。
　上述した本発明の原理に従う態様において、前記クラスタを構成する各装置における各仮想コンテナが前記ローカルネットワークを介して通信できるように、ネットワーク接続を支援する手段をさらに備え、該手段の少なくとも一部は、前記複数種類の仮想コンテナのうちの一つが自装置に配置されて起動されることにより備えられるものであってもよい。
　これにより、例えば、ロボットシステムを構成する各装置に、手動でネットワーク接続のための設定（時刻同期、アドレス付与、名前解決等）をする作業から、ロボットシステムの開発者や管理者を解放することが可能になる。この設定が行われた各装置上の仮想コンテナ同士の通信については、仮想コンテナランタイム／仮想コンテナオーケストレーションツールの技術により支援してもよい。
　上述した本発明の原理に従う態様において、前記少なくとも一つのロボット装置は、移動するロボット装置を含み、前記ローカルネットワークのうち少なくとも前記移動するロボット装置への接続部分は、無線で構成されるものであり、前記無線接続のためのアクセスポイント機能又はマルチホップ機能の少なくとも一方をさらに備えるようにしてもよい。
　このアクセスポイント機能により、移動ロボットと各種装置（センサやコンピュータ）を相互に接続してロボットシステムを構成することが可能になり、マルチホップ機能により、移動ロボットの移動範囲に合わせてフレキシブルに無線ローカルエリアネットワークを張り巡らせることが可能になる。その結果、移動ロボットは、無線の電波到達範囲を気にせずに、動き回ることができる。
　上述した本発明の原理に従う態様において、前記ロボットアプリケーション管理装置が備える手段のうちの少なくとも一部を備える少なくとも１つの副ロボットアプリケーション管理装置を、前記クラスタを構成する装置群に含めるようにしてもよい。
　これにより、主となるロボットアプリケーション管理装置がダウンしても、副ロボットアプリケーション管理装置が代替することで、ロボットシステムが動作を継続することが可能になる。また、副ロボットアプリケーション管理装置を使って、前述の無線マルチホップ機能を展開することが可能になる。さらに、ロボットシステムを複数動かす場合、主ロボットアプリケーション管理装置は共通とし、前述の無線アクセスポイント機能を有する副ロボットアプリケーション管理装置をロボットシステムごとに設置することで、それぞれのロボット装置が近傍のアクセスポイントを利用して無線通信することが可能になる。
　上述した本発明の原理に従う態様において、前記前記ロボットアプリケーション管理装置が、ローカルエリアネットワークと外部ネットワークとの境界に位置し、前記ローカルエリアネットワークに接続された各装置を前記外部ネットワークから保護する手段をさらに備えるようにしてもよい。
　これにより、ロボットシステムのためのローカルエリアネットワークを外部ネットワークから分離して、保護する（例えば、ネットワークアドレストランスレーションや、ファイアウォール等の手段を用いる）ことで、セキュリティを高めることが可能になる。例えば、前述の副ロボットアプリケーション管理装置をロボットシステムごとに設置する場合、複数のロボットシステムに共通の主ロボットアプリケーション管理装置に、このネットワーク分離保護機能を設けるとよい。
　また、このネットワーク分離保護機能を備えるロボットアプリケーション管理装置と、外部ネットワークの向こう側にあるクラウドサービス装置との間を、ＶＰＮ（Ｖｉｒｔｕａｌ　Ｐｒｉｖａｔｅ　Ｎｅｔｗｏｒｋ）を用いて接続するようにすれば、そこでもセキュリティを確保することが可能になる。もしくは、ＨＴＴＰＳやＭＱＴＴＳのような暗号化通信プロトコルを用いて通信するようにしてもよい。
　上述した本発明の原理に従う態様において、前記ロボットアプリケーション管理装置が、前記ロボットアプリケーションのために物理的環境のデータを入力するセンサをさらに備え、前記センサを制御する仮想コンテナを、前記複数種類の仮想コンテナのうちの一つとして、自装置に配置して起動させるものであってもよい。
　これにより、例えば、ロボット装置に搭載されている（移動しながらセンシングする）センサからの情報と、ロボットアプリケーション管理装置に搭載されている（ロボット装置の移動範囲の環境をセンシングする）センサからの情報と、両方を考慮したロボットシステムの制御が可能になる。前述の副ロボットアプリケーション管理装置をロボットシステムごとに設置する場合、当該副ロボットアプリケーション管理装置に、センサを設けてもよい。
　上述した本発明の原理に従う態様において、前記クラスタを構成する少なくとも一つの装置における少なくとも一つの仮想コンテナが前記ローカルネットワークを介して前記クラスタを構成しない装置と通信できるように、ネットワーク接続のためのアドレスを付与する手段をさらに備えるようにしてもよい。
　これにより、仮想コンテナ技術を導入した装置とそうでない装置とを混在させてロボットシステムを構成することができるため、ロボットシステムの開発や管理を部分的な仮想化技術の導入から始めることが可能になる。
　上述したそれぞれの態様は、異なるカテゴリの態様としたり、組み合わせて別の態様としたり、部分的に抜き出して別の態様としたりすることも可能である。例えば、上記の方法を実行するためにシステムを構成するいずれかの装置にインストールされるプログラム、上記のシステムを構成するロボットアプリケーション管理装置以外の装置、当該装置において実行される方法及びその実行のためのプログラム、既述のいずれのプログラムについても当該プログラムを記憶した記憶媒体等、それぞれが本発明の原理に従う一つの態様となり得る。
　また、上述した本発明の原理に従う態様は、実行する装置の選択に制約がある仮想コンテナの取り扱いを含んでいるが、これを含まない態様に上記に説明したそれぞれの手段等を付加したものも発明（本発明とは独立した発明）になり得るものである。
　以下には、例示として、本発明の一実施形態に係るシステム（以下、「本システム」という）について、図面を用いて説明する。以下の例においては、仮想コンテナランタイムとしてＤｏｃｋｅｒを用い、仮想コンテナオーケストレーションツールとしてＤｏｃｋｅｒ　Ｓｗａｒｍを用いる。
　図１に例示された本システムは、ロボット（センサやモータ等の物理的要素）と、ロボットシステムの開発やプログラム実行に必要なネットワーク環境構築支援およびプログラム開発・実行環境をローカルネットワーク（ＬＡＮ６００）で提供することを目的としたエッジコンピュータであるロボットアプリケーション管理装置（主）１００と、その少なくとも一部の機能を重複して担うロボットアプリケーション管理装置（副）２００と、その管理・制御対象となり得る複数コンピュータ資源（末端コンピュータ装置）３００、４００とを含んでいる。
　末端コンピュータ装置Ａ（３００）は、ロボット接続型であり、センサ３０６と駆動装置３０７を搭載している。末端コンピュータ装置Ｂ（４００）は、コンピュータ単体である。ロボットアプリケーション管理装置と末端コンピュータ装置は、仮想コンテナ技術が導入されている装置であり、それぞれが、群実行型論理コンテナ用仮想化環境提供部１０３、２０３、３０３、４０３を備えており、その上で動作する複数の仮想コンテナが連携して、一つのロボットアプリケーションを実行する（一つのロボットシステムを動作させる）。
　本システムは、仮想コンテナ技術が導入されていないＬＡＮ６００上のコンピュータ装置５００（例えば、スマートフォンやパソコン等）を収容することも可能である。ＬＡＮ６００とインターネット７００とを接続する機能は、本例では、ロボットアプリケーション管理装置（主）１００が備えている。インターネット７００を介して、仮想コンテナ技術が導入されていないコンピュータ装置（ディスプレイ／ストレージ）８００を本システムに収容することも可能である。
　インターネット７００は、外部のコンピュータ資源（図１の例ではコンピュータ装置８００）にアクセス可能な通信網であればよく、ＬＴＥ等の携帯電話網、公衆ＷｉＦｉ等でもよい。ロボットアプリケーション管理装置（主）１００は、インターネット接続部１０８（例えば、有線ＬＡＮ接続のためのネットワークインタフェースカード等）を備えており、図３の例に示すように、ブロードバンドルータ１０９を介してインターネット７００に接続することができる。
　なお、図１の例では、ロボットアプリケーション管理装置（主）１００とディスプレイ／ストレージ８００が、インターネット７００を介して接続されているが、ディスプレイ／ストレージ８００をＬＡＮ６００上に設け、本システムをＬＡＮ内に閉じて構成することも可能である。
　ロボットアプリケーション管理装置と末端コンピュータ装置と仮想コンテナ技術未導入のコンピュータ装置は、それぞれ、ＬＡＮ６００に接続するための通信モジュール部１０１、２０１、３０１、４０１、５０１を備えている。各通信モジュール部は、有線ネットワークを介して接続可能なものでもよいが、少なくとも移動するロボットに直接接続されるコンピュータ装置３００と他の装置との間については、ＷｉＦｉ等の無線ネットワークを介して接続可能なものとすることが好ましい。ＷｉＦｉは、画像、音声、点群等の大容量データを扱え、屋内に強い点でも現実的な選択肢である。
　さらに、マルチホップＷｉＦｉアクセスポイント環境を提供するためには、ロボットアプリケーション管理装置（主）１００だけでなくロボットアプリケーション管理装置（副）２００も、無線通信基地局提供部１０２、２０２（例えば、Ｗｉｒｅｌｅｓｓ　Ｄｉｓｔｒｉｂｕｔｉｏｎ　Ｓｙｓｔｅｍ（ＷＤＳ）規格準拠の無線ＬＡＮアダプタ等）を備える。ＷＤＳは、無線ＬＡＮの信号を送受信し、かつ中継することで、通信可能な範囲を広げるための機能をサポートする。これにより、電源さえあれば、移動ロボットが移動する範囲を全てＷｉＦｉネットワークでカバーすることが可能になる。
　ロボットアプリケーション管理装置（主）１００の群実行型論理コンテナ用仮想化環境提供部１０３は、仮想コンテナオーケストレーションツールのマネージャ機能（Ｄｏｃｋｅｒ　Ｓｗａｒｍ　Ｍａｎａｇｅｒ）を含み、操作手順台帳記憶部１０５を参照して、ロボットシステムを構成する装置群をクラスタとして束ねて（クラスタリングして）管理する。管理される側の各装置内の群実行型論理コンテナ用仮想化環境提供部３０３、３０４は、仮想コンテナオーケストレーションツールのエージェント機能（Ｄｏｃｋｅｒ　Ｓｗａｒｍ　Ａｇｅｎｔ）を含んでいる。
　ロボットアプリケーション管理装置（副）２００の群実行型論理コンテナ用仮想化環境提供部２０３は、仮想コンテナオーケストレーションツールのマネージャ機能を含み、ロボットアプリケーション管理装置（主）１００と機能分担した上で、操作手順台帳記憶部２０５を参照して、ロボットシステムを構成する装置群の管理を行う。ロボットアプリケーション管理装置のコンピュータ資源を、末端コンピュータ装置のコンピュータ資源と同様にロボットアプリケーションの実行に利用することも可能であり、その場合、群実行型論理コンテナ用仮想化環境提供部１０３、１０４は、仮想コンテナオーケストレーションツールのエージェント機能も含む。
　ロボットアプリケーション管理装置（主）１００の群実行型論理コンテナ用仮想化環境提供部１０３は、イメージ台帳記憶部（Ｄｏｃｋｅｒレジストリ）１０４も備えており、ロボットシステムを構成する各装置が動作させる仮想コンテナの実体である実行可能なプログラム（Ｄｏｃｋｅｒイメージ）を管理する。ロボットアプリケーション管理装置（副）２００の群実行型論理コンテナ用仮想化環境提供部２０３が、イメージ台帳の全部又は一部を記憶するようにしてもよい。
　ロボットアプリケーション管理装置（主）１００の群実行型論理コンテナ用仮想化環境提供部１０３によって、各仮想コンテナの標準出力・標準エラー出力を一箇所に収集することが可能になると共に、一つのコマンドだけで、設定ファイル（操作手順台帳）に記述されたとおりに、ホストマシン（クラスタを構成する装置）を跨いで複数の仮想コンテナを起動・配置・停止することが可能になる。また、後述するように、ステートレスなアプリケーションとすることで、各サービスのスケールアップ・スケールダウンが容易に行えるようになる。
　また、ロボットアプリケーション管理装置（主）１００の状態表示部１０７は、群実行型論理コンテナ用仮想化環境提供部１０３の働きにより、ホストマシン（クラスタを構成する装置）を跨いで各仮想コンテナで動いているサービスの稼動状態を一覧として取得することが可能になる。この一覧は、ロボットシステムのユーザ等が、ディスプレイ８００等で確認することができる。
　このように、ロボットアプリケーション管理装置を設けることで、中央集権的に、複数のホストマシンに分散させた仮想コンテナを扱えるようになる。そのため、運用／監視面での最適化が期待できる。
　さらに、ロボットアプリケーション管理装置（主）１００が、共通情報配信部１０６（図示しない共通情報台帳記憶部を含む）を備えることにより、ロボットシステムのためにネットワーク環境を構築してもよい。このネットワーク環境の構築の少なくとも一部は、ロボットアプリケーション管理装置（主）１００又はクラスタリングされた他の装置上で、仮想コンテナによって実行することも可能である。
　そのように行われるネットワーク環境の構築には、例えば、時刻同期（ネットワークタイムプロトコルを用いて、自動時刻合わせを行う）、名前解決（ドメインネームシステムを用いて、ホスト名によるアドレス解決を行う）、アドレス付与（ダイナミックホストコンフィギュレーションプロトコル等を用いて、ＩＰアドレスを自動的に付与する）、ディレクトリサービス（ライトウェイトディレクトリアクセスプロトコル等を用いて、アカウント情報の集中管理を行う）等が含まれ得る。そうすると、ロボットアプリケーション管理装置上の仮想コンテナが実行するネットワークアプリケーションにより、例えば、パブリックなＮＴＰサーバへの接続を制限している企業ネットワークにおいてロボットシステムを構築する場合でも、全コンピュータの時刻合わせ等が自動的に行えることになる。
　また、ロボットアプリケーション管理装置（主）又は（副）が、センサ２０６を備えてもよい。センサ２０６は、例えば、環境センサ、カメラ等の情報収集デバイスであり、複数備えてもよい。これらのセンサは、それぞれのために動作する仮想コンテナにより制御されるようにすることができ、それらの仮想コンテナが連携することで、センサネットワークを構成することもできる。
　ロボットアプリケーション管理装置には、他にも、ロボットアプリケーション開発環境を備えるようにしてもよい。また、移動するロボットの位置情報を検出する機構や、地図を配信するサーバ機能を備えるようにしてもよい。
　上述したロボットアプリケーション管理装置は、ＲＯＳが使われる移動ロボットをメインターゲットとすることが可能である。その際、ＷｉＦｉアクセスポイントとして振る舞うのと渾然一体で、ネットワーク・仮想化技術をベースとした環境も提供することができる。
　図２に例示された本システムでは、ロボットアプリケーション管理装置（主）１００が、インターネット７００を介して、群実行型論理コンテナ用仮想化環境提供部９０３を備えるクラウドサービス装置（例えば、ＩａａＳ）９００に接続し、クラウドサービス装置９００もロボットシステムを構成する装置群の一つとして、仮想コンテナを動作させる。
　なお、仮想コンテナ技術を導入していない一般的なクラウドサービス（例えば、ＰａａＳ、ＳａａＳ等）を、インターネット７００を介してロボットアプリケーション管理装置（主）１００に接続し、例えば、履歴管理部１０７が通信モジュール１０１から収集したロボットシステムの制御や動作状態に関する情報の全部又は一部を、クラウドサービスが提供するストレージ８００に保存するようにしてもよい。
　図２の例では、ロボットアプリケーション管理装置（主）１００は、クラウドサービスとロボットの中間で、エッジ機器として働く。ロボットアプリケーション管理装置（主）１００は、ロボットシステムのためのローカルエリアネットワークを、それ以外のネットワークから分離した環境として構築することができるから、レスポンスの速さや通信のセキュリティが要求されるサービスを動かす仮想コンテナは、ローカルエリアネットワーク内に配置し、それ以外のサービスを動かす仮想コンテナは、クラウドサービス装置に配置する等、コンピュータ資源の最適な配分が可能になる。
　ロボットアプリケーション管理装置（主）１００のインターネット接続部１０８と、クラウドサービス装置９００のインターネット接続部９０８が、ＶＰＮゲートウェイの機能を有するようにすれば、外部のコンピュータ資源を使っても、通信のセキュリティを確保することが可能である。
　図２の例では、ロボットアプリケーション管理装置（副）２００を設けていないが、これを設けることも勿論可能である。逆に、図１の例で、ロボットアプリケーション管理装置（副）２００を設けない構成とすることも可能である。
　図３は、本システムを利用して、ロボット装置１（３００－１）用のロボットシステムＡと、ロボット装置２（３００－２）用のロボットシステムＢとが稼働している例を示している。図中、ＷｉＦｉ（ＡＰ）は無線アクセスポイントを、ＷｉＦｉ（ＣＬ）は無線クライアントを意味する。ロボット装置２は、最近傍のアクセスポイントであるロボットアプリケーション管理装置（副）２００－２と無線通信するが、ロボットアプリケーション管理装置（副）２００－１のマルチホップ機能によって、ＷｉＦｉ電波の到達範囲外であるロボットアプリケーション管理装置（主）１００とも無線通信できるようになっている。
　ここで、例えば、ロボットシステムＡは、ロボットアプリケーション管理装置（主）１００と、ロボットアプリケーション管理装置（副）２００－１と、ロボット装置３００－１と、図示しないコンピュータ装置４００とで構成し、ロボットシステムＢは、ロボットアプリケーション管理装置（主）１００と、ロボットアプリケーション管理装置（副）２００－２と、ロボット装置３００－２と、図示しないコンピュータ装置４００とで構成するといったこと（つまり、動作対象となるホストマシンをクラスタごとに指定すること）が可能である。
　ロボットシステムＡとロボットシステムＢが、同じ動作をするサービスロボットである場合も、ロボットシステムＡ用の仮想コンテナ群と、ロボットシステムＢ用の仮想コンテナ群は別々に生成され、例えば、コンピュータ装置４００で同じサービスをする仮想コンテナがロボットシステムＡ用とロボットシステムＢ用に２つ動作するということになる。
　図４は、Ｄｏｃｋｅｒの技術を利用して本システムを実装する場合の一例を示している。ロボットアプリケーション管理装置（「ＲＤＢ」と表記することがある）１００／２００とそれ以外のコンピュータ装置４００とロボット装置３００という複数のコンピュータ資源上に、仮想コンテナランタイムである「Ｄｏｃｋｅｒ」と仮想コンテナオーケストレーションツールである「Ｄｏｃｋｅｒ　Ｓｗａｒｍ」を用いた仮想コンテナによるクラスタリング環境を構築し、ロボット用仮想コンテナ（図中の「ＲＯＳ　Ｃｏｎｔａｉｎｅｒ　Ｆｏｒ　ＲＤＢ－ＡＰＰＳ」）を動かし、ロボットシステムを構築する。
　図４の例では、クラスタを構成する複数のコンピュータ装置（ホストマシン）のそれぞれの実行装置は、「Ｄｏｃｋｅｒ」「ＲＤＢ－ＡＰＰＳ」「ＲＯＳ　Ｃｏｎｔａｉｎｅｒ　Ｆｏｒ　ＲＤＢ－ＡＰＰＳ」を含んでいる。「ＲＤＢ－ＡＰＰＳ」は、各種ロボット向けに仮想コンテナを個別操作するために「Ｄｏｃｋｅｒ」の上位層で動作するデーモンである。「Ｄｏｃｋｅｒ」及び「ＲＤＢ－ＡＰＰＳ」がインストールされたホストマシンは、図１～２で説明した「群実行型論理コンテナ用仮想化環境提供部」を備えることになる。
　ロボットアプリケーション管理装置として働くコンピュータ装置は、「Ｄｏｃｋｅｒ」及び「ＲＤＢ－ＡＰＰＳ」上に、「ＲＯＳ　Ｃｏｎｔａｉｎｅｒ　Ｆｏｒ　ＲＤＢ－ＡＰＰＳ」として、上述したネットワーク環境の構築を行う（ＮＴＰ、ＤＮＳ、ＤＨＣＰ等の機能を有する）共通情報配信部１０６や、ロボット環境のヘルスチェックを行う機能部や、ロボットの稼働状況に関する情報を収集してディスプレイ／ストレージへ送信する状態表示部／履歴管理部１０７や、ロボットアプリケーション開発環境を提供する機能部等を備えるようにしてもよい。これにより、ロボットアプリケーション管理装置をインターネットとサービスロボットの間に設置するだけで、ロボット専用のローカルエリアネットワークと開発支援環境を構築することが可能になる。
　各ホストマシンにインストールされる「ＲＤＢ－ＡＰＰＳ」は、上述した機能の他に、ロボットハードウェアのドライバ管理等を担うこともできる。例えば、「ＲＤＢ－ＡＰＰＳ」は、そのホストマシン上で仮想コンテナを起動する際に、その仮想コンテナがモータ（アクチュエータ）や各種センサ等のハードウェアに紐づくものであれば、そのハードウェアのバージョンを指定して、ハードウェアを動かすためのドライバをホストマシン上にセットアップすることができるようにする。これにより、デバイスファイルに直接アクセスするため、ハイパーバイザー型と比べてハードウェアとの接続で問題が起こりづらいというコンテナ型仮想化の利点も生かされる。
　図４の例において、「ＲＯＳ　Ｃｏｎｔａｉｎｅｒ　Ｆｏｒ　ＲＤＢ－ＡＰＰＳ」（図１～２の仮想コンテナ）は、少なくともその一部を、ロボットシステムのユーザの実装によって作成することができる。ロボットアプリケーション管理装置上のＤｏｃｋｅｒレジストリには、「ＲＤＢ－ＡＰＰＳ」に対応した標準の「ＲＯＳ　Ｃｏｎｔａｉｎｅｒ」が配置され、ロボットシステムのユーザは、この標準ＲＯＳコンテナをベースに、Ｄｏｃｋｅｒコンテナを中心としたロボットシステム開発を実施することができる。Ｄｏｃｋｅｒレジストリはまた、完全な同一ＲＯＳ環境をいくつでも瞬時に複製することを可能にする。
　上述したロボットシステム開発においては、ＯＳやミドルウェアのセットアップが完了したＤｏｃｋｅｒコンテナイメージを、Ｄｏｃｋｅｒレジストリに保存しておき、ロボットアプリケーション開発時に、このコンテナイメージを元に差分のみを実装することで、修正作業の効率化が可能になる。また、一つのＤｏｃｋｅｒイメージにつき一つのパッケージとすることで、環境の汚染を防ぐことが可能である。
　より詳細には、まず、仮想コンテナイメージ台帳記憶部１０４（「Ｄｏｃｋｅｒレジストリ」）に保存されているテンプレートイメージを利用し、テンプレートイメージからの差分のみを、仮想コンテナ作成手順台帳（「Ｄｏｃｋｅｒｆｉｌｅ」とも呼ばれる）に記述する。そして、このＤｏｃｋｅｒｆｉｌｅを用いて、仮想コンテナイメージを作成するコマンドを実行し、新たに作成されたイメージに名前をつけて、Ｄｏｋｅｒレジストリに保存する。
　クラスタを構成する各コンピュータ装置（ロボットアプリケーション管理装置と、それ以外のローカルエリアネットワーク内に設置されたもしくはクラウド上に設置されたコンピュータ装置）上の各Ｄｏｃｋｅｒコンテナ（図１～２の仮想コンテナ）は、ロボットアプリケーション管理装置上に常駐するアプリケーションである「Ｄｏｃｋｅｒ　Ｓｗａｒｍ　Ｍａｎａｇｅｒ」（「群実行型論理コンテナ用仮想化環境提供部」１０３／２０３に含まれる）により統合監視される。
　各コンピュータ装置には、それぞれ役割を明確にするためのラベルが付与され、各コンピュータ装置の「群実行型論理コンテナ用仮想化環境提供部」（各コンピュータ装置に常駐するアプリケーションである「Ｄｏｃｋｅｒ　Ｓｗａｒｍ　Ａｇｅｎｔ」を含む）が、付与されたラベルを記憶している。「Ｄｏｃｋｅｒ　Ｓｗａｒｍ　Ｍａｎａｇｅｒ」は、各コンピュータ装置に付与されたラベルを参照して、各仮想コンテナの実行に適したラベルを有するコンピュータ装置（「Ｄｏｃｋｅｒ　Ｓｗａｒｍ　Ａｇｅｎｔ」）を選択し、タスク割当を行う。
　これにより、各コンピュータ装置（ノード）や各仮想コンテナ（プロセス）の起動・監視、そこから出る標準出力を、ロボットアプリケーション管理装置において一元的に扱うことが可能になる。よって、ロボットシステムのユーザは、関係するコンピュータ装置がどんなに増えても、あたかも１台のように操ることができる。
　なお、ここでは、ロボットアプリケーション管理装置がマネージャになる例を説明しているが、クラスタを構成する他のコンピュータ装置がマネージャになることも可能である。その場合、各コンピュータ装置がクラスタに参加する際に、自装置が「Ｄｏｃｋｅｒ　Ｓｗａｒｍ　Ｍａｎｅｇｅｒ」として働くのか「Ｄｏｃｋｅｒ　Ｓｗａｒｍ　Ａｇｅｎｔ」として働くのかを選択する。どちらを選択すべきかは、各コンピュータ装置の「郡実行型論理コンテナ用仮想化環境提供部」が記憶している。
　さらには、ロボットアプリケーション管理装置を介し、ＶＰＮ、ＨＴＴＰＳ、ＭＱＴＴ等の各プロトコルを使って、ロボットに有用なクラウドサービスが利用できる。例えば、ロボット動作に必要なＳａａＳ（Ｖｉｓｉｏｎ　ＡＰＩ、Ｖｏｉｃｅ　ＡＰＩ、機械学習等のサービス）を利用することが可能になる。
　上記のクラウドサービスとして提供されるデータ保全性や可用性の高いストレージ８００上に、ｒｏｓｂａｇ等のダンプデータを保存することも可能である。収集したデータから、ロボット動作の管理に必要な各種データを抽出（フィルタリング）して、保存するようにしてもよい。
　なお、ロボットアプリケーション管理装置は、Ｄｏｃｋｅｒコンテナをベースとしたロボットシステム開発を強制するものではなく、従来のＲＯＳ開発手法を用いる場合であっても、ロボットアプリケーション管理装置の提供する各種ネットワークインフラ機能等の多くの利便性を享受することができる。また、一部機能のみをＤｏｃｋｅｒコンテナ化することも可能であり、ロボットシステムのユーザの都合に応じて使い分けることができる。
　図５は、ロボットアプリケーション管理装置１００／２００の無線通信基地局提供部１０２／２０２（ＷｉＦｉアクセスポイント）及び通信モジュール部２０１（ＷｉＦｉクライアント）が、図３で例示したように、マルチホップ機能によってＷｉＦｉ電波の到達範囲を拡張していくための動作の流れの一例を示している。
　図６は、ロボットアプリケーション管理装置１００の共通情報配信部１０６（もしくはネットワーク環境構築を実行する仮想コンテナ）と、ロボットアプリケーション管理装置２００及び末端コンピュータ装置３００／４００の通信モジュール部２０１、３０１、４０１が協働して、クラスタを構成する複数のコンピュータ装置がローカルエリアネットワークを介して通信できるようにするための動作の流れの一例を示している。
　図７は、Ｄｏｃｋｅｒの技術を利用して本システムを実装する場合の動作の流れの一例を示している。本例では、ロボットアプリケーション管理装置１００／２００及び末端コンピュータ装置３００／４００／９００の郡実行型論理コンテナ用仮想化環境提供部１０３、２０３、３０３、４０３、９０３が、一つ又は複数のロボットシステムを実現する一つのクラスタを構成し（クラスタを構成する装置群の情報も「郡実行型論理コンテナ用仮想化環境提供部」に記憶されている）、ロボットアプリケーション管理装置１００／２００上でマネージャが動作し、複数のエージェント上の各Ｄｏｃｋｅｒコンテナをｃｒｅａｔｅ（Ｓ７２）もしくはｄｅｓｔｒｏｙ（Ｓ７６）する。
　各コンピュータ装置上での各Ｄｏｃｋｅｒコンテナのデプロイ（配置及び起動の指示）は、仮想コンテナ操作手順台帳記憶部１０５に記憶された操作手順（例えば、ｙｍｌ記述）を読み込んで、マネージャが行う（Ｓ７１）。この「Ｄｏｃｋｅｒ　Ｓｗａｒｍ　Ｍａｎａｇｅｒ」によって、配下の（同一クラスタに属する）「Ｄｏｃｋｅｒ　Ｓｗａｒｍ　Ａｇｅｎｔ」のコンピュータ資源が、ホストマシンを超えて監視（プーリング）され、その上で、仮想コンテナの配置が透過的にマネージメントされる（Ｓ７３）。よって、クラスタに属するある装置が離脱したとき（Ｓ７５）、その装置で稼働していた仮想コンテナのうち、他の装置で継続稼働可能なものについては、移動先の装置への再配置及び起動が行われる。その際、移動元の装置で稼働していた仮想コンテナは、停止され、必要に応じて廃棄される。
　図８は、Ｄｏｃｋｅｒ技術を利用して本システムを実装する場合の、ロボットアプリケーション管理装置１００の履歴管理部１０７の動作の流れの一例を示している。なお、ロボットアプリケーション管理装置１００の状態表示部１０７の動作例については、図７に示されている（Ｓ７４）。
　本システムでは、仮想コンテナ技術によるクラスタリング環境下で、何らかの制約がある装置（ロボット等）を含んでいた場合でも、コンピュータ資源を最適に利用するための設計指針に合わせた実装を可能にする機能を提供する。
　図９は、Ｄｏｃｋｅｒの技術を利用して本システムを実装する場合に、実行する装置の選択に制約のある仮想コンテナの配置を実現するための機構の一例を示している。
　「Ｄｏｃｋｅｒ　Ｓｗａｒｍ　Ｍａｎａｇｅｒ」のデフォルトの動き（アプリケーションのデプロイ自動化ツール）では、コンピュータ資源は透過的に扱われるため、仮想コンテナを実行するホストコンピュータは、マネージャが最適と判断したものが選択される。
　このとき、以下の場合には、該当する仮想コンテナを、デフォルトで選択されるホストコンピュータに配置するのではなく、意図したホストコンピュータに配置する。
　１．物理的接続（ＵＳＢ接続等）を伴うアプリケーションの仮想コンテナ。
　２．ＧＰＵが必要であったり潤沢なメモリが必要であったりと、特定機能を有するコンピュータ資源上での動作が必要なアプリケーションの仮想コンテナ。
　このように意図したホストコンピュータ上に仮想コンテナを配置するには、図９（ａ）に例示すように、ラベル機能を利用する。「Ｄｏｃｋｅｒ　Ｓｗａｒｍ」では、各エージェント（ノード）に、予めラベルを付与しておく（「群実行型論理コンテナ用仮想化環境提供部」に、クラスタセットアップ時に記憶する）。図中では、「environment」というラベル項目に対して「dev，test，prod」というラベルのいずれかが、「storage」というラベル項目に対して「disk，ssd」というラベルのいずれかが付与されている。図示しないが、エッジ機器（上記の特定機能を有するコンピュータ資源としての別の例）であるか否かというラベルが指定される場合もある。
　そして、アプリケーション実行時には、図９（ｂ）に例示されたｙｍｌ記述を参照して、仮想コンテナがデプロイされる。ｙｍｌ記述には、実行ノードに関するラベルの定義等が記述されており、「service/db/deploy/placement/constraints/node.labels.storage」で指定したラベルと合致するエージェントのみ（この場合「ssd」）が、その仮想コンテナが動作し得るホストマシンとなる。図９（ａ）では、５台存在するエージェントのうち３台がこの条件を満たすホストマシンとなっており、これら３台のうちどれかにのみ「db」というサービスの仮想コンテナがデプロイされる。これによって、動作するホストマシンをコントロールする（特定のノードでのみ動作するようにする）ことが可能となる。
　ロボットシステムに多く存在する物理的接続の制約の影響範囲を最小限に押さえ込むには、物理的接続の制約がある仮想コンテナを、状態を持たない（ステートレスである）ように作成する（例えば、状態の保持が必要な場合には、仮想コンテナの外部に持たせる等）ことが好ましい。また、ロボットには搭載不可能な（例えば、重量や大容量電源が必要な）コンピュータ資源を分離し、ロボット上のコンピュータ資源の利用は必要最小限に留めることも、ロボットシステムにおける仮想コンテナを作成する際にとるべき設計思想となり得る。
　図１０は、Ｄｏｃｋｅｒの技術を利用して本システムを実装する場合に、クラスタを構成するいずれかの装置（ホストマシン）が動作不良に陥ったら（例えば、「Ｄｏｃｋｅｒ　Ｓｗａｒｍ　Ｍａｎａｇｅｒ」のハートビートが消失したら）、本システムがそれに対処するためにとる動作の一例を示している。これにより、動作不良に陥ったノードで稼働していた仮想コンテナの再起動、終了オプションの指定、異なるホストマシンでの動作不良に陥ったノードの再起動等が可能になる。
　まず、動作不良に陥ったノードで稼働していた仮想コンテナについて、定義されているラベルと合致するエージェントが１つしか存在しない場合は（Ｓ９０Ｙｅｓ）、該当のエージェントが回復するまでシステム復帰は不可能である（Ｓ９３）。この場合は、図７における仮想コンテナの停止や廃棄（Ｓ７６）を行うようにしてもよい。
　但し、この処分対象として割り当てられる仮想コンテナを、状態を持たない（ステートレスな）ものとすることで、エージェントの回復後すぐさま、システムの復帰が実行できる。つまり、「制約に依存する部分」は動作に必要な最小単位で構成すると共に、「制約に依存する部分」と「制約に依存しない部分」は疎結合で動作するという設計指針を守ることにより、少ないダウンタイムでのシステム復帰が可能になる。
　一方、動作不良に陥ったノードで稼働していた仮想コンテナについて、定義されているラベルと合致するエージェントが２つ以上存在する場合は（Ｓ９０Ｎｏ）、「Ｄｏｃｋｅｒ　Ｓｗａｒｍ」の働きにより、当該仮想コンテナはすぐさま、別のエージェント上で起動することができ（Ｓ９１）、ロボットシステムが復帰する（Ｓ９２）。よって、画像処理や動作計画など、どこでも実行できる処理については、どのエージェント上でも動作するようにしておくことで、あるホストマシンがダウンしても、他の既にクラスタを構成しているホストマシンで、プロセスが自動的に再起動されるようになる。
　但し、見かけ上はすぐに復旧できても、仮想コンテナが状態を持っている（ステートフルな）ものであると、状態がリセットされてしまうことがある。その場合も、状態を仮想コンテナ外部で保持するといった作りとすることで、ダウンタイムのないシステムを実現することが可能である。
　クラスタを構成するいずれかの装置が、動作不良によりクラスタから離脱することは、それぞれの装置にインストールされる「ＲＤＢ－ＡＰＰＳ」に常駐する機能によって、検出することができる。例えば、末端コンピュータ装置の「ＲＤＢ－ＡＰＰＳ」は、自装置の通信モジュール部を定期的に監視することにより、有効な無線基地局提供部と接続されているかどうかを定期的に確認する。そして、無線基地局との通信が途絶えて一定時間が経過する（通信断が発生する）と、ＲＤＢ－ＡＰＰＳ経由で起動した仮想コンテナ（ロボットアプリケーション）を停止する。
　一方、ロボットアプリケーション管理装置の「ＲＤＢ－ＡＰＰＳ」は、自装置の無線基地局提供部を定期的に監視することにより、クラスタを構成する装置の一覧（無線経由で接続されている装置の一覧）にある各装置が、有効に接続されているかどうかを定期的に確認する。この一覧は、「ＲＤＢ－ＡＰＰＳ」が記憶しており、定期的な監視結果に基づいて更新する（図１０のＳ９１のように、別の装置がクラスタを構成することになれば、一覧に記憶される装置が変更されることになる）。
　そして、ロボットアプリケーション管理装置の「ＲＤＢ－ＡＰＰＳ」は、ある装置との通信が途絶えて一定時間が経過する（通信断が発生する）と、例えば、図１０の動作を行う。通信断が発生した装置の代わりに利用可能な装置が存在しなければ、群実行型論理コンテナ用仮想化環境提供部が管理している操作手順台帳に基づき、仮想コンテナ（ロボットアプリケーション）を停止する。その後、上述した定期的な監視により、無線経由で接続されている装置が増加した（通信断が発生した装置もしくはその装置の代わりになる装置が改めて接続してきた）ことを検出して一定時間が経過すると、操作手順台帳に基づき、その接続してきた装置上で、仮想コンテナ（ロボットアプリケーション）を起動させる。
　ロボットシステムのように「制約があるシステム」の要求を実現しつつコンピュータ資源を最適に利用するための設計指針を要約すると、以下のようになる。
　Ａ．仮想コンテナオーケストレーションツールによって、ホストマシンを超えてコンピュータ資源がプーリングされており、その上で仮想コンテナの配置がマネージメントされていること。
　Ｂ．制約があるシステムを、「制約に依存する部分」と「制約に依存しない部分」に分離すること（「制約」とは、仮想コンテナを実行するホストマシンが制限されることを意味する）。
　Ｃ．「制約に依存する部分」は、動作に必要な最小単位で構成されること。
　Ｄ．「制約に依存する部分」と「制約に依存しない部分」は疎結合で動作すること（例えば、ＲＯＳのトピック通信モデルを利用する）。
　この設計指針を実現するための機構とそれに合わせた実装により、コンピュータ資源の一部が利用不可能な状態になっても、他のコンピュータ資源で自動的に代替することが可能になり、システムの一部がダウンしたとしても、他に与える影響を最小限にでき、他のシステムを巻き添えにする連鎖的なダウンを防ぐことができる。また、ダウンした一部のシステムも、条件を満たせば自動的に復旧することができ、制約が及ぼす影響を最小限に押さえ込むことが可能になる。
　以上では、継続的な開発・運用を実施するネットワークサービスロボット分野に本システムを適用する例を中心に説明したが、本システムは、映像・音声・３Ｄデータ等の大容量のデータを取り扱うＩｏＴ分野や、多機能なＷｉＦｉアクセスポイントとしてのネットワークインフラを提供する分野、クラウドサービスを経由したハードウェア機器のシェアリングエコノミーやそれに伴う課金システム等にも、適用することが可能である。
　各ホストマシンにインストールされる「ＲＤＢ－ＡＰＰＳ」は、上述した機能の他に、システムに部分的に仮想コンテナ技術を導入するための機能を備えることもできる。これにより、Ｄｏｃｋｅｒの取り扱いに不慣れなユーザでも、コンテナ型仮想化のスモールスタートが可能になり、Ｄｏｃｋｅｒからどうしても認識できない各種ハードウェア接続が必要な場合には、ベアメタル混在環境を許容することが可能になる。
　図１１は、Ｄｏｃｋｅｒの技術を利用して本システムを実装する場合に、本システムにおいて仮想コンテナ技術を導入した装置とそうでない装置とを混在させてシステムを構成するための機構の一例を示している。仮想コンテナ間の連携をするだけでよい仮想コンテナＢの場合は、その仮想コンテナＢを起動する際に、Ｄｏｃｋｅｒ用のプライベートＩＰアドレス（ｅｔｈ０：199.0.2.3）を割り当て、その仮想コンテナＢが配置されているノードのホストＯＳのＩＰアドレス（203.0.113.5）に変換することにより、ローカルエリアネットワークを介した通信を行う。
　これに対し、仮想コンテナ技術が導入されていない装置との連携が求められる仮想コンテナＡの場合は、その仮想コンテナＡを起動する際に、Ｄｏｃｋｅｒ用のプライベートＩＰアドレス（ｅｔｈ０：192.0.2.6）を割り当てるのに加えて、仮想コンテナＡが配置されているノードのホストＯＳと同じＬＡＮセグメントの未割当のＩＰアドレス（ｅｔｈ１：203.0.113.7）を割り当てる。ｅｔｈ０は、割り当てられたＩＰアドレスを仮想コンテナＡが配置されているノードのホストＯＳのＩＰアドレス（203.0.113.5）に変換して、ＬＡＮを介した通信を行うが、ｅｔｈ１は、割り当てられたＩＰアドレスをそのまま使って、当該ＬＡＮセグメントのデバイス（図１～２のコンピュータ装置５００）と通信する。
　上述した機構の実現のためには、例えば、「ＲＤＢ－ＡＰＰＳ」が、自装置上に配置された仮想コンテナの起動を（Ｓｗａｒｍにより自動的に起動されたかユーザにより手動で起動されたかを問わず、また、ロボットアプリケーションの実行開始時に配置されて起動されたか実行中に別の装置から再配置されて起動されたかを問わず）検知するためのアプリケーションを含んでおり、この検知と連動して、以下の処理を実行する。
　まず、仮想コンテナに付与されたフラグを参照して、ホストＯＳと同じＬＡＮセグメントのＩＰアドレスを割り付けるべき（すなわち、仮想コンテナ技術未導入の装置との連携が求められる仮想コンテナである）か否かを判別する。
　そして、割り付けるべき場合は、起動した仮想コンテナに、Ｄｏｃｋｅｒ用の仮想インタフェース（ｅｔｈ０）以外の仮想インターフェイス（ｅｔｈ＊）を割り付け、起動した仮想コンテナのホスト名をハッシュして生成した物理アドレス（ＭＡＣアドレス）を割り付け、この物理アドレスと仮想コンテナのホスト名を使ってＤＨＣＰサーバやルータに対してＩＰアドレスの発行を要求し、発行されたＩＰアドレスを仮想インターフェイス（ｅｔｈ＊）に割り付ける。ＩＰアドレスを割り付けた後に、ＬＡＮやＷＡＮへの疎通確認を実施するようにしてもよい。
　図１２は、複数カメラを搭載した画像検査用移動ロボット（自律走行によって任意の場所に移動して高解像度画像を撮影し、画像解析によって実世界の分析を実施するロボットであり、ここでは「実ロボット」という）に対して、Ｄｏｃｋｅｒの技術を利用して本システムを構築した一例を示している。
　図１２の例における分散計算システムは、ロボットアプリケーション管理装置（「ＲＤＢ」）と他３台のコンピュータによって構成される。他３台とは、実ロボットに搭載された低消費電力の「Ｃｏｍｐｕｔｅｒ＿Ａ」及び「Ｃｏｍｐｕｔｅｒ＿Ｂ」と、高性能ＣＰＵが動作して計算に特化した「Ｈｉｇｈ＿ＣＰＵ＿Ｃｏｍｐｕｔｅｒ」である。各コンピュータは、ＲＤＢによって提供されるＷｉＦｉネットワークによって相互に接続されている。
　また、各コンピュータには、ロボット向けにコンテナを個別操作するためのデーモン（「ＲＤＢ－ＡＰＰＳ」）が導入されており、各コンピュータ上では，Ｄｏｃｋｅｒコンテナ（「ＲＯＳ　Ｃｏｎｔａｉｎｅｒ　Ｆｏｒ　ＲＤＢ－ＡＰＰＳ」）が稼働する。このＤｏｃｋｅｒコンテナは、標準ＲＯＳコンテナをベースに、ＲＯＳアプリケーションがノード単位でインテグレートされたものである。そして、インテグレートされたＤｏｃｋｅｒコンテナの集合によって、ロボットサービスが提供される。
　Ｃｏｍｐｕｔｅｒ＿Ａには、ＵＳＢカメラと、移動ロボットと、スピーカーやマイク等のオーディオ機器とが接続されている。これらの物理的接続があるデバイスをＤｏｃｋｅｒコンテナから制御するために、その制御を行う仮想コンテナを、図１２の例では、「Ｄｏｃｋｅｒ　Ｃｏｍｐｏｓｅ」を利用して実装している。これは、「Ｄｏｃｋｅｒ　Ｓｗａｒｍ」を利用して、コンテナ起動時に指定されるラベル「docker-compose.yml」に応じて実行ノードを選択する機能により実装してもよい。
　このＣｏｍｐｕｔｅｒ＿Ａ上でデプロイされる仮想コンテナには、例えば、レーザ測距装置（イーサネット（登録商標）接続）動作用コンテナ「urg_node」、複数カメラ（USB接続）動作用コンテナ「usb_cam」、スピーカー・マイク（オーディオジャック接続）コンテナ「audio_common」、移動ロボット（USB接続）ドライバーコンテナ「turtlebot_bringup」がある。「urg_node」は、別のコンピュータに配置して起動してもよい仮想コンテナであるが、「usb_cam」と「audio_common」と「turtlebot_bringup」は、物理的接続があるデバイスを制御する仮想コンテナであるためＣｏｍｐｕｔｅｒ＿Ａに配置して起動する必要がある。
　実ロボットに搭載される別のコンピュータ資源であるＣｏｍｐｕｔｅｒ＿Ｂ上でデプロイされる仮想コンテナには、例えば、画面（シリアルバス接続）制御用コンテナ「ros_eye」がある。
　実ロボットとは別の場所に設けられるコンピュータ資源であるＨｉｇｈ＿ＣＰＵ＿Ｃｏｍｐｕｔｅｒにデプロイされる仮想コンテナには、例えば、移動ロボットの経路探索計算用コンテナ「amcl」、Ｃｏｍｐｕｔｅｒ＿Ａ上の「usb_cam」により撮影した動画をＨＴＭＬ５に変換するためのコンテナ「web_video_server」、移動ロボットの現在地から充電器までの経路の計算用コンテナ「kobuki_auto_docking」、ＨＴＭＬ５でＲＯＳを扱うためのコンテナ「roswww」及び「ros_bridge_server」、Ｃｏｍｐｕｔｅｒ＿Ａ上の「usb_cam」の画像を圧縮するためのコンテナ「image_transport」、移動ロボットの姿勢（クオタニオン）を計算・公表するためのコンテナ「robot_pose_publisher」、音声合成用のコンテナ「bridge_ojtalk_audio」がある。
　本例では、物理的接続の制約がある仮想コンテナを、状態を持たない（ステートレスである）ように作成するという観点から、「usb_cam」コンテナが撮影した内容の保存等は、「web_video_server」やimage_transport」等の別のコンテナが実行するようにしており、これらの別のコンテナは、物理的接続の制約がないため、Ｃｏｍｐｕｔｅｒ＿Ａ上ではなく、Ｈｉｇｈ＿ＣＰＵ＿Ｃｏｍｐｕｔｅｒにデプロイされている。
　それ自体もコンピュータ資源であるＲＤＢ上でデプロイされる仮想コンテナには、例えば、ＲＯＳ参加ノードのアドレス解決を行うためのコンテナ「roscore」がある。ＲＤＢのＣＰＵ、メモリ、ディスク等のスペックは、ＲＤＢ上で動作させるＤｏｃｋｅｒコンテナのサービスによって増減すればよく、ＲＤＢに高度な計算を実行させたい場合は、よりスペックの高いコンピュータや、ＧＰＵを搭載したコンピュータを利用するようにすればよい。
　また、ＲＤＢが、例えば、気温センサと気圧センサと湿度センサとを備えていてもよく、その場合、気温センサを制御するためのＤｏｃｋｅｒコンテナと、気圧センサを制御するためのＤｏｃｋｅｒコンテナと、湿度センサを制御するためのＤｏｃｋｅｒコンテナとが、物理的接続があるデバイスを制御する仮想コンテナであるためＲＤＢに配置して起動する必要があるものとして、ＲＤＢ上にデプロイされることになる。
　以上、本発明の実施の形態について説明したが、上述の実施形態を当業者が種々に変形、改良、応用等して実施できることは勿論であり、そのような形態も本発明の範囲に含まれる。

Claims (20)

  1. 　複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理装置であって、
    　前記ロボットアプリケーション管理装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置と少なくとも一つのコンピュータ装置とを含む装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理する手段と、
    　前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させる手段とを備え、
    　前記複数種類の仮想コンテナには、該仮想コンテナを実行する装置としていずれの装置を選択してもよい第一の種類の仮想コンテナと、ロボット装置における物理的接続を要するために該仮想コンテナを実行する装置の選択に制約がある第二の種類の仮想コンテナとがあり、
    　前記第一の種類の仮想コンテナと、前記第二の種類の仮想コンテナとは、疎結合で動作するものであり、
    　前記配置は、第二の種類の仮想コンテナについては、前記制約を満たす装置を選択して行われることを特徴とするロボットアプリケーション管理装置。
  2. 　前記ロボットアプリケーション管理装置と外部ネットワークを介して接続される少なくとも一つのクラウドサービス装置を、前記クラスタを構成する装置群に含めることを特徴とする請求項１に記載のロボットアプリケーション管理装置。
  3. 　前記複数の仮想コンテナには、所定以上の処理能力又は記憶容量を要するために該仮想コンテナを実行する装置の選択に別の制約がある第三の種類の仮想コンテナがあり、
    　前記第三の種類の仮想コンテナと、前記第一及び第二の種類の仮想コンテナとは、疎結合で動作するものであり、
    　前記配置は、第三の種類の仮想コンテナについては、前記別の制約を満たす装置を選択して行われることを特徴とする請求項１又は２に記載のロボットアプリケーション管理装置。
  4. 　前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させるための手順を、記憶する手段をさらに備えることを特徴とする請求項１～３のいずれか１項に記載のロボットアプリケーション管理装置。
  5. 　前記クラスタを構成する装置群の各装置がどの制約を満たすものかを示す情報を記憶する手段をさらに備えることを特徴とする請求項１～４のいずれか１項に記載のロボットアプリケーション管理装置。
  6. 　前記複数種類の仮想コンテナのそれぞれが配置される装置が該仮想コンテナの実行可能なプログラムを取得できるように、該実行可能なプログラムを記憶する手段をさらに備えることを特徴とする請求項１～５のいずれか１項に記載のロボットアプリケーション管理装置。
  7. 　前記仮想コンテナの実行可能なプログラムは、前記ロボットアプリケーションを構成するアプリケーションプログラムとオペレーティングシステム（ＯＳ）とがパッケージ化されたものであり、各装置のホストＯＳ上に仮想コンテナごとに分離した空間が形成され、該ホストＯＳからはプロセスとして見えるように実行されるものであることを特徴とする請求項１～６のいずれか１項に記載のロボットアプリケーション管理装置。
  8. 　前記クラスタを構成する装置群のいずれかが動作不良に陥った場合に、該動作不良に陥った装置で起動されている仮想コンテナを、前記クラスタを構成する他の装置に再配置して起動させることにより、前記ロボットアプリケーションの実行を継続する手段をさらに備え、
    　前記再配置は、前記実行する装置の選択に制約がある仮想コンテナについては、該制約を満たす装置を選択して行われ、該制約を満たす装置が前記動作不良に陥った装置以外に存在しない場合には、前記ロボットアプリケーションの実行を停止するものであることを特徴とする請求項１～７のいずれか１項に記載のロボットアプリケーション管理装置。
  9. 　前記実行する装置の選択に制約がある仮想コンテナを、ステートレスなものとし、
    　前記クラスタを構成する装置群のいずれかが動作不良に陥り、前記ロボットアプリケーションの実行が停止された場合に、該動作不良に陥った装置又はそれに代わる装置が前記クラスタを構成する装置として復活したら、前記仮想コンテナの配置及び起動を行うことにより、前記ロボットアプリケーションの実行を再開することを特徴とする請求項１～８のいずれか１項に記載のロボットアプリケーション管理装置。
  10. 　前記仮想コンテナが起動されている装置が前記クラスタを構成する装置でなくなった場合に、該仮想コンテナを停止させる手段と、
    　前記仮想コンテナを停止させるための手順を、記憶する手段とをさらに備えることを特徴とする請求項１～９のいずれか１項に記載のロボットアプリケーション管理装置。
  11. 　前記複数種類の仮想コンテナのそれぞれがどの装置に配置され、起動中であるか停止中であるかを含めどのような状態であるかを示す情報を収集し、ユーザに表示するサービス又は履歴を記憶するサービスの少なくとも一方へ送信する手段をさらに備えることを特徴とする請求項１～１０のいずれか１項に記載のロボットアプリケーション管理装置。
  12. 　前記クラスタを構成する各装置における各仮想コンテナが前記ローカルネットワークを介して通信できるように、ネットワーク接続を支援する手段をさらに備え、
    　該手段の少なくとも一部は、前記複数種類の仮想コンテナのうちの一つが自装置に配置されて起動されることにより備えられることを特徴とする請求項１～１１のいずれか１項に記載のロボットアプリケーション管理装置。
  13. 　前記少なくとも一つのロボット装置は、移動するロボット装置を含み、
    　前記ローカルネットワークのうち少なくとも前記移動するロボット装置への接続部分は、無線で構成されるものであり、
    　前記無線接続のためのアクセスポイント機能又はマルチホップ機能の少なくとも一方をさらに備えることを特徴とする請求項１～１２のいずれか１項に記載のロボットアプリケーション管理装置。
  14. 　前記ロボットアプリケーション管理装置が備える手段のうちの少なくとも一部を備える少なくとも１つの副ロボットアプリケーション管理装置を、前記クラスタを構成する装置群に含めることを特徴とする請求項１～１３のいずれか１項に記載のロボットアプリケーション管理装置。
  15. 　前記ローカルエリアネットワークと外部ネットワークとの境界に位置し、
    　前記ローカルエリアネットワークに接続された各装置を前記外部ネットワークから保護する手段をさらに備えることを特徴とする請求項１～１４のいずれか１項に記載のロボットアプリケーション管理装置。
  16. 　前記ロボットアプリケーションのために物理的環境のデータを入力するセンサをさらに備え、
    　前記センサを制御する仮想コンテナを、前記複数種類の仮想コンテナのうちの一つとして、自装置に配置して起動させることを特徴とする請求項１～１５のいずれか１項に記載のロボットアプリケーション管理装置。
  17. 　前記クラスタを構成する少なくとも一つの装置における少なくとも一つの仮想コンテナが前記ローカルネットワークを介して前記クラスタを構成しない装置と通信できるように、ネットワーク接続のためのアドレスを付与する手段をさらに備えることを特徴とする請求項１～１６のいずれか１項に記載のロボットアプリケーション管理装置。
  18. 　複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理装置と、
    　前記ロボットアプリケーション管理装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置及び少なくとも一つのコンピュータ装置とを備えるシステムであって、
    　前記システムの備える装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理する手段と、
    　前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させる手段とを備え、
    　前記複数種類の仮想コンテナには、該仮想コンテナを実行する装置としていずれの装置を選択してもよい第一の種類の仮想コンテナと、ロボット装置における物理的接続を要するために該仮想コンテナを実行する装置の選択に制約がある第二の種類の仮想コンテナとがあり、
    　前記第一の種類の仮想コンテナと、前記第二の種類の仮想コンテナとは、疎結合で動作するものであり、
    　前記配置は、第二の種類の仮想コンテナについては、前記制約を満たす装置を選択して行われることを特徴とするシステム。
  19. 　複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理方法であって、
    　前記ロボットアプリケーション管理方法を実行する装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置と少なくとも一つのコンピュータ装置とを含む装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理し、
    　前記複数種類の仮想コンテナには、該仮想コンテナを実行する装置としていずれの装置を選択してもよい第一の種類の仮想コンテナと、ロボット装置における物理的接続を要するために該仮想コンテナを実行する装置の選択に制約がある第二の種類の仮想コンテナとがあり、
    　前記第一の種類の仮想コンテナと、前記第二の種類の仮想コンテナとは、疎結合で動作するものであり、
    　前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させ、
    　前記配置は、第二の種類の仮想コンテナについては、前記制約を満たす装置を選択して行われることを特徴とするロボットアプリケーション管理方法。
  20. 　複数種類の仮想コンテナを連携させながら実行することによりロボットアプリケーションを実行するためのロボットアプリケーション管理プログラムであって、
    　前記ロボットアプリケーション管理プログラムがインストールされる装置とローカルエリアネットワークを介して接続される少なくとも一つのロボット装置と少なくとも一つのコンピュータ装置とを含む装置群を、前記ロボットアプリケーションを実行するためのクラスタとして管理するためのプログラムコードと、
    　前記複数種類の仮想コンテナのそれぞれを、前記クラスタを構成する装置群のいずれかに配置して起動させるためのプログラムコードとを備え、
    　前記複数種類の仮想コンテナには、該仮想コンテナを実行する装置としていずれの装置を選択してもよい第一の種類の仮想コンテナと、ロボット装置における物理的接続を要するために該仮想コンテナを実行する装置の選択に制約がある第二の種類の仮想コンテナとがあり、
    　前記第一の種類の仮想コンテナと、前記第二の種類の仮想コンテナとは、疎結合で動作するものであり、
    　前記配置は、第二の種類の仮想コンテナについては、前記制約を満たす装置を選択して行われることを特徴とするロボットアプリケーション管理プログラム。
PCT/JP2019/002517 2018-01-26 2019-01-25 ロボットアプリケーション管理装置、システム、方法及びプログラム WO2019146763A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US16/964,286 US11327856B2 (en) 2018-01-26 2019-01-25 Robot application management device, system, method and program
CN201980010102.2A CN111656320A (zh) 2018-01-26 2019-01-25 机器人应用管理装置、系统、方法及程序

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018-011123 2018-01-26
JP2018011123A JP6572330B2 (ja) 2018-01-26 2018-01-26 ロボットアプリケーション管理装置、システム、方法及びプログラム

Publications (1)

Publication Number Publication Date
WO2019146763A1 true WO2019146763A1 (ja) 2019-08-01

Family

ID=67396054

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/002517 WO2019146763A1 (ja) 2018-01-26 2019-01-25 ロボットアプリケーション管理装置、システム、方法及びプログラム

Country Status (4)

Country Link
US (1) US11327856B2 (ja)
JP (1) JP6572330B2 (ja)
CN (1) CN111656320A (ja)
WO (1) WO2019146763A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021195709A1 (en) * 2020-03-31 2021-10-07 Stealth Technologies Pty Ltd Autonomous vehicle/robot control
WO2023272385A1 (en) * 2021-06-29 2023-01-05 Kinova Inc. Containerized plug-in system for robotics

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6792125B1 (ja) * 2019-07-02 2020-11-25 ラトナ株式会社 エッジシステム、エッジシステムの制御方法、エッジシステムの制御に用いるコンピュータプログラム、及び、その記録媒体
KR102261306B1 (ko) * 2019-11-11 2021-06-08 주식회사 스프링클라우드 자율주행시스템
KR102496687B1 (ko) * 2020-09-23 2023-02-07 한국전자통신연구원 도커화된 인공지능 라이브러리에 대한 프록시 생성 장치 및 방법, 도커화된 인공지능 라이브러리 기반 ros 분산 시스템
JP2022091301A (ja) * 2020-12-09 2022-06-21 オムロン株式会社 制御システムおよび制御方法
CN113127192B (zh) * 2021-03-12 2023-02-28 山东英信计算机技术有限公司 一种多个服务共享同一个gpu的方法、系统、设备及介质
CN113296807B (zh) * 2021-05-12 2023-10-31 阿里巴巴新加坡控股有限公司 数据更新方法
CN113286009B (zh) * 2021-07-20 2021-10-26 上海景吾智能科技有限公司 远端HTTP网页实时查看机器人rosbag的播放方法及系统
US20230102169A1 (en) * 2021-09-27 2023-03-30 UiPath, Inc. System and computer-implemented method for controlling a robot of a virtual machine

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009282652A (ja) * 2008-05-21 2009-12-03 Yokogawa Electric Corp 分散アプリケーションの配置先ノード選択支援システム、配置先ノード選択支援方法およびプログラム

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2925572B1 (fr) * 2007-12-24 2010-02-12 Snecma Services Procede de choix d'un arrangement de secteurs pour un distributeur pour turbomachine
CN101286188B (zh) * 2008-04-03 2010-06-02 深圳先进技术研究院 一种虚拟仿真系统中力觉反馈的计算方法
US8850571B2 (en) * 2008-11-03 2014-09-30 Fireeye, Inc. Systems and methods for detecting malicious network content
CN102087592B (zh) * 2009-12-08 2014-03-19 茵弗维尔科技株式会社 用于执行机器人应用程序的终端装置
US8412945B2 (en) * 2011-08-09 2013-04-02 CloudPassage, Inc. Systems and methods for implementing security in a cloud computing environment
CN103386687A (zh) * 2013-07-16 2013-11-13 河北工业大学 一种具有力觉临场感的2-dof机器人遥操作装置
US20150046425A1 (en) * 2013-08-06 2015-02-12 Hsiu-Ping Lin Methods and systems for searching software applications
US10237240B2 (en) * 2016-07-21 2019-03-19 AT&T Global Network Services (U.K.) B.V. Assessing risk associated with firewall rules
CN107329799A (zh) * 2017-05-22 2017-11-07 国网安徽省电力公司信息通信分公司 一种融合Docker容器与KVM虚拟化技术的系统
US11861511B2 (en) * 2017-10-04 2024-01-02 Trustees Of Tufts College Systems and methods for ensuring safe, norm-conforming and ethical behavior of intelligent systems
US20190325763A1 (en) * 2018-04-22 2019-10-24 Intel Corporation Real and virtual collision-free movement of autonomous vehicles in mixed-reality environments
TWI726236B (zh) * 2018-09-05 2021-05-01 林保成 個人雲系統及其相關本地化方法

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009282652A (ja) * 2008-05-21 2009-12-03 Yokogawa Electric Corp 分散アプリケーションの配置先ノード選択支援システム、配置先ノード選択支援方法およびプログラム

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
FUKUDA, TATSUYA ET AL.: "Development of service robot using network/virtualization environment provided by edge computing device", IEICE TECHNICAL REPORT, vol. 117, no. 198, 25 August 2017 (2017-08-25), pages 37 - 42 *
KAGAMI, TAKAHIRO: "A Recommendation Cloud System for Robot Application considering Robot Hardware Configuration", IEICE TECHNICAL REPORT, vol. 111, no. 446, 20 February 2012 (2012-02-20), pages 19 - 23 *
TERAUCHI, ATSUSHI: "R&D activities toward new value creation through IoT", N TT TECHNICAL JOURNAL, vol. 29, no. 7, 1 July 2017 (2017-07-01), pages 19 - 23 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021195709A1 (en) * 2020-03-31 2021-10-07 Stealth Technologies Pty Ltd Autonomous vehicle/robot control
WO2023272385A1 (en) * 2021-06-29 2023-01-05 Kinova Inc. Containerized plug-in system for robotics

Also Published As

Publication number Publication date
JP6572330B2 (ja) 2019-09-04
CN111656320A (zh) 2020-09-11
US11327856B2 (en) 2022-05-10
US20210034479A1 (en) 2021-02-04
JP2019128863A (ja) 2019-08-01

Similar Documents

Publication Publication Date Title
WO2019146763A1 (ja) ロボットアプリケーション管理装置、システム、方法及びプログラム
KR102125260B1 (ko) 분산 지능모듈의 통합관리 시스템
US10044795B2 (en) Methods and apparatus for rack deployments for virtual computing environments
US11416342B2 (en) Automatically configuring boot sequence of container systems for disaster recovery
US11146620B2 (en) Systems and methods for instantiating services on top of services
CN108737468B (zh) 云平台服务集群、构建方法及装置
CN102891882B (zh) 利用硬件中的网络包缓冲的基于检查点的高可用性
US9910765B2 (en) Providing testing environments for software applications using virtualization and a native hardware layer
EP3716552B1 (en) Universal customer premises equipment
CN109062655A (zh) 一种容器化云平台及服务器
CN113196237A (zh) 计算系统中的容器迁移
EP3037964B1 (en) Virtual application manager in a cloud computing environment
WO2013148665A1 (en) Global computing interface
JP2006190141A (ja) 移動処理プログラム、情報処理装置、コンピュータシステム及び移動処理プログラムを格納したコンピュータ読み取り可能な記録媒体
US20210250234A1 (en) Methods and apparatus to migrate physical server hosts between virtual standard switches and virtual distributed switches in a network
CN112311646B (zh) 基于超融合系统的混合云及部署方法
JP7056759B2 (ja) Ｉｃｔ資源管理装置、ｉｃｔ資源管理方法、および、ｉｃｔ資源管理プログラム
US20220237090A1 (en) Autonomous organization and role selection of homogenous workers
CN112667293B (zh) 一种部署操作系统的方法、装置及存储介质
WO2013114829A1 (ja) 情報処理システム、データセンタ、システム移行方法、及び、プログラム
US20140122676A1 (en) Method and Apparatus For Web Based Storage On Demand
KR102394293B1 (ko) 다종 멀티 지능모듈 프로세스 조합 시스템
KR102554198B1 (ko) 테스트베드 시스템 및 그것의 제어 방법
WO2024069846A1 (ja) 仮想化ネットワーク機能のためのリソース割り当ての動的な変更
CN117478634A (zh) 网络地址的访问方法、装置、存储介质及电子装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19744606

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19744606

Country of ref document: EP

Kind code of ref document: A1