JP7353341B2 - A method for controlling a robot that provides services in conjunction with a service application and a cloud server - Google Patents

Description

The following description relates to a cloud server and a method for controlling a robot that provides a service in conjunction with a service application.

An autonomous robot is a robot that detects obstacles while exploring its surroundings, and uses its tires and feet to find the optimal route to its destination.It is used not only for autonomous vehicles but also for logistics and hotel services. It has been developed and utilized for various fields such as , cleaning services, etc.

For example, Patent Document 1 discloses a technology related to a route planning method for an autonomous mobile robot, in which a mobile robot that moves autonomously in a home or office safely and quickly moves to a target point while avoiding obstacles. This paper discloses a method for planning an optimal route for

The above information is only intended to aid in understanding the invention and may contain material that does not form part of the prior art.

Korean Published Patent No. 10-2005-0024840

A method of controlling a robot that provides a service in conjunction with a service application, executed by a cloud server, in which an abstracted command received from the service application is concretely generated to generate multiple sub-commands. A robot control method is provided in which a robot is controlled by sending sub-commands to the robot.

To analyze the data received from the robot to generate abstracted data, send the abstracted data to the service application, and control the robot with the service application based on the corresponding abstracted data. Provided is a robot control method that enables generation of commands and monitoring information for the robot.

In one aspect, there is provided a method for controlling a robot that provides a service in cooperation with a service application, which is executed by a cloud server, including the step of receiving an instruction for providing the service from the service application; A robot control method, comprising: generating a plurality of sub-instructions by embodying the sub-instructions; and transmitting each sub-instruction of the sub-instructions to the robot, the robot being controlled based on the received sub-instructions. I will provide a.

The robot control method further includes the step of determining whether the instruction from the service application is an instruction to be bypassed, and the step of generating the sub-instruction is performed when the instruction from the service application is not an instruction to be bypassed. May be executed.

The robot control method further includes the step of directly transmitting the command from the service application to the robot, if the command from the service application is a bypass target command, and the robot performs the command based on the transmitted command. may be controlled by Here, "direct transmission" refers to transmitting the received command as it is without going through the "step of embodying the received command and generating a plurality of sub-commands."

The bypass target command may be a command for controlling a configuration related to a UX (User Experience) of the robot.

Each of the sub-commands is a unit command executable by the robot, and the step of generating the sub-commands may include generating the sub-commands by dividing the received command into a plurality of unit commands.

The command from the service application is a command to cause the robot to move to a destination, and the step of generating sub-commands includes a plurality of commands for the robot to move from the current location of the robot to the destination. and transmitting an instruction for moving the robot to each of the waypoints to the robot as each sub-instruction, the robot responding to the movement to the waypoint. The vehicle may be moved to the destination by being controlled according to the sub-instruction to perform the sub-instruction.

In the step of transmitting each of the sub-commands, each of the sub-commands is transmitted in order, and in the step of transmitting a first sub-command of the sub-commands to the robot, control of the robot by the first sub-command is completed. after receiving the completion report from the robot; and after receiving the completion report, transmitting to the robot a second sub-instruction that is next to the first sub-instruction among the sub-instructions. may be included.

The step of transmitting each of the sub-commands includes the step of monitoring the state of the robot, and transmitting the sub-commands necessary for the robot to provide the service from among the sub-commands based on the state of the robot. The method may include transmitting to the robot a cancellation command for canceling a sub-command that has been sent to the robot or has previously been sent.

The robot control method includes the steps of receiving data collected by the robot from the robot, analyzing the data to generate abstracted data, and transmitting the abstracted data to the service application. Based on the abstracted data, the service application may generate instructions for controlling the robot or generate monitoring information for the robot.

The robot control method further includes the steps of determining whether data from the robot includes data to be bypassed, and directly transmitting the data to be bypassed among the data from the robot to the service application. , the bypass target data may include data indicating a first state of the robot.

The step of generating the abstracted data includes the step of analyzing data from the robot to determine whether the robot exhibits the second state, and the result of the determination determines whether the robot exhibits the second state. The service application may include the step of transmitting information regarding whether to display or not to the service application as the abstracted data.

The robot control method further includes the steps of: generating an independent command for controlling the robot independently of commands from the service application; and transmitting the independent command to the robot or another robot, The independent command may be a command to request the robot to charge, a command to update the route of movement of the robot to a particular point, or a command to perform the other command when the robot is no longer able to provide the service. It may include instructions requesting the robot to provide the service.

The service application is implemented on a server or client that is separated from the robot via a network, and the instructions from the service application directly control the robot to provide the service. Each sub-instruction is an abstracted command that cannot be sent to the robot, and each sub-instruction is a concrete command of the abstracted command so that the robot can be directly controlled. Each sub-instruction may not include context information associated with the service.

By plugging the service application into the robot, the robot is realized to provide the service in cooperation with the service application, and the service application is plural, and the robot is configured to provide the service in cooperation with the service application. The server controls the robot to cooperate with the other service application to provide other services by causing the other service application of the plurality of service applications to be plugged in with the robot. It's fine.

Different security policies may be set for the service application, the cloud server, and the robot.

In another aspect, there is provided a method for controlling a robot that provides a service in cooperation with a cloud server and a service application, the method comprising: providing the service transmitted from the service application to the cloud server; The service application includes the steps of receiving each sub-instruction of a plurality of sub-instructions generated by embodying the instruction, and controlling the robot based on each of the received sub-instructions, is realized on a server or client that is partitioned via a network, and the instructions from the service application are abstracted instructions that cannot directly control the robot to provide the service. and each of the sub-instructions is a concrete instruction of the abstracted instruction so as to be able to directly control the robot, and each of the sub-instructions sent to the robot is an instruction of the service. To provide a robot control method that does not include context information associated with the robot.

The robot control method further includes the steps of collecting data related to controlling the robot, and transmitting the collected data to the cloud server, and the data transmitted to the cloud server is transmitted to the cloud server. is processed into abstracted data by being analyzed by the service application, and is sent to the service application, and based on the abstracted data, the service application generates an instruction for controlling the robot. , information indicating monitoring information of the robot may be generated.

The robot is realized by being plugged in with the service application to provide the service in cooperation with the service application, and the cloud server allows the robot to connect to other services other than the service application. By plugging in applications, the robot may be controlled to provide other services in conjunction with the other service applications.

In another aspect, a cloud server for controlling a robot providing a service in conjunction with a service application, the cloud server comprising at least one processor implemented to execute computer readable instructions, the at least one A processor receives an instruction for providing the service from the service application, embodies the received instruction to generate a plurality of sub-instructions, transmits each sub-instruction of the sub-instructions to the robot, and The robot provides a cloud server that is controlled based on each of the received sub-instructions.

A service application containing service logic associated with the services provided by the robot can be separated from the robot. The service application can be implemented on a server or client that is separated from the robot via a network.

Based on the abstracted instructions received from the service application (which cannot directly control the robot), the cloud server generates a concrete sub-component that corresponds to a unit instruction for directly controlling the robot. The robot can be controlled to generate instructions and provide services according to the generated sub-instructions.

The robot side no longer needs to know the context information for the service provided by the robot, and the service application side no longer needs to know how to control the robot's detailed functions, reducing the complexity of service application development. Expandability can be easily increased.

A variety of applications can be plugged into the robot, making it easy to switch between robots providing different services.

FIG. 2 is a diagram illustrating a method of controlling a robot that provides a service in conjunction with a service application, executed by a cloud server, in one embodiment. 1 is a block diagram illustrating a robot providing a service in one embodiment. FIG. FIG. 2 is a block diagram illustrating a cloud server that controls a robot in one embodiment. FIG. 2 is a block diagram illustrating a cloud server that controls a robot in one embodiment. 1 is a block diagram illustrating a device equipped with a service application in one embodiment. FIG. 2 is a flowchart illustrating a method of controlling a robot that provides a service in conjunction with a service application, which is executed by a cloud server, in one embodiment. 2 is a flowchart illustrating a method for generating sub-instructions in which the abstracted instructions are materialized based on the abstracted instructions in one example. 2 is a flowchart illustrating a method for generating sub-instructions in which the abstracted instructions are materialized based on the abstracted instructions in one example. 5 is a flowchart illustrating a method for processing data from a robot and generating and processing abstracted data based on the data in one example. 5 is a flowchart illustrating a method for processing data from a robot and generating and processing abstracted data based on the data in one example. 5 is a flowchart illustrating a method for generating and processing independent commands that are independently provided to a robot on a cloud server side in one example. FIG. 2 is a diagram illustrating a method for controlling a robot by generating concrete sub-instructions based on abstract instructions from a service application in one example. FIG. 2 is a diagram illustrating a method for controlling a robot by generating concrete sub-instructions based on abstract instructions from a service application in one example. FIG. 2 is a diagram showing an N:1:K relationship between a cloud server, a robot, and a service application in an example. FIG. 2 is a diagram illustrating the relationship between a cloud server, a robot, and a service application in terms of data flow in one example.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings.

FIG. 1 is a diagram illustrating a method of controlling a robot that provides a service in conjunction with a service application, which is executed by a cloud server, in one embodiment.

In FIG. 1, in providing a service through the robot 100 (or controlling the robot 100), the cloud server 120 receives an instruction (abstracted instruction) from the service application 110, and embodies the received instruction. , describes a method for controlling the robot 100 according to concrete instructions.

In FIG. 1, when the robot 100 is controlled, the cloud server 120 receives data collected by the robot 100 from the robot 100 (for example, data related to the control of the robot 100), abstracts the data, and abstracts the data. A method for transmitting converted data to the service application 110 is explained.

The cloud server 120 may determine whether the command from the service application 110 corresponds to a bypass target command that does not need to be materialized, and if the command is a bypass target command, the cloud server 120 directly sends the corresponding command to the robot 100. May be communicated (routing or forwarding).

Further, the cloud server 120 may determine whether the data from the robot 100 includes bypass target data that does not require abstraction, and if the data is bypass target data, the data is directly transmitted to the service application 110. (routing or forwarding).

As an example, as shown in the figure, when a command from the service application 110 is "wink and greet", a device 105 (for example, an LED corresponding to the eyes of the robot 100) associated with the UX (User Experience) of the robot 100 is sent. , or other sound output device), the cloud server 120 may determine that such an instruction corresponds to a bypass target instruction. At this time, the command may be transmitted to the robot 100, and the robot 100 may output an expression and sound corresponding to a greeting (“hello”) through the device 105.

In embodiments, portions of the service application that include service logic associated with services provided by the robot 100 may be implemented separately from the robot 100. In other words, the embodiments differ from the conventional technology in which an application including a service or a function related to the service must be installed inside the robot 100 in order to realize the robot 100 for providing a specific service. In comparison, the complexity of the service application 110 (on the side that operates and/or requests services) can be reduced, and the scalability of the robot 100 can be increased.

In the case of conventional technology, the service logic related to the service provided by the robot 100 is installed in the robot 100 as a service application, and the service application installed in such a robot (operating and/or requesting side) ) The service was provided while interacting with the service application 110.

In contrast, in the case of the embodiment, since the robot 100 is not equipped with a service application including service logic, the robot 100 cannot grasp the context information related to the service, and the robot 100 is unable to grasp the context information related to the service. The robot 100 receives only commands (ie, unit commands executable by the robot 100) for controlling the movement of the robot 100 and the functions provided by the robot 100 from the robot 120 and operates.

On the other hand, the service application 110 side that issues the command may send abstracted commands (not concrete commands for directly controlling the robot) to the cloud server 120, and the cloud server 120 side Based on such abstracted instructions, concrete instructions for directly controlling the robot 100 may be generated. Therefore, the developer of the service application 110 no longer needs to know how to control the detailed functions of the robot 100, and the developer of the service application 110 no longer needs to know how to control the detailed functions of the robot 100, and can control the robot 100 with only abstracted instructions. You will be able to develop applications that can

The service application 110 may be implemented on a server or client that is partitioned from the robot 100 via a network. Additionally, service application 110 may be coupled to robot 100 or implemented within a device included in robot 100, depending on the embodiment. Even in such an embodiment, the service application 110 and the robot 100 may be separated via the network.

The specific operations of the robot 100, the service application 110, and the cloud server 120 and the detailed control method of the robot 100 will be explained in more detail with reference to FIGS. 2 to 15.

FIG. 2 is a block diagram illustrating a robot providing a service in one embodiment.

FIG. 2 shows a robot 100 that provides services in conjunction with a service application 110 using a cloud server 120. The robot 100 may be, for example, a service robot that provides services under the control of the cloud server 120 in a space such as the interior of a building. Space should not be limited to indoor space, but may also refer to outdoor space. In other words, the space may be an indoor or outdoor space with a specified range, or a space that includes both indoors and outdoors.

The space may be, for example, a building (such as a company) where goods are delivered by the robot 100, a cafe where food and drinks are delivered, an indoor/outdoor space where guidance services are provided, or the like.

The robot 100 may provide services to users within the space by traveling in the space. The robot 100 may provide a service based on instructions (abstracted instructions) from the service application 110. Instructions from the service application 110 may be embodied in the cloud server 120 and communicated to the robot 100, and the robot 100 may be controlled based on such embodied instructions.

The robot 100 does not execute specific calculations necessary to provide the service, and uses not only sensing data to perform this but also data related to robot control (or data collected by the robot 100). The robot may be considered a brainless robot in that it only provides information to the cloud server 120.

The services provided by the robot 100 may include a delivery service that delivers food, drinks, products such as manufactured goods, or home delivery within a space. That is, robot 100 may be a delivery service robot or a serving service robot. Further, the services provided by the robot 100 may include a guide service that guides the user to a specific position in space. Furthermore, the services provided by the robot 100 may include a security service, an information provision service such as events/news, and a service for managing plants located within the space.

The robot 100 may be a physical device, and may include a control section 104, a driving section 108, a sensor section 106, and a communication section 102, as shown in the figure. Furthermore, the robot 100 may further include a mounting section on which items for providing services are placed.

The control unit 104 may be a physical processor built into the robot 100, and includes a path planning processing module 211, a mapping processing module 212, a drive control module 213, a localization processing module 214, a data processing module 215, and an instruction processing module. 216. At this time, the route planning processing module 211, the mapping processing module 212, and the localization processing module 214 are configured according to the embodiment in order to allow the robot 100 to run autonomously even when there is no communication with the cloud server 120. Depending on the situation, it may be selectively included in the control unit 104.

The communication unit 102 may be configured to allow the robot 100 to communicate with other devices (such as other robots or the cloud server 120). In other words, the communication unit 102 includes hardware such as an antenna, a data bus, a network interface card, a network interface chip, a networking interface port, etc. of the robot 100 that transmits/receives data and/or information to/from other devices. or a software module such as a network device driver or networking program.

The drive unit 108 is configured to control the movement of the robot 100 to enable the movement, and may include equipment for executing this. For example, drive unit 108 may include tires. Drive unit 108 may control movements and/or functions of robot 100 according to instructions processed by instruction processing module 216.

The sensor unit 106 may be configured to collect data necessary for the robot 100 to travel autonomously and provide services. The sensor unit 106 does not need to include expensive sensing equipment (scanning equipment), and may include sensors such as a low-cost ultrasonic sensor and/or a low-cost camera. The sensor unit 106 may include a sensor for identifying obstacles/persons located in the traveling direction.

Further, although not shown in the figure, the sensor unit 106 may include a camera. The camera may be positioned such that it can recognize users or obstacles located around the robot 100. The camera may be an RGB camera or a monocular camera. Alternatively, the camera may include a depth camera.

As an example of processing by the control unit 104, the data processing module 215 of the control unit 104 transmits sensing data including a sensing value from the sensor unit 106 (for example, an output value from the sensor) to the cloud server 120 via the communication unit 102. You may do so. The cloud server 120 may transmit route data generated based on an in-space (indoor) map to the robot 100. The route data may be data indicating a route for the robot 100 to provide a service. The route data may be transmitted from the communication unit 102 to the data processing module 215. The data processing module 215 may directly transmit the route data to the drive control module 213, and the drive control module 213 may control the drive unit 108 according to the route data to control autonomous travel of the robot 100.

If the robot 100 and the cloud server 120 are unable to communicate, the data processing module 215 sends the sensing data to the localization processing module 214, the route planning processing module 211 and the mapping processing module 212 generate route data, and the robot 100 Autonomous driving may be handled directly. For example, the control unit 104 may use the route planning processing module 211 and the mapping processing module 212 to identify a location where a service is provided from a map, and use route data as data indicating a route for providing a service at the identified location. may be generated, and the autonomous running of the robot 100 may be controlled to travel along a route based on such route data.

The robot 100 may autonomously move to a location to provide a service based on a map stored in the cloud, and performs actions such as avoiding obstacles, crossing thresholds, getting on and off elevators, and making emergency stops while moving. It may be controlled to

On the other hand, the robot 100 may be different from a mapping robot used to generate a map in space. At this time, since the robot 100 does not include expensive sensing equipment (scanning equipment), it can run autonomously using output values of sensors such as low-cost ultrasonic sensors and/or low-cost cameras. May be processed. If the robot 100 has previously processed autonomous travel through communication with the cloud server 120, it can utilize low-cost sensors by further utilizing mapping data included in route data previously received from the cloud server 120. This enables accurate autonomous driving even while driving. Depending on the embodiment, the robot 100 may also be used as the mapping robot.

In embodiments, the robot 100 may not be equipped with a service application that includes service logic related to the services provided by the robot 100. Therefore, the robot 100 is not directly controlled by abstracted instructions for providing a service from the service application 110, but unit instructions generated by the cloud server 120 embodying the instructions. (sub-instructions). The sub-commands sent from cloud server 120 to robot 100 may not include context information associated with the service. For example, the sub-command does not need to include information related to the service, such as information indicating the type of service or a service identifier. Therefore, control of the robot 100 does not have to depend on the context of the service.

The command processing module 216 may receive commands (ie, instantiated commands) received from the cloud server 120 via the communication unit 102 or via the communication unit 102 and the data processing module 215. The control unit 104 may control the robot 100 based on the received command. The robot 100 may provide a service to a user by being controlled according to embodied instructions received from the cloud server 120.

Meanwhile, the driving unit 108 may include not only equipment for moving the robot 100 but also equipment related to services provided by the robot 100. For example, the drive unit 108 may include a loading unit as described above and a configuration (eg, a robot arm) for loading and moving items related to the service. According to the embodied instructions received from the cloud server 120, the driving unit 108 may be controlled to provide the service.

Additionally, the robot 100 may further include a speaker and/or display, LEDs, etc. for providing information/content. These devices may constitute the device 105 associated with the UX described with reference to FIG. Command processing module 216 may control robot 100 such that UX and associated devices 105 are controlled according to commands received from cloud server 120.

In the embodiment, the service application 110 is equipped with logic that controls the UI and service scenario of the robot 100, and the robot 100 is equipped with only the minimum logic (for example, safety-related logic) required for the operation of the robot 100. It's okay to be. According to abstracted instructions (eg, movement instructions) from service application 110, cloud server 120 may determine a detailed movement plan corresponding to the instruction and may control robot 100. The robot 100 may travel according to such a determined movement plan.

A specific method for receiving instructions from the cloud server 120 and controlling the robot 100 according to the received instructions will be described in more detail with reference to FIGS. 3 to 15.

The technical features described above with reference to FIG. 1 can also be applied to FIG. 2 as they are, so duplicate explanations will be omitted.

3 and 4 are block diagrams illustrating a cloud server that controls a robot in one embodiment.

The cloud server 120 may be a device that controls the movement (i.e., travel) of the robot 100 described above in space and the functions provided by the robot 100. When there are a plurality of robots 100, the cloud server 120 may control the movement of each of the plurality of robots and the functions of each of the robots. Cloud server 120 may communicate with robot 100 to establish a route that robot 100 must travel to provide a service, and may communicate information regarding such route to robot 100. The robot 100 may travel according to the received information regarding the route and may provide services to the user. That is, the cloud server 120 may control the movement of the robot 100 so that the robot moves (runs) along a set route.

The cloud server 120 may constitute a robot control system or a part thereof. The cloud server 120 may include at least one computer device and may be implemented in a server located inside or outside the space.

Cloud server 120 may include a memory 330, a processor 320, a communications unit 310, and an input/output interface 340, as shown.

Memory 330 is a computer-readable storage medium, and may include random access memory (RAM), read only memory (ROM), and permanent mass storage devices such as disk drives. . Here, the ROM and the permanent mass storage device may be included as separate permanent storage devices separated from the memory 330. Additionally, an operating system and at least one program code may be recorded in the memory 330. Such software components may be loaded from a computer-readable storage medium separate from memory 330. Such other computer-readable recording media may include computer-readable recording media such as floppy drives, disks, tapes, DVD/CD-ROM drives, memory cards, and the like. In other embodiments, software components may be loaded into memory 330 through communication portion 310 that is not a computer-readable storage medium.

Processor 320 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input/output operations. Instructions may be provided to processor 320 by memory 330 or communication unit 310. For example, processor 320 may be configured to execute instructions received according to program code loaded into memory 330. Such a processor 320 may include configurations 410-440 as shown in FIG.

Each of the components 410-440 of the processor 320 is part of the processor 320 and may be a software and/or hardware module, and may represent a function (functional block) implemented by the processor. The configurations 410 to 440 of the processor 320 will be described with reference to FIG.

The communication unit 310 may be configured to allow the cloud server 120 to communicate with another device (such as a device equipped with the robot 100 or the service application 110). In other words, the communication unit 310 includes hardware such as antennas, data buses, network interface cards, network interface chips, networking interface ports, etc. of the cloud server 120 that transmit/receive data and/or information in other devices. module or a software module such as a network device driver or networking program.

Input/output interface 340 may be a means for interfacing with input devices, such as a keyboard or mouse, and output devices, such as a display or speakers.

In some embodiments, cloud server 120 may include more components than those illustrated.

In embodiments, the cloud server 120 may receive instructions (abstracted instructions) for the robot 100 to provide the service from the service application 110, and processes (i.e., embodies) the received instructions to provide the robot with the instructions. Sub-instructions (ie, instantiated instructions) may be generated to control 100.

The configurations 410 to 440 of the processor 320 described above will be described in more detail with reference to FIG. Processor 320 may include a map generation module 410, a localization processing module 420, a route planning processing module 430, and an instruction processing module 440, as shown. The components included in such processor 320 may perform different functions performed by at least one processor included in processor 320 according to control instructions provided by operating system code and at least one computer program code. ) may be an expression.

The map generation module 410 generates an indoor map of a target facility using sensing data generated for the target facility (for example, inside a building) by a mapping robot (not shown) autonomously running inside the building. It may be a component for

At this time, the localization processing module 420 uses the sensing data received from the robot 100 via the network and the indoor map of the target facility generated by the map generation module 410 to ) may determine the position of the robot 100 within the interior.

The route planning processing module 430 may generate a control signal for controlling the autonomous running of the robot 100, using the sensing data received from the robot 100 described above and the generated indoor map. For example, the path planning processing module 430 may generate a path (ie, path data) for the robot 100 to travel. The generated route (route data) may be set in the robot 100 for the robot 100 to travel along the corresponding route. The cloud server 120 may transmit information regarding the generated route to the robot 100 via the network. As an example, the information regarding the route may include information indicating the current location of the robot 100, information for mapping the current location with an indoor map, or route planning information. The route planning processing module 430 may generate a route for the robot 100 and set it on the robot 100. The cloud server 120 may control the movement of the robot 100 so that the robot 100 moves along such a set route (that is, along the set route).

The generated route may be a route that the robot 100 travels in space to provide a service. Route planning processing module 430 may identify locations in space from the map to provide services and may generate a route that causes services to be provided at the locations.

The command processing module 440 may receive commands (abstracted commands) for the robot 100 to provide a service from the service application 110, and processes (i.e., embodies) the received commands to control the robot 100. A subinstruction (i.e., a reified instruction) may be generated to do the following: Additionally, the command processing module 440 may transmit the generated sub-commands to the robot 100 and control the robot 100 based on the sub-commands.

In the embodiment, the robot 100 is not equipped with a service application that includes service logic associated with the service provided by the robot 100, and the robot 100 is not equipped with a service application that includes service logic related to the service provided by the robot 100, and the robot 100 is not equipped with a service application that includes service logic related to the service provided by the robot 100. It does not have to be directly controlled.

The movements and functions of robot 100 may be controlled only by embodied instructions provided by cloud server 120. The instruction processing module 440 may generate sub-instructions corresponding to the unit instructions by embodying the abstracted instructions received from the service application 110 into unit instructions executable by the robot. Robot 100 may be controlled by sending each of the commands to robot 100.

Furthermore, depending on the type of command received from the service application 110, the command processing module 440 may directly transmit the command to the robot 100, or after embodying the relevant command, transmit the embodied sub-command to the robot 100. 100 may be transmitted.

In the embodiment, since the robot 100 is not equipped with a service logic part corresponding to a service application, the developer of the service application 110 can provide services through the robot 100 without having to understand how to control detailed functions of the robot 100. Applications can be developed to provide Additionally, various service applications that provide different services can be easily plugged into the robot 100.

The command processing module 440 may also receive data collected by the robot 100 from the robot 100 (eg, data related to controlling the robot 100). Depending on the type of received data, the command processing module 440 may transmit the data to the service application 110, or may abstract the data and then transmit the abstracted data to the service application 110.

More specific operations of the robot 100, service application 110, and cloud server 120 and a method of controlling the robot 100 will be described in more detail with reference to FIGS. 5 to 15.

The technical features described above with reference to FIGS. 1 and 2 can also be applied to FIGS. 3 and 4 as they are, so duplicate explanations will be omitted.

FIG. 5 is a block diagram illustrating a device equipped with a service application in one embodiment.

As described above, the service application 110 may be implemented on a server or client that is separated from the robot 100 via a network. Device 500 may correspond to such a server or client. In some embodiments, such a device 500 may be coupled to the robot 100 or implemented within a device included in the robot 100. Further, the device 500 may be coupled to the cloud server 120 or may be realized within a device included in the cloud server 120. Even in such an embodiment, the service application 110 and the robot 100 may be separated via the network.

The device 500 is a personal computer (PC), a laptop computer, a smart phone, a tablet, a wearable computer, or an Internet of Things. ) equipment, etc. It may mean a terminal device or an electronic device. Device 500 may be a terminal used by a user who operates and/or requests services provided by robot 100.

A service application 110 installed on the device 500 allows a user to instruct the robot 100 to provide a service. Such a command may be transmitted from the cloud server 120 to the robot 100, or may be transmitted to the robot 100 after being embodied through processing by the cloud server 120.

Additionally, the device 500 may receive data from the robot 100 using the installed service application 110. The data may be transmitted from the cloud server 120 to the service application 110 or may be abstracted through processing by the cloud server 120 and then transmitted to the service application 110.

Device 500 may include a communication unit 510 and a processor 520, as shown. The communication unit 510 may be a device for the device 500 to communicate with the cloud server 120 (or robot 100). In other words, the communication unit 510 is a hardware module, such as a network interface card, a network interface chip, a networking interface port, etc., or a network device driver that sends/receives data and/or information in such other devices. (driver) or a software module such as a networking program.

Processor 520 may manage components of device 500 and execute programs or applications used by user terminal 110. For example, processor 520 may install and execute service application 110 for generating and transmitting instructions for service provision by robot 100, and perform operations necessary to execute service application 110 and process data, etc. May be executed. Processor 520 may be at least one processor or at least one core within a processor.

Although not shown, device 500 may include memory. Memory is a computer-readable storage medium that may include random access memory (RAM), read only memory (ROM), and permanent mass storage devices such as disk drives. Here, the ROM and the permanent large capacity storage device may be included as separate permanent storage devices separated from the memory. An operating system and at least one program code may also be recorded in the memory. Such software components may be loaded from a computer-readable storage medium separate from memory. Such other computer-readable recording media may include computer-readable recording media such as floppy drives, disks, tapes, DVD/CD-ROM drives, memory cards, and the like. In other embodiments, the software components may be loaded into memory through communication portion 510 that is not a computer-readable storage medium.

Processor 520 may be configured to process instructions of a computer program by performing basic arithmetic, logic, and input/output operations. Instructions may be provided to processor 520 by memory or communication unit 510. For example, processor 520 may be configured to execute instructions received according to program code loaded into memory.

If the device 500 is a terminal of a user operating and/or requesting a service, the device 500 may include a display. The display may display monitoring information for the robot 100, including the control status of the robot 100, information for managing the robot 100, and the status of service provision by the robot 100. The display may include a touch screen.

In the embodiment, the service application 110, which is the entity that generates abstracted instructions for providing a service, and the cloud server 120, which is the entity that embodies the instructions and sends them to the robot 100, are separated.

Therefore, a layer corresponding to the service application 110, a layer corresponding to the cloud server 120, and a layer corresponding to the robot 100 may be separated from each other. As a result, the service application 110, the cloud server 120, and the robot 100 may be configured to have different security policies (or the security policies of at least two of them) and are updated relatively frequently. You can separate and manage only the necessary layers.

Further, in the embodiment, the robot 100 may be implemented to provide updated services by updating only the layer corresponding to the service application 110.

Further, since it is possible to easily plug different service applications into the robot 100, it is possible to realize a robot 100 that provides various services as long as the range of functions provided by the robot 100 is not exceeded.

The developer of the service application 110 can provide services provided by the robot 100 without having detailed domain knowledge about the robot 100 (i.e., without having to deal with unnecessary troubleshooting or issues related to execution/operation of the robot). can be implemented within the service application 110.

Therefore, the expandability of the robot 100 and the service application 110 can be improved.

The technical features described above with reference to FIGS. 1 to 4 can also be applied to FIG. 5 as they are, so redundant explanation will be omitted.

In the detailed description below, operations performed by robot 100, cloud server 120, or service application 110 (e.g., a processor of robot 100, cloud server 120, or device 500) are referred to as robot 100, cloud server 120, or a processor of device 500 for convenience of explanation. 120 or an operation executed by the service application 110.

FIG. 6 is a flowchart illustrating a method of controlling a robot that provides a service in conjunction with a service application, which is executed by a cloud server, in one embodiment.

At step 610, cloud server 120 may receive instructions to provide a service from service application 110. The commands received from the service application 110 request the robot 100 to perform specific operations and/or functions, and may be abstracted commands. Abstracted instructions may be instructions that (unless they are made concrete) cannot directly control the robot 100 so that a service is provided. The abstracted command may be, for example, a command to move the robot to a delivery or collection position in a delivery service, a command to guide a user to a specific position in a route guidance service, or a command to perform a specific function on the robot 100. may include instructions requesting the execution of the following.

At step 615, cloud server 120 may determine whether the instruction from service application 110 is a bypassed instruction.

In step 620, the cloud server 120 may directly transmit the command from the service application 110 to the robot 100 if the command from the service application 110 is a bypass target command. At step 622, the robot 100 may be controlled according to such communicated bypass target commands.

The bypass target command is a simple command that does not need to be embodied by the cloud server 120, and may be a command that is directly transmitted (routed) from the service application 110 to the robot 100 via the cloud server 120. The bypass target command may be, for example, a command for controlling the configuration 105 related to the UX (User Experience) of the robot 100. By way of example, the instructions to be bypassed may be instructions for controlling the on/off of an LED or indicator included in the robot 100 (e.g., an LED corresponding to a gaze on the robot, or other visual indicator), or an instruction provided in the robot 100. may include instructions for causing a particular sound to be output from the selected speaker. Further, a command for manually controlling the movement (movement) of the robot 100 may be a bypass target command.

The cloud server 120 may determine whether the instruction is a bypass target instruction by analyzing the type of instruction from the service application 110. For example, cloud server 120 may determine whether an instruction is a bypassed instruction by analyzing the protocol of the instruction from service application 110. That is, cloud server 120 may determine whether to bypass the instruction to robot 100 by interpreting the protocol end of the received instruction.

At step 625, cloud server 120 may embody the instructions received from service application 110 to generate a plurality of sub-instructions. The step of generating a sub-instruction may be performed when the instruction from the service application 110 is not a bypass target instruction. “Concretization of instructions” may mean dividing abstracted instructions from service application 110 into instructions that allow robot 100 to be directly controlled. In other words, each sub-instruction generated by step 625 may be a reification of an abstracted instruction from the service application 110 so that the robot 100 can be directly controlled.

At step 630, the cloud server 120 may send each of the generated sub-instructions to the robot 100. At step 635, robot 100 may be controlled based on each received sub-instruction. The robot 100 may complete the operation requested by the command from the service application 110 by completing control by the sub-command.

Each sub-instruction may constitute a unit instruction executable by the robot. In other words, in step 625, the cloud server 120 may generate sub-instructions by dividing the instruction received from the service application 110 into multiple unit instructions. For example, the cloud server 120 may generate sub-instructions by dividing the instruction received from the service application 110 into predetermined time units or predetermined size units. If the action indicated by the command received from the application 110 is divided into a plurality of actions depending on time, the command received from the application 110 may be divided into sub-instructions corresponding to each of the actions.

A method for generating sub-instructions in which the abstracted instructions are concrete based on the abstracted instructions will be described in more detail with reference to FIGS. 7 and 8.

The cloud server 120 may send each of the generated sub-instructions to the robot 100 in turn. Each sub-command may be transmitted from the cloud server 120 to the robot 100 in a timely manner according to the operation of the robot 100.

For example, at step 630, cloud server 120 may send a first of the sub-instructions to robot 100. The first sub-command may indicate a first action that the robot 100 must perform with priority in order to complete the action of the robot 100 indicated by the command received from the service application 110. At step 635, the robot 100 may perform the first action according to the first sub-instruction, and sends a completion report (or signal indicating completion) to the cloud server 120 indicating that the execution of the first action is completed. You may do so. In step 640, the cloud server 120 may receive such a completion report, and after receiving the completion report, in step 645, the cloud server 120 may execute a second sub-instruction subsequent to the first sub-instruction among the sub-instructions. It may be transmitted to the robot 100. At this time, the second sub-command may indicate an action subsequent to the first action to complete the action of the robot 100 indicated by the command received from the service application 110. At step 650, robot 100 may perform a second operation according to the second sub-instruction. Similarly, the robot 100 may send a completion report to the cloud server 120 indicating that the execution of the second action is completed, and may receive the next sub-instruction from the cloud server 120.

In this way, the cloud server 120 can sequentially send each of the generated sub-instructions to the robot 100, and transmits the next sub-instruction to the robot 100 after the action indicated by a certain sub-instruction is executed by the robot 100. By doing so, commands can be transmitted to the robot 100 in a timely manner. Thereby, malfunctions of the robot 100 can be prevented. In other words, cloud server 120 may implement instructions received from service application 110 by partitioning them into multiple missions. When one mission is completed according to a sub-command sent to the robot 100, a sub-command corresponding to the next mission may be sent to the robot 100.

Also, unlike what has been described above, the robot 100 does not need to send a report to the cloud server 120 after performing an operation based on a sub-instruction. At this time, the cloud server 120 may monitor the robot 100 (eg, in real time) and send the next sub-command to the robot 100 if it is determined that the robot 100 has executed the operation according to the sub-command.

Alternatively, the cloud server 120 may send each of the sub-commands to the robot 100 in turn at predetermined time intervals.

As described above, in the embodiment, the cloud server 120 analyzes the command from the service application 110 and, depending on the type of command, may bypass the corresponding command to the robot 100 or embody the command to generate sub-commands. It may be generated and transmitted to the robot, thereby allowing the robot 100 to be appropriately controlled.

On the other hand, although not shown in the figure, the robot 100 may determine whether the received command (sub-command) is a bypassed command from the service application 110. At this time, the robot 100 may determine whether the received command (sub-command) is a bypassed command from the service application 110 by analyzing the protocol of the received command (sub-command). If the received command (sub-instruction) corresponds to a bypassed command, the robot 100 may perform the operation corresponding to the bypassed command, and perform the action corresponding to the non-bypassed command (i.e., the instantiated sub-instruction). command), the action corresponding to the instantiated command may be executed.

The technical features described above with reference to FIGS. 1 to 5 can also be applied to FIG. 6 as they are, so duplicate explanations will be omitted.

7 and 8 are flowcharts illustrating, in one example, a method for generating sub-instructions in which the abstracted instructions are materialized based on the abstracted instructions.

With reference to FIG. 6, a method in which the cloud server 120 generates sub-instructions by dividing the instruction received from the service application 110 into a plurality of unit instructions in step 625 described above will be described in more detail. The cloud server 120 may generate sub-instructions by dividing the instruction received from the service application 110 into predetermined time units or predetermined size units.

For example, a case where the command from the service application 110 is a command to move the robot 100 to a destination will be described with reference to FIG. The destination may be a destination for the robot 100 to deliver an item or a destination for the robot 100 to guide a user.

At step 710, cloud server 120 may determine multiple waypoints through which robot 100 must travel from its current location to a destination.

At step 720, the cloud server 120 may generate instructions for moving the robot 100 to each of the waypoints as each sub-instruction, and may send each generated sub-instruction to the robot 100.

For example, the cloud server 120 may determine the coordinates (array of coordinates) of each of a plurality of waypoints at which the robot 100 must move from the current location of the robot 100 to the destination, and may provide instructions indicating movement to each coordinate. may be sent to the robot 100 as each sub-command.

Each of the waypoints may be, for example, a position in space, and if the robot 100 has to move between floors in moving to a destination, each waypoint may indicate a position in front of an elevator (i.e., in front of a door). good. The waypoint may also be a position in front of a door in the space, a position corresponding to a corner in the space, a position corresponding to a corner or corner of the space, or the like. A waypoint may or may not include a destination.

As mentioned above, after the robot 100 completes moving to a certain waypoint, the cloud server 120 may receive a completion report from the robot 100, which causes the cloud server 120 to direct the robot 100 to the next waypoint. A sub-command indicating movement to may be sent.

The robot 100 may move to a destination by being controlled according to sub-instructions corresponding to movement to a waypoint.

In this manner, instructions received from service application 110 may be embodied in movements to multiple waypoints, and embodied sub-instructions may be generated.

With reference to FIG. 8, a method for the cloud server 120 to send appropriate sub-commands to the robot 100 while monitoring the state of the robot 100 will be described.

At step 810, cloud server 120 may monitor the status of robot 100. Monitoring of the condition of robot 100 may occur in real time or near real time.

At step 820, the cloud server 120 may identify a suitable sub-instruction or generate a cancellation instruction for the previously sent sub-instruction based on the monitored state of the robot 100. Cloud server 120 may send the identified sub-instruction or cancellation instruction to robot 100.

Based on the monitored state of the robot 100, the cloud server 120 determines which sub-instructions are necessary for the robot 100 to provide the service, from among the sub-instructions generated by embodying the instructions received from the service application 110. It may be transmitted to the robot 100. For example, when it is confirmed that the robot 100 has moved to a certain waypoint, the cloud server 120 may identify a sub-instruction indicating movement to the next waypoint from among the sub-instructions, and may be sent to the robot 100.

Further, the cloud server 120 may transmit a cancellation command to the robot 100 to cancel the previously transmitted sub-command, depending on the monitored state of the robot 100. For example, if the robot 100 is unable to perform an operation according to a sub-command sent in advance (due to reasons such as the robot 100 being trapped in a particular position, malfunctioning, or becoming inoperable), In this case, the cloud server 120 may transmit a cancellation command to the robot 100 to cancel the previously transmitted sub-command. In some cases, the cloud server 120 may send the sub-instructions to other robots and control the other robots to perform the unexecuted operations instead. Alternatively, the cloud server 120 may send a postponement instruction to the robot 100 to postpone (i.e., execute later) the operation according to the previously transmitted sub-instruction.

As described above, by monitoring the state of the robot 100, the cloud server 120 can send sub-commands to the robot 100 in a timely manner, or send commands to cancel/postpone the command. .

In this regard, FIGS. 12 and 13 illustrate, in one example, a method for generating concrete sub-instructions based on abstract instructions from a service application to control a robot.

In FIG. 12, it is assumed that the robot 100 is a robot that provides a delivery service and that a command to move to a destination 1200 is received by the cloud server 120 from the service application 110.

Cloud server 120 may establish a route plan for robot 100 to move to destination 1200 based on instructions from service application 110. The cloud server 120 may determine a plurality of waypoints 1210 ((1) to (7)) included in the route for the robot 100 to move to the destination 1200, and may determine a sub-instruction 1210 indicating movement to the waypoint. -1 to 1210-7 may be generated.

The cloud server 120 sends each of the sub-commands 1210-1 to 1210-7 to the robot 100 in order, so that the robot 100 arrives at the destination 1200 via the waypoints 1210 ((1) to (7)). You can control it to do so. Each of the waypoints 1210 ((1) to (7)) may indicate the coordinate values of the corresponding position.

If the path from the current location of the robot 100 to the destination 1200 includes movement of the robot 100 between floors, at least one of the waypoints 1210 ((1) to (7)) corresponds to the elevator on which the robot 100 rides. The location may be indicated (ie, the location corresponding to the door of the elevator where the robot 100 boards and/or exits). This allows the robot 100 to move to the destination 1200, including moving between floors.

As described above, when the robot 100 is instructed to move to the destination 1200, the robot 100 may be controlled by receiving divided sub-commands (indicating waypoints) from the cloud server 1200. That is, the robot 100 may operate by receiving unit commands that can be executed at one time. Unlike abstracted instructions, a unit instruction may indicate an array of coordinates that the robot 100 can process.

In FIG. 13, it is assumed that a command to terminate the robot 100 is received by the cloud server 120 from the service application 110.

Based on the abstracted command to terminate the robot 100, the cloud server 120 (1) terminates the sensor device of the robot 100, (2) terminates the motor control of the robot 100, and (3) terminates the main system of the robot 100. You may generate three sub-instructions. The cloud server 120 may send the sub-commands (1) to (3) to the robot 100 in order. For example, the cloud server 120 sends (2) to the robot 100 when the sensor device of the robot 100 ends due to (1), and sends (3) to the robot 100 when the motor control of the robot 100 ends due to (2). You may send it. With this, the robot 100 may be terminated.

The cloud server 120 described above may be a server configured to control one function of the robot 100. For example, the cloud server 120 is a server for controlling the movement of the robot 100 as described with reference to FIG. 12, or a server for controlling the movement of the robot 100 as described with reference to FIG. It may be a server for controlling. Alternatively, cloud server 120 may be configured to control each of a plurality of functions of robot 100.

The technical features described above with reference to FIGS. 1 to 6 can also be applied to FIGS. 7, 8, 12, and 13 as they are, and therefore redundant explanations will be omitted.

9 and 10 are flowcharts illustrating a method of processing data from a robot and generating and processing abstracted data based on the data, in one example.

With reference to FIG. 9, a method in which data from the robot 100 is processed by the cloud server 120 will be described.

At step 905, cloud server 120 may receive from robot 100 data collected by robot 100 (eg, data related to control of robot 100). The data related to the control of the robot 100 may be data collected by the robot 100 while running, performing a function, or performing a service operation. For example, the data related to the control of the robot 100 is data collected by the sensor unit 106, and includes at least one of time information, speed and position of the robot 100, battery information, and video information captured by a camera. may include. Further, the data related to the control of the robot 100 may include data indicating the operating state of the device 105 related to the UX, such as the lighting state of an LED, the output state of a sound, the opening/closing state of a door of the robot 100, etc. .

At step 910, cloud server 120 may determine whether the data from robot 100 includes data to be bypassed.

In step 915, the cloud server 120 may directly route bypass target data among the data from the robot 100 to the service application 110. The bypass target data may include data indicating the first state of the robot 100. The first state may represent a simple state of the robot 100 that can be understood only from the data itself without any analysis or processing of the data. Alternatively, the first state may indicate a state of the robot 100 that requires real-time identification by the service application 110.

The first state may include, for example, the battery state, speed state, door opening/closing state, LED lighting state, and sound output state of the robot 100, and the data indicating the first state includes such battery data of the robot 100, It may include speed data, data regarding door opening/closing status, data regarding LED lighting status, and data regarding sound output status.

Data indicating such a first state of the robot 100 may be communicated directly to the service application 110, where the first state of the robot 100 may be identified. The service application 110 may generate monitoring information for the robot 100 by identifying the first state of the robot 100. Monitoring information may be displayed/output at device 500.

At step 925, cloud server 120 may analyze data from robot 100 to generate abstracted data. The cloud server 120 may analyze data from the robot 100 that is not bypass target data or data from the robot 100 that includes bypass target data among the data from the robot 100 and generate abstracted data. “Data abstraction” may be a stage of generating processed data by analyzing raw data. For example, the abstracted data is data indicating whether the robot 100 falls under a specific state based on the result of determining whether the robot 100 falls under a specific state while analyzing data from the robot 100. It's fine.

This will be explained in more detail as a method of generating abstracted data with reference to FIG.

The following steps 1010-1040 may be included in step 925.

At step 1010, cloud server 120 may analyze data from robot 100.

At step 1020, cloud server 120 may analyze data from robot 100 and determine whether robot 200 exhibits a second state.

At step 1030, the cloud server 120 may generate abstracted data indicating that the robot 100 is in the second state if it is determined that the robot 100 exhibits the second state. Alternatively, in step 1040, if it is determined that the robot 100 does not fall into the second state, the cloud server 120 may generate abstracted data indicating that the robot 100 is not in the second state.

In other words, the cloud server 120 may generate information indicating whether the robot 100 exhibits the second state as abstracted data based on the result of such determination.

At step 930, cloud server 120 may send the generated abstracted data to service application 110.

The data from the robot 100 analyzed in step 1010 may include data indicative of the first state described above and/or may additionally include data sensed by the sensor unit 106. The second state may refer to a state of the robot 100 that the cloud server 120 determines to be applicable to the robot 100 by analyzing such data. For example, the second state may indicate whether the robot 100 has completed providing the service, whether the robot 100 is capable of providing the service, or whether the robot 100 is operating normally. In other words, the second state may indicate the state of the robot 100 determined by the cloud server 120 based on data from the robot 100.

Specifically, when the cloud server 120 analyzes that the position of the robot 100 does not change for a certain period of time or more, the cloud server 120 determines whether the robot 100 is trapped, cannot operate properly, or cannot provide services. Abstracted data may be generated to indicate that something is no longer possible (or that it took a lot of time to provide a service).

At step 935, service application 110 may identify that robot 100 falls into the second state based on the received abstracted data.

The service application 110 generates instructions for controlling the robot 100 based on the received abstracted data (or the second state of the robot 100 is identified), as in step 940. good. Or/additionally, the service application 110 may generate monitoring information for the robot 100 based on the received abstracted data (or due to the second state of the robot 100 being identified).

The monitoring information may be information indicating the first state and/or second state of the robot 100 described above. Monitoring information may be displayed/output to device 500.

The instructions sent to the cloud server 120 at step 940 may correspond to the abstracted instructions described with reference to step 610 of FIG. On the other hand, although not shown in the figure, the service application 110 may also generate instructions for controlling the robot 100 when the first state described above is identified.

The technical features described above with reference to FIGS. 1 to 8, FIG. 12, and FIG. 13 can also be applied to FIGS. 9 and 10 as they are, and thus redundant explanations will be omitted.

FIG. 11 is a flowchart illustrating, in one example, a method for generating and processing independent commands that are independently provided to a robot from the cloud server side.

At step 1110, cloud server 120 may generate independent instructions for controlling robot 100 independently of instructions (abstracted instructions) from service application 110.

At step 1120, cloud server 120 may send independent instructions to robot 100 or other robots.

The independent command may be a command generated by the cloud server 120 to control the robot 100 regardless of the service application 110. The independent command is related to the operation and function execution of the robot 100, and may be a command related to the operation and function execution that is independent of the service provided by the robot 100.

For example, the independent commands include a command to request the robot 100 to charge (for example, a command to move to a charging position in space), a command to update the route of movement of the robot 100 to a specific point (for example, a destination or An instruction to update the route to a specific waypoint (traveling recovery instruction), or an instruction to request another robot to provide the corresponding service when the robot 100 is unable to provide the service. may be included.

In addition, when the cloud server 120 controls multiple robots, it may switch a specific robot providing a service to provide another service, or change the robot providing a service to another robot. Instructions related to resource management may be independent instructions.

The technical features described above with reference to FIGS. 1 to 10, FIG. 12, and FIG. 13 can also be applied to FIG. 11 as they are, and thus redundant explanations will be omitted.

FIG. 14 is a diagram showing an N:1:K relationship among a cloud server, a robot, and a service application in an example.

As shown in the figure, there may be multiple service applications 110. The service applications 110-1 to 110-N may be implemented so that different robots 100 provide services. N may be a natural number of 2 or more. The cloud server 120 may receive abstracted instructions from each of the service applications 110-1 to 110-N, and may control the robot 100 to perform operations corresponding to the received abstracted instructions. .

As shown in the figure, there may be a plurality of robots 100. Each of the robots 100-1 to 100-K may be configured to provide at least one of the services provided by the service applications 110-1 to 110-N. The robots 100-1 to 100-K may be matched with the service applications 110-1 to 110-N in a 1:many or many:1 relationship. That is, a plurality of robots 100-1 to 100-K may be controlled by one service application, and one robot may be configured to provide services related to a plurality of service applications 110-1 to 110-N. good.

For example, each of the robots 100-1 to 100-K is enabled by plugging in at least one of the service applications 110-1 to 110-N to the robot. It may be implemented to provide a service in conjunction with a service application provided by the service provider. In other words, by plugging the service application 110 into the robot 100, the robot 100 may be implemented to cooperate with the service application 110 to provide services related to the service application 110.

The cloud server 120 allows other service applications among the plurality of service applications 110-1 to 110-N to be plugged into the robot 100, so that the robot 100 can cooperate with other service applications and perform other service applications. May be controlled to provide services.

Accordingly, as shown in the figure, in embodiments, a robot 100 that is implemented to provide one service may be adapted to provide other services (or may additionally be adapted to provide other services). 100 can be easily switched. In other words, it is possible to easily ensure that the robot 100 provides the service.

The technical features described above with reference to FIGS. 1 to 13 can also be applied to FIG. 14 as they are, so duplicate explanations will be omitted.

FIG. 15 is a diagram illustrating the relationship between a cloud server, a robot, and a service application in terms of data flow in one example.

In terms of data flow, cloud server 120, robot 100, and service application 110 may be interconnected.

The robot 100 and the service application 110 communicate instructions and data from the cloud server 120, but the instructions to be bypassed and the data to be bypassed are directly transmitted between the robot 100 and the service application 110. Here, cloud server 120, robot 100, and service application 110 may be considered to be coupled to each other.

The technical features described above with reference to FIGS. 1 to 14 can also be applied to FIG. 15 as they are, so redundant explanations will be omitted.

The apparatus described above may be realized by hardware components, software components, or a combination of hardware and software components. For example, the devices and components described in the embodiments include, for example, a processor, a controller, an arithmetic logic unit (ALU), a digital signal processor, a microcomputer, a field programmable gate array (FPGA), a programmable logic unit (PLU), and a microcomputer. The implementation may be implemented using one or more general purpose or special purpose computers, such as a processor or various devices capable of executing and responding to instructions. A processing device may execute an operating system (OS) and one or more software applications that execute on the OS. The processing device may also be responsive to execution of the software to access, record, manipulate, process, and generate data. Although for convenience of understanding, one processing device may be described as being used, those skilled in the art will appreciate that a processing device may include multiple processing elements and/or multiple types of processing elements. You will understand. For example, a processing device may include multiple processors or a processor and a controller. Other processing configurations are also possible, such as parallel processors.

Software may include computer programs, code, instructions, or a combination of one or more of these that configure a processing device or instruct a processing device, independently or collectively, to perform operations as desired. You may do so. The software and/or data may be persistent on any machine, component, physical device, virtual device, computer storage medium or device of any kind to be interpreted by or to provide instructions or data to a processing device. It may be realized temporarily or temporarily. The software may be distributed on computer systems connected by a network, and may be recorded or executed in a distributed manner. The software and data may be recorded on one or more computer readable storage media.

Methods according to embodiments may be implemented in the form of program instructions executable by various computer means and recorded on computer-readable media. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the medium may be those specially designed and configured for the embodiments, or may be those known and available to those skilled in the art of computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs and DVDs, and floptical disks. Includes magneto-optical media, and hardware devices specifically configured to record and execute program instructions, including ROM, RAM, flash memory, and the like. Examples of program instructions include machine language code, such as that produced by a compiler, as well as high-level language code that is executed by a computer using an interpreter or the like.

As mentioned above, although the embodiments have been described based on limited embodiments and drawings, those skilled in the art will be able to make various modifications and variations based on the above description. For example, the techniques described may be performed in a different order than in the manner described, and/or components of the systems, structures, devices, circuits, etc. described may be performed in a different form than in the manner described. Even when combined or combined, opposed or replaced by other components or equivalents, suitable results can be achieved.

Therefore, even if the embodiments are different, if they are equivalent to the scope of the claims, they fall within the scope of the appended claims.

100: Robot 102: Communication unit 104: Control unit 106: Sensor unit 108: Drive unit 110: Service application 120: Cloud server 211: Route planning processing module 212: Mapping processing module 213: Drive control module 214: Localization processing module 215: Data processing module 216: Instruction processing module

Claims (18)

A method for controlling a robot that provides a service in conjunction with a service application executed by a cloud server, the method comprising:
receiving instructions for providing the service from the service application;
generating a plurality of sub-commands by embodying the received command; and transmitting each sub-command of the sub-commands to the robot;
the instructions from the service application are abstracted instructions that cannot directly control the robot to provide the service;
Each of the sub-commands is a concrete command of the abstracted command so that the robot can be directly controlled;
A robot control method, wherein the robot is controlled based on each of the received sub-commands. further comprising determining whether the instruction from the service application is a bypass target instruction;
2. The robot control method according to claim 1, wherein the step of generating the sub-instruction is executed when the instruction from the service application is not a bypass target instruction. If the command from the service application is a bypass target command, the method further includes transmitting the command from the service application directly to the robot;
The robot control method according to claim 2, wherein the robot is controlled based on the transmitted command. 4. The robot control method according to claim 3, wherein the bypass target command is a command for controlling a configuration related to a UX (User Experience) of the robot. Each of the sub-instructions is a unit instruction that can be executed by the robot,
2. The robot control method according to claim 1, wherein in the step of generating the sub-instruction, the sub-instruction is generated by dividing the received instruction into a plurality of unit instructions. The command from the service application is a command to move the robot to a destination,
The step of generating the sub-instructions includes:
determining a plurality of waypoints through which the robot should move from its current location to the destination; and sending instructions to the robot to move the robot to each of the waypoints as each of the sub-instructions. including the step of transmitting;
6. The robot control method according to claim 5, wherein the robot moves to the destination by being controlled according to the sub-instruction corresponding to movement to the waypoint. The step of transmitting each of the sub-commands includes transmitting each of the sub-commands in order,
transmitting a first sub-command of the sub-commands to the robot;
after the control of the robot by the first sub-instruction is completed, receiving a completion report from the robot; and after receiving the completion report, the next one of the sub-instructions after the first sub-instruction The robot control method according to claim 1, comprising: transmitting a second sub-command to the robot. The step of transmitting each sub-command includes:
monitoring the state of the robot; and based on the state of the robot, transmitting to the robot a sub-command that is necessary for the robot to provide the service, or transmitting a sub-command that has been previously transmitted to the robot. The robot control method according to claim 1, comprising the step of: transmitting a cancellation command to the robot to cancel the sub-command. receiving data related to the robot from the robot;
determining whether data from the robot includes bypass target data indicating a first state of the robot;
If the data from the robot includes the data to be bypassed, directly transmitting the data to be bypassed to the service application;
generating abstracted data based on data that is not the bypass target data among the data from the robot, and transmitting the generated abstracted data to the service application;
further including;
Based on the abstracted data, the service application generates instructions for controlling the robot or generates monitoring information for the robot ,
The robot control method according to claim 1 , wherein the service application identifies a first state of the robot based on the bypass target data . The step of generating the abstracted data includes:
analyzing data from the robot to determine whether the robot exhibits a second state; and the result of the determination determines whether the robot exhibits a second state. The robot control method according to claim 9 , comprising the step of transmitting data to the service application. further comprising: generating an independent command to control the robot independently of commands from the service application; and transmitting the independent command to the robot or another robot,
The independent command may be a command to request the robot to charge, a command to update the route of movement of the robot to a particular point, or a command to perform the other command when the robot is no longer able to provide the service. The robot control method according to claim 1, further comprising an instruction to request the robot to provide the service. The service application is realized on a server or a client that is separated from the robot via a network,
The robot control method according to claim 1, wherein each of the sub-instructions sent to the robot does not include context information associated with the service. The service application is plugged into the robot, so that the robot is realized to cooperate with the service application to provide the service,
The service applications are plural;
The cloud server allows other service applications among the plurality of service applications to be plugged in with the robot, so that the robot cooperates with the other service applications to provide other services. The robot control method according to claim 12 . The robot control method according to claim 12 , wherein different security policies are set for the service application, the cloud server, and the robot. A method for controlling a robot that provides a service in conjunction with a cloud server and a service application, the method comprising:
receiving, from the cloud server, each sub-instruction of a plurality of sub-instructions generated by embodying the instruction for providing the service transmitted from the service application to the cloud server; and controlling the robot based on each of the sub-commands;
The service application is realized on a server or a client that is separated from the robot via a network,
the instructions from the service application are abstracted instructions that cannot directly control the robot to provide the service;
Each of the sub-commands is a concrete command of the abstracted command so that the robot can be directly controlled;
The robot control method, wherein each of the sub-commands sent to the robot does not include context information associated with the service. further comprising: collecting data related to controlling the robot; and transmitting the collected data to the cloud server;
The data sent to the cloud server is analyzed by the cloud server, processed into abstracted data, and sent to the service application,
16. Robot control according to claim 15 , wherein the service application generates an instruction for controlling the robot or generates information indicating monitoring information of the robot based on the abstracted data. Method. The robot is realized to provide the service in cooperation with the service application by being plugged in with the service application,
15. The robot is controlled to provide another service in cooperation with the other service application by plugging in another service application other than the service application by the cloud server. Robot control method described in. A cloud server that controls a robot that provides services in conjunction with a service application,
at least one processor implemented to execute computer-readable instructions;
The at least one processor includes:
receiving an instruction for providing the service from the service application, embodying the received instruction to generate a plurality of sub-instructions, and transmitting each sub-instruction of the sub-instructions to the robot;
the instructions from the service application are abstracted instructions that cannot directly control the robot to provide the service;
Each of the sub-commands is a concrete command of the abstracted command so that the robot can be directly controlled;
A cloud server, wherein the robot is controlled based on each of the received sub-instructions.

Images