Method and apparatus for processing occupancy of stopover node of robot for transportation

Abstract

Disclosed are a method and an apparatus for processing the occupancy of a stopover node of a robot for transportation. A method for processing the occupancy of a stopover node of a robot by a robot management server according to an embodiment of the present invention may comprise the steps of: receiving occupancy request information from a robot when the robot moves to a stopover node according to a pre-generated work plan; assigning a standby position on the basis of the occupancy request information, determining whether to permit the occupancy on the basis of a standby state, and transmitting occupancy permission information to the robot so that the stopover node is occupied; and receiving occupancy release information when the robot leaves the stopover node.

Description

Method and device for handling the occupation of a waypoint node by a robot for transportation

[0001] The present invention relates to a method and device for handling the occupancy of a waypoint node by a robot for transportation. The research of the present invention is related to the "Development of an Intelligent Manufacturing Logistics System Based on Autonomous Mobile Manipulation" (No. 1711193750 (No. 2022-0-01010)), a smart manufacturing innovation technology development project conducted by Yujin Robot Co., Ltd. with support from the National IT Industry Promotion Agency (NIPA) and funding from the Ministry of Science and ICT (MSIT).

[0002] The material described in this section merely provides background information on embodiments of the present invention and does not constitute prior art.

[0003] As production systems have become increasingly larger and more complex, most equipment is becoming automated and unmanned. This has led to a growing demand for autonomous transport robots, or unmanned transport robots, for transporting and storing materials and automatically transporting cargo.

[0004] Autonomous transport robots are used to load cargo onto their bodies and automatically transport them to designated locations. Initially, their use was limited to transporting materials in manufacturing sites such as factories. However, with the development of industries such as semiconductors, displays, steel, and automobiles, the demand for unmanned automation is increasing in these industries, including factories and logistics centers, and their use is increasing.

[0005] In general, there are limitations to autonomous transport robots being able to reach their destinations using only movement commands.

[0006] As a transport robot moves according to a movement command, modifications to the preset path plan may be required.

[0007] Additionally, in order for a transport robot to move to its destination, it may need to pass through automatic doors or elevators along its route, wait for a specific area to pass through sequentially, or receive permission through communication with a control system.

[0008] In the past, there was the inconvenience of having to implement a separate algorithm for path movement in areas where the robot had to pass through automatic doors or elevators on the path or to pass through specific areas sequentially, or the user had to manually control the path movement of the transport robot.

[0009] The main purpose of the present invention is to provide a method and device for processing occupancy of a waypoint node by a robot for transportation, in which a robot moves to a waypoint node, assigns a waiting position based on occupancy request information received from the robot, determines whether occupancy is permitted based on the waiting status, and transmits occupancy permission information to the robot so that the waypoint node is occupied, but when the robot leaves the waypoint node, occupancy release information is received.

[0010] According to one aspect of the present invention, in a method for performing a process of occupying a waypoint node of a robot in a robot management server for achieving the above object, the method of occupying a waypoint node of a robot may include the steps of: receiving occupancy request information from the robot when the robot moves to the waypoint node according to a pre-generated work plan; allocating a waiting position based on the occupancy request information, determining whether to permit occupancy based on a waiting state, and transmitting occupancy permit information to the robot so that the waypoint node is occupied; and receiving occupancy release information when the robot leaves the waypoint node.

[0011] In addition, according to another aspect of the present invention, in a robot task management server for achieving the above object, the robot task management server may include a memory storing one or more programs for performing a process of occupying a waypoint node of a robot; and one or more processors for performing operations for performing a process of occupying a waypoint node of a robot according to the one or more programs, wherein the operations performed by the processor may include a step of receiving occupancy request information from the robot when the robot moves to a waypoint node according to a pre-generated work plan; a step of allocating a waiting position based on the occupancy request information, determining whether to permit occupancy based on a waiting state, and transmitting occupancy permit information to the robot so that the waypoint node is occupied; and a step of receiving occupancy release information when the robot leaves the waypoint node.

[0012] As described above, the present invention has the advantage that, from the user's perspective, when creating task information to be performed by an autonomous driving robot, a detailed plan required for the actual task is automatically added by simply writing a movement command to a destination in the GUI, thereby making the task creation process intuitive and simplified in line with the user's intention and reducing the creation time.

[0013] In addition, the present invention has the effect of reducing the difficulty of writing software (SW) and reducing implementation costs by providing a simplified API for the movement function of an autonomous robot when writing an external application program for professionally utilizing a robot service in a field (domain) where the service is operated.

[0014] FIG. 1 is a block diagram schematically illustrating a transportation operation management system according to an embodiment of the present invention.

[0015] FIG. 2 is a block diagram schematically illustrating a robot management server according to an embodiment of the present invention.

[0016] Figures 3 and 4 are block diagrams schematically showing a robot for transportation according to an embodiment of the present invention.

[0017] FIG. 5 and FIG. 6 are flowcharts for explaining a method for generating work information for transportation according to an embodiment of the present invention.

[0018] FIG. 7 and FIG. 8 are flowcharts for explaining a method for processing occupancy of a robot's waypoint node according to an embodiment of the present invention.

[0019] Figures 9 to 11 are exemplary diagrams for explaining the operation of generating work information for transport work management according to an embodiment of the present invention.

[0020] FIG. 12 and FIG. 13 are exemplary diagrams for explaining a transit node occupancy processing operation according to an embodiment of the present invention.

[0021] Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the attached drawings. In describing the present invention, detailed descriptions of related known structures or functions will be omitted if they are judged to obscure the gist of the present invention. Furthermore, although preferred embodiments of the present invention will be described below, it should be understood that the technical spirit of the present invention is not limited thereto and can be modified and implemented in various ways by those skilled in the art. Hereinafter, with reference to the drawings, a method and device for processing the occupancy of a waypoint node of a robot for transportation proposed in the present invention will be described in detail.

[0022] FIG. 1 is a block diagram schematically illustrating a transportation operation management system according to an embodiment of the present invention.

[0023] The transportation operation management system according to the present embodiment includes a user terminal (100), a robot management server (200), a robot (300), and a communication network (400). The transportation operation management system of FIG. 1 is according to one embodiment, and not all blocks illustrated in FIG. 1 are essential components. In other embodiments, some blocks included in the transportation operation management system may be added, changed, or deleted.

[0024] A transportation task management system is a system that creates and manages task information for transportation tasks of autonomous robots.

[0025] The transportation operation management system is preferably applied to a logistics management warehouse or center, but is not necessarily limited thereto.

[0026] The user terminal (100) refers to a user-operable device for managing transportation operations.

[0027] The user terminal (100) is a front-end terminal, i.e., a computing device located on the user side, and is a device including a user interface, such as a display screen, that can check the work plan of the robot (300).

[0028] The user terminal (100) can receive the work progress status and work performance results of the robot (300) from the robot management server (200) and display them on the display screen.

[0029] The user terminal (100) can provide a UI (path inspector) that allows the user to check the detailed path plan, since the automatically established detailed path plan varies depending on the type and location of the resource placed on the path of the robot (300).

[0030] The user terminal (100) may include a processing unit, memory, a display unit, a communication module, and the like. In particular, the user may communicate with the robot management server (200) and the robot (300) through the user terminal graphical user interface, and may easily check the work plan, the robot's current status, route information, and logistics status information through the display screen.

[0031] The user terminal (100) can receive user requirement information through a display unit or the like, and generate work request information by further considering the current status of the robot (300) and the situation of the work site.

[0032] The robot management server (200) is a server (Service Platform server) that manages services related to work robots and logistics robots.

[0033] The robot management server (200) performs overall control and management of the robot (300) for transportation.

[0034] The robot management server (200) according to this embodiment is preferably an FMS (Fleet management system) server, but is not necessarily limited thereto.

[0035] The robot management server (200) receives task request information that the robot (300) must perform from the user terminal (100).

[0036] The robot management server (200) performs a work structure analysis of the work environment based on the received work request information, determines a robot (300) to perform the work and a plurality of nodes included in the travel path of the robot (300) according to the work structure analysis, and generates a work report including movement path information for traveling the link section between nodes.

[0037] The robot management server (200) assigns a task to a robot (300) based on a task report, establishes a detailed path plan based on an initial plan received from the robot (300) to which the task is assigned, transmits the generated modified plan to the robot (300), and stores the task plan based on the modified plan.

[0038] The robot management server (200) transmits the work progress status and work performance results of the robot (300) to the user terminal (100).

[0039] Meanwhile, the robot management server (200) according to another embodiment of the present invention can receive occupancy request information from the robot (300) by moving the robot (300) to a transit node based on a work plan.

[0040] The robot management server (200) assigns a waiting position based on the received occupancy request information, determines whether occupancy is permitted based on the waiting status, and transmits occupancy permission information to the robot (300) to ensure that the transit node is occupied.

[0041] The robot management server (200) receives occupancy release information when the robot (300) leaves the transit node.

[0042] A detailed description of the robot management server (200) is described in Fig. 2.

[0043] The robot (300) refers to a mobile robot that performs tasks for transporting logistics. Here, the robot (300) may be defined as an autonomous driving robot, a logistics robot, a transport robot, a mobile robot, a lifting robot, etc. The robot (300) may be implemented as a robot vacuum cleaner, a logistics robot, a toy car, a mobile robot for industrial or military purposes, etc., but is not necessarily limited thereto.

[0044] The robot (300) performs work based on a work plan created in conjunction with the robot management server (200).

[0045] The robot (300) is assigned a task from the robot management server (200), determines an initial plan through task analysis, and saves the task plan.

[0046] Meanwhile, the robot (300) can request a modification plan from the robot management server (200) or create a modification plan on its own.

[0047] When the robot (300) receives a modification plan from the robot management server (200), it verifies the modification plan and updates the work plan by reflecting the verified modification plan.

[0048] The robot (300) moves and performs work based on a work plan.

[0049] Meanwhile, a robot (300) according to another embodiment of the present invention moves to a transit node based on a work plan and transmits occupancy request information to a robot management server (200).

[0050] The robot (300) is assigned a waiting position from the robot management server (200) and moves to the waiting position.

[0051] When the robot (300) receives occupancy permission information from the robot management server (200), it occupies the transit node. Here, the robot (300) can pass through the transit node.

[0052] When the robot (300) leaves the transit node, it transmits occupancy release information to the robot management server (200).

[0053] A detailed description of the robot (300) is given in Fig. 3.

[0054] The communication network (400) relays communication for linkage between the user terminal (100), the robot management server (200), and the robot (300). The communication network (400) may be a network composed of mobile communication, short-range communication, an intranet, etc.

[0055] FIG. 2 is a block diagram schematically illustrating a robot management server according to an embodiment of the present invention.

[0056] The robot management server (200) is a service platform server that manages services related to work robots and logistics robots. The robot management server (200) includes a processor, memory, a communication unit, and other components that perform such service management. In particular, the processor may include a first processor (210) that executes tasks for core services and a second processor (220) related to the general operation of the server.

[0057] The first processor (210) can perform site configuration and task scheduling operations for executing site configuration operations. The second processor (220) can plan the path of the robot (300) and perform operations related to calculations and control for traffic control. Of course, the processor configuration is not limited to this, and all execution operations may be performed by a single integrated processor, or each individual task may be implemented in a form in which separate processors perform parallel processing.

[0058] The first processor (210) associated with the core service performs a structural analysis of the task and determines the destination node and the transit node among the nodes existing on the path. More specifically, the first processor (210) can generate a shortest path plan from the current location of the robot (300) to the destination. In the shortest path plan, it can be determined whether to use resources (e.g., automatic doors, elevators, traffic control areas, etc.) that must be sequentially occupied by each robot (300) or that require interoperability with other systems.

[0059] The first processor (210) generates a detailed route plan related to the above-determined matters, particularly entry, exit, and waiting related to the transit node (including resources) and the destination node. For example, the route plan may include the logistics robot's waiting time, waiting location, entry priority, exit method, exit timing, definition of uncertain events, and response actions in the event of an uncertain event.

[0060] The first processor (210) can generate work information including work request information input by the user and information including the above-described path plan, and transmit the generated work information to the robot (300) through the communication unit.

[0061] The first processor (210) may further generate linkage tasks required for linkage with the robot management server (200) or external systems (e.g., elevators, automatic doors, PLCs, PCs, etc.) when using each resource, and transmit these to the robot (300).

[0062] The robot (300) can analyze the work information received from the robot management server (200), and, by further considering the work request information, generate a job revision plan that modifies or adds detailed work. The robot (300) can transmit the generated job revision plan to the robot management server (200).

[0063] Meanwhile, the work modification plan is described as being generated by the robot (300), but is not necessarily limited thereto, and the work modification plan may be generated by the first processor (210) and then transmitted to the robot (300).

[0064] The process of generating task information performed by the first processor (210) and generating a task modification plan performed by the robot (300) may be performed for each unit link connecting nodes, or may be performed or updated for each cluster link, which is a collection of unit links. Furthermore, even for unit links, a single unit link may be composed of multiple sub-links depending on the driving situation.

[0065] A sub-link divides a single unit link into multiple sub-links. To specify a sub-link, the robot (or robot management server) can determine a temporary virtual node by considering the robot's driving environment. For example, if a congestion situation occurs during driving and the uncertainty value of a task exceeds a predetermined threshold, the robot (300) can determine a specific point located along the path as a virtual node and update the path of the virtual node and the path plan.

[0066] In this embodiment, the uncertainty of the task may include inherent uncertainty caused by internal reasons of the robot (300) itself, external uncertainty caused by external factors, uncertainty of a user request due to ambiguity of the user's requested task itself, and complex factor uncertainty caused by at least two or more of the above-described uncertainties. The uncertainty score for each uncertainty may be calculated by an uncertainty model for each factor. The uncertainty model may be implemented in software form and executed by a processor of a user terminal or a processor of a server. In addition, it may be implemented to be executed by a separately added processing unit to calculate the uncertainty score.

[0067] Hereinafter, the operation of generating work information of the robot management server (200) according to another embodiment of the present invention will be described.

[0068] The robot task management server (100) receives task request information that the robot (300) must perform. Here, the robot task management server (100) may receive task request information from the user terminal (100). The task request information may include information about the starting point and destination for the task.

[0069] The robot task management server (100) performs task structure analysis for the task environment based on the received task request information.

[0070] Specifically, the robot task management server (100) searches for a plurality of candidate robots located within a predetermined reference distance from a location specified based on task request information. Thereafter, the robot task management server (100) obtains local environment information according to the location of each candidate robot, calculates a score for the task performance capability of each candidate robot for the task based on the task request information, and predicts the task performance capability.

[0071] Here, the score for task performance ability can be calculated by considering the task start time, task performance time, destination arrival time, task success probability, etc. For example, the robot task management server (100) can calculate points for each candidate robot's task start time, task performance time, destination arrival time, and task success probability, and process the calculated points through preset calculations (sum, average, variance, etc.) to calculate a score for task performance ability.

[0072] The robot task management server (100) determines a robot (300) to perform a task and a plurality of nodes included in the driving path of the robot (300) based on task structure analysis, and generates a task report including movement path information for driving the link section between nodes.

[0073] Specifically, the robot task management server (100) determines a robot (300) to perform a task based on a score among a plurality of candidate robots, and determines a plurality of nodes included in the travel path of the robot (300). Here, the robot task management server (100) determines the candidate robot with the highest score as the robot (300), but may additionally check whether a resource (e.g., an automatic door, an elevator, a traffic control area, etc.) exists on the travel path of the candidate robot, and may adjust the score according to the type and passage time of the resource before determining the robot (300).

[0074] Thereafter, the robot task management server (100) generates an action report including movement path information for link sections between nodes included in a plurality of nodes.

[0075] The robot task management server (100) assigns tasks to robots (300) based on task reports.

[0076] The robot task management server (100) establishes a detailed path plan based on the initial plan received from the robot (300) to which the task is assigned, transmits the generated modified plan to the robot, and stores the task plan based on the modified plan.

[0077] Specifically, the robot task management server (100) obtains a task analysis result for a task assigned from a robot (300) and an initial plan determined based on the task analysis result.

[0078] If modifications to the initial plan are required, the robot task management server (100) establishes a detailed path plan and applies the detailed path plan to the initial plan to generate a modified plan. Modifications to the initial plan may be required when, upon reviewing the task analysis results and the initial plan, it is determined that the robot (300) cannot perform the task with the initial plan, or when a request for modifications to the initial plan is received from the robot (300).

[0079] The robot task management server (100) determines whether it is possible to move from the current location of the robot (300) to the destination of the initial plan and whether it is possible to perform the task of the current plan in addition to movement-related commands, thereby establishing a detailed path plan and generating a modification plan.

[0080] Meanwhile, in the case of inter-floor movement (elevator), the robot task management server (100) creates a revision plan by recursively establishing a detailed route plan by repeating the process of adding a map transition and revising the plan from getting off at the destination floor to the destination until the problem is eliminated.

[0081] The robot task management server (100) can establish a detailed path plan by modifying the path plan included in the task information in consideration of the environmental information acquired from the location of the robot (300). Meanwhile, the robot task management server (100) can also establish a detailed path plan by adding virtual nodes between nodes located on the task path specified in the path plan and further generating a detailed driving plan according to the virtual nodes.

[0082] When the modification plan is verified, the robot task management server (100) stores the task plan created based on the modification plan.

[0083] Specifically, the robot task management server (100) transmits a modification plan to the robot (300) for verification, and receives an updated task plan from the robot (300) based on the verified modification plan. The robot task management server (100) stores the received task plan.

[0084] Hereinafter, the operation of processing the occupancy of a transit node of a robot for transportation by a robot management server (200) according to another embodiment of the present invention will be described.

[0085] When a robot (300) moves to a stopover node according to a previously generated work plan, the robot management server (200) receives occupancy request information from the robot (300). Here, the stopover node refers to a resource placed on the robot's (300) movement path according to the work plan. The resource may include at least one of an automatic door, an elevator, and a traffic control area.

[0086] The robot management server (200) includes the current location and resource information of the robot (300). Here, the resource information may include the type and location of the resource.

[0087] The robot management server (200) allocates a waiting position based on the occupancy request information, determines whether to permit occupancy based on the waiting status, and transmits the occupancy permit information to the robot (300) to ensure that the transit node is occupied.

[0088] The robot management server (200) selects one of the candidate waiting locations within a preset distance from the transit node and assigns it as the waiting location of the robot (300).

[0089] Specifically, the robot management server (200) searches for candidate waiting locations around the waypoint node, excludes candidate waiting locations already assigned to a given robot from the search results, and then assigns the candidate waiting location closest to the current location of the robot (300) as the waiting location.

[0090] When there is only one robot (300) in standby mode, the robot management server (200) transmits occupancy permission information to the robot (300).

[0091] Meanwhile, if there are multiple robots (300) in a standby state, the robot management server (200) can determine the occupation priority for the multiple robots and transmit occupation permission information to each of the multiple robots (300) so that the transit node is occupied according to the determined occupation priority.

[0092] The robot management server (200) can determine the occupation priority using the first score for the width of the overlapping area of ​​the waiting area of ​​the waiting position and the robot waiting in the waiting area.

[0093] The robot management server (200) can determine the occupation priority using the second score for the shortest distance between the center of the transit node and the waiting robot.

[0094] The robot management server (200) can determine the occupation priority using the third score for the angle between the center of the waypoint node and the direction of travel of the waiting robot.

[0095] Although the robot management server (200) is described as determining the occupancy priority using one of the first, second, and third scores, it is not necessarily limited to this. For example, the robot management server (200) may also determine the occupancy priority by calculating (summing, averaging, variance, etc.) the first, second, and third scores.

[0096] When a robot (300) leaves a transit node, the robot management server (200) receives de-occupancy information. After receiving the de-occupancy information, the robot management server (200) may transmit a modification plan to the robot (300) for updating the work plan when a request for occupancy for a new transit node is received from the robot (300) or when the robot (300) moves to a new transit node.

[0097] Figures 3 and 4 are block diagrams schematically showing a robot for transportation according to an embodiment of the present invention.

[0098] FIG. 3 is a block diagram illustrating a robot (300) for transportation according to an embodiment of the present invention.

[0099] The robot (300) receives work information (work report) generated from the robot management server (200) and determines an initial plan to be performed at the current location. The robot (300) executes operations according to a work plan corresponding to the determined initial plan.

[0100] If the robot (300) cannot perform a task with the initial plan, it receives a modification plan from the robot management server (200) and updates the task plan with the received modification plan.

[0101] The robot (300) updates the results of the work performed according to the execution of the movement and transmits them to the robot management server (200) or the user terminal (100).

[0102] In this embodiment, candidate robots may be multiple robots selected based on the location, route, and congestion conditions of the origin-destination nodes. The robot management server (200) may select a robot close to the origin as a candidate robot, or a robot with sufficient resources for logistics transport as a candidate robot.

[0103] The above-described steps may be repeatedly performed until the robot (300) reaches its destination. The robot (300) may repeatedly perform the process of generating an updated work plan by updating the current work plan and the modified plan generated by considering environmental information collected in real time.

[0104] The update process for the work plan may include adding virtual nodes between nodes, changing a waypoint node to another waypoint node considering congestion conditions, or modifying driving information between nodes (e.g., speed, time to reach waypoint node management).

[0105] The robot (300) according to the present embodiment includes a work control module (310) and a movement control module (320). The robot (300) of FIG. 2 is according to one embodiment, and not all blocks illustrated in FIG. 2 are essential components, and some blocks included in the robot (300) in other embodiments may be added, changed, or deleted.

[0106] The job control module (310) obtains job assignment information from the robot management server (200), performs job analysis for the assigned job and determines an initial plan, and then saves the job plan.

[0107] Meanwhile, when the work control module (310) obtains a modification plan from the robot management server (200), it verifies the modification plan and updates the work plan based on the verified modification plan.

[0108] The work control module (310) according to another embodiment of the present invention transmits occupancy request information to the robot management server (200) while moving to a transit node.

[0109] The job control module (310) is assigned a standby position from the robot management server (200) and moves to the standby position.

[0110] The job control module (310) occupies a transit node when it receives occupancy permission information from the robot management server (200).

[0111] When the work control module (310) leaves the transit node, it transmits occupation release information to the robot management server (200).

[0112] The movement control module (320) performs an operation to control the movement of the robot (300). The movement control module (320) according to the present embodiment may include a motion control unit (322), a motor (324), and a wheel assembly (326).

[0113] The motion control unit (322) is connected to the main body and can be implemented to move the robot (300), and can calculate a driving path based on the distance to the target object or detect an obstacle to move the robot (300).

[0114] The motion control unit (322) moves the robot (300) in conjunction with the motor (324) and the wheel assembly (326). Here, the wheel assembly (326) may include main wheels, auxiliary wheels, rails, legs, etc. In addition, the motion control unit (322) may include an odometry measurement sensor that detects movement changes, but is not necessarily limited thereto.

[0115] FIG. 4 is a block diagram schematically showing the hardware configuration of a work control module (310) included in a robot (300) for transportation according to an embodiment of the present invention.

[0116] FIG. 4 is a block diagram illustrating the hardware configuration of a job control module (310) for illustrating a computing environment including a computing device suitable for use in preferred embodiments of the present invention.

[0117] The task control module (310) may be implemented as a computing device, such as a smart phone, a personal computer (PC), a tablet PC, a personal digital assistant (PDA), a laptop, etc., but is not necessarily limited thereto.

[0118] The job control module (310) may include a memory that stores a processor and a program executed by the processor, and may generate commands for processing the creation or update of a job plan and processing the occupancy of a transit node in the processor, and may provide information for processing the creation or update of a job plan and processing the occupancy of a transit node using the generated commands.

[0119] The job control module (310) may include a database. A database refers to a data storage format that allows for free searching, extracting, deleting, editing, adding, etc. of data. The database may be implemented to suit the purpose of the present embodiment using Oracle, Informix, Sybase, a Relational Data Base Management System (RDBMS), Gemston, Orion, an Object Oriented Database Management System (OODBMS), a distributed database, a cloud, etc.

[0120] In the embodiment illustrated in FIG. 4, each component may have different functions and capabilities other than those described below, and may include additional components other than those described below.

[0121] The illustrated computing environment includes a job control module (310). In one embodiment, the job control module (310) may be any type of computing device that transmits and receives signals with other terminals.

[0122] The job control module (310) includes at least one processor (13), a computer-readable storage module (16), and a communication bus. The processor (13) may cause the job control module (310) to operate according to the exemplary embodiments mentioned above. For example, the processor (13) may execute one or more programs stored in the computer-readable storage module (16). The one or more programs may include one or more computer-executable instructions, and the computer-executable instructions, when executed by the processor (13), may be configured to cause the job control module (310) to perform operations according to the exemplary embodiments.

[0123] The processor (13) may also perform the generation or update of a work plan and the occupancy of a transit node in conjunction with the neural network module (14). While the processor (13) and the neural network module (14) are described as being different modules, they are not necessarily limited to this, and may be implemented so that each operation is performed by combining them into a single module.

[0124] The neural network module (14) performs neural network processing related to the generation or update processing of a work plan and the occupancy processing of a waypoint node based on artificial intelligence (AI). The neural network module (14) has an input node, an intermediate node, and an output node, and has a structure specified by a decision weight that has been previously learned through training data as a connection weight connecting each node. The output value of the neural network module (14) may be a coordinate value of an extended area or a coordinate value of a unit block area, and may be implemented in the form of a feature value matrix for the extended area or the unit block area.

[0125] The computer-readable storage module (16) is configured to store computer-executable instructions or program code, program data, and / or other suitable forms of information. A program stored in the computer-readable storage module (16) includes a set of instructions executable by the processor (13). In one embodiment, the computer-readable storage module (16) may be a memory (volatile memory such as random access memory, non-volatile memory, or a suitable combination thereof), one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, any other form of storage medium that is accessible by the job control module (310) and capable of storing desired information, or a suitable combination thereof.

[0126] The communication bus interconnects various other components of the job control module (310), including the processor (13) and the computer-readable storage module (16).

[0127] The job control module (310) may also include one or more input modules (11) and output modules (12) and one or more communication interfaces that provide interfaces for one or more input / output devices (not shown). The input modules (11) and output modules (12) and the communication interfaces are connected to a communication bus. The input / output devices (not shown) may be connected to other components of the job control module (310) via the input modules (11) and the output modules (12). Exemplary input / output devices may include input devices such as pointing devices (such as a mouse or trackpad), keyboards, touch input devices (such as a touchpad or touchscreen), voice or sound input devices, various types of sensor devices, and / or photographing devices, and / or output devices such as display devices, printers, speakers, and / or network cards. An exemplary input / output device (not shown) may be included within the job control module (310) as a component constituting the job control module (310), or may be connected to the computing device as a separate device distinct from the job control module (310).

[0128] FIG. 5 and FIG. 6 are flowcharts for explaining a method for generating work information for transportation according to an embodiment of the present invention.

[0129] Referring to FIG. 5, the user terminal (100) generates work request information (S510) and transmits the work request information to the robot management server (200) (S512).

[0130] The robot management server (200) performs a task structure analysis on task request information (S520) and generates a node selection and task report (S530).

[0131] The robot management server (200) selects a robot (300) based on the work report and assigns work to it.

[0132] The robot (300) analyzes the work and determines an initial plan for the assigned work and saves the work plan.

[0133] The robot (300) transmits the work analysis results and the initial plan to the robot management server (200) and requests modification (revision) of the plan.

[0134] The robot management server (200) establishes a detailed path plan based on the task analysis results and the initial plan (S550), and creates a modified plan by modifying the initial plan based on the detailed path plan (S552).

[0135] The robot (300) obtains a modification plan from the robot management server (200), verifies the modification plan, and updates the work plan (S560).

[0136] The robot (300) transmits the updated latest version of the work plan to the robot management server (200) (S562).

[0137] The robot management server (200) stores the work plan received from the robot (300) (S564).

[0138] The robot (300) performs work with an updated work plan (S570) and shares update information on the work progress with the robot management server (200) (S572).

[0139] The robot management server (200) feeds back the work progress of the robot (300) to the user terminal (100) (S574).

[0140] Meanwhile, when the robot (300) completes the work being performed according to the work plan (S580), it shares information about the work completion status with the robot management server (200) (S582).

[0141] The robot management server (200) shares the results of the robot's (300) work performance with the user terminal (100) (S584).

[0142] Referring to FIG. 6, a method for determining a path plan for a robot according to another embodiment of the present invention comprises the following steps, which are performed in time series. The steps below are steps for automatically generating a performance plan required for path occupancy management and movement.

[0143] First, the user terminal generates a job request to be performed by the mobile robot and transmits the generated job request to the server (S610).

[0144] The robot management server performs a structural analysis on the above-mentioned job request (S620), selects multiple nodes related to the job request, and then transmits a job report including information on the selected nodes to the robot (S630, S640).

[0145] The work robot performs work analysis based on the work report and determines the initial plan (S650).

[0146] Next, the robot management server receives the task analysis and initial plan from the robot, performs path planning, and transmits the path plan to the robot.

[0147] The logistics robot verifies the received route plan and modifies the initial plan (S660). The robot management server receives the modified initial plan and transmits it to the client terminal (S670).

[0148] Hereinafter, the above-described process will be described in more detail. First, structural analysis analyzes user-requested task information and environmental information to analyze the tasks performed by the robot. Here, the "job" refers to the task that the robot must perform. The content of the task can be composed of a combination of instructions for the robot's function execution, considering the robot's performance capability to perform the task. Structural analysis of the task can include information such as the timing of task execution, whether it is repeated, the functional group of the robot to be performed, direct or system-designated designation of the robot to perform the task, and analysis of the timing and conditions of the execution of the instructions for function execution.

[0149] Based on these analysis results, the robot management server can generate a job report containing the user-requested task, i.e., the initial plan. A job report is data that records the robot's job performance process, progress, and results. For repetitive tasks, there is only one task, but multiple reports can be generated in a 1:N ratio, and multiple robots can perform the tasks.

[0150] Based on the task report, the robot management server determines which worker robot will perform the task and assigns the task to the selected worker robot. The worker robot may be a user-specified robot or a robot selected by the robot management server. The selected worker robot is preferably the robot closest to the route, or the robot with the highest task performance efficiency (robots closer to the starting point, robots closer to the destination), or the robot with a high probability of completing the task (robots with high battery life, robots with a low probability of failure), considering the user-requested task or task report.

[0151] Accordingly, the robot assigned the task (i.e., the worker robot) performs an initial verification of the task's feasibility and a revision of the task. Furthermore, the worker robot retrieves information about the task execution environment, determines an initial path plan directly, or requests an initial path plan from the robot management server.

[0152] Here, the initial route plan is a route plan determined based on the shortest distance by analyzing movement-related commands among the structurally analyzed function execution instructions. The initial route plan is, for example, a route plan from the starting node to the first waypoint node. The initial route plan may include location information for the starting node and the first waypoint node, a driving route plan, speed information, and more.

[0153] Next, the task robot can either directly generate task revision information or request a task revision from the robot management server. Here, a task revision refers to a task plan based on task information generated by the robot management server, specifically, improving the initial task plan into a detailed, executable plan.

[0154] The work robot can determine whether it is possible to move from its current location to the initially planned destination.

[0155] In the cases below, the work robot may determine that it is difficult to perform the task with only the initial plan, and may establish (revise) an additional detailed plan.

[0156] First, when it is necessary to link with structures (facilities) within a building necessary for the robot's movement (elevators, automatic doors, etc.)

[0157] Second, in cases where multiple robots need to be used sequentially according to priority or waiting one at a time for smooth movement (e.g. in narrow hallways).

[0158] Third, when the robot moves, it is necessary to adjust the robot's sensor detection range before entering a specific space.

[0159] Fourth, when the direction of movement of the robot is specific, such as one-way traffic.

[0160] Meanwhile, the detailed plan described above can be generated through the processes of waiting, occupancy approval, occupancy, and release from the waiting area. Furthermore, the task revision information can further include revisions to alternative plans based on changes in the situation (e.g., user job cancellation, error occurrence, etc.) during the movement of the task robot.

[0161] Beyond movement-related commands, work robots can also determine whether they can perform the current planned task. For example, there are cases where interoperability with other equipment / devices is required, rather than performing standalone functions (e.g., movement or loading operations linked to other equipment). Detailed plans can be generated through the process of waiting, occupancy approval, occupancy, and release at the work location or waiting area.

[0162] In the case of moving between floors (elevators), the work robot can establish a detailed plan through a recursive process by adding a map transition and repeating the above process (Revision) from the time it gets off at the destination floor until there is no problem.

[0163] The working robot can verify the final work revision information. Verification here refers to determining whether the robot can actually complete the task according to the revision plan.

[0164] Although FIGS. 5 and 6 each describe the steps as being executed sequentially, this is not necessarily the case. In other words, the steps described in FIGS. 5 and 6 may be modified and executed, or one or more steps may be executed in parallel. Therefore, FIGS. 5 and 6 are not limited to a chronological order.

[0165] The method for generating work information for transportation according to the present embodiment described in FIGS. 5 and 6 may be implemented as an application (or program) and recorded on a recording medium readable by a terminal device (or computer). The recording medium on which the application (or program) for implementing the method for generating work information for transportation according to the present embodiment is recorded and readable by a terminal device (or computer) includes all types of recording devices or media on which data readable by a computing system is stored.

[0166] FIG. 7 and FIG. 8 are flowcharts for explaining a method for processing occupancy of a robot's waypoint node according to an embodiment of the present invention.

[0167] Referring to FIG. 7, the robot (300) receives a modification plan from the robot management server (200) (S710) and moves to a transit node according to an updated work plan based on the modification plan (S720).

[0168] The robot (300) requests the robot management server (200) to allocate a waiting position to occupy (use) a transit node (S730).

[0169]

[0170] The robot (300) is assigned a waiting position and checks whether occupancy permission information has been received (S740).

[0171] In step S740, if occupancy permission information is not received, the robot (300) waits in a standby position.

[0172] Meanwhile, in step S740, if occupancy permission information is received, the robot (300) performs transit occupancy (use and passage) (S750).

[0173] When the robot (300) leaves the waypoint, it notifies the robot management server (200) of the release of occupation (S760).

[0174] When the robot (300) moves to an additional stopover (S770), it receives a modification plan from the robot management server (200) and updates the work plan.

[0175] Meanwhile, if not moving to an additional stopover (S770), the robot (300) performs work according to the existing work plan (S780).

[0176] Hereinafter, a method for automatically generating a detailed execution plan required for route occupancy management and movement, according to another embodiment of the present invention, is described in detail. The method comprises the following steps, which are performed sequentially by a logistics robot or a robot management server.

[0177] The work robot moves along the path to the first waypoint (automatic door) according to the path plan received from the server and the modified initial plan (S810).

[0178] While moving, the work robot requests the server side to “allocate a waiting position” to occupy (use) the first waypoint (S820).

[0179] The work robot waits for “occupancy permission” from the server at the assigned waiting location (S830).

[0180] When the work robot receives “occupancy permission” from the server, it occupies (i.e. uses, passes through) the first waypoint (automatic door), and when the sensor of the first waypoint (automatic door) detects that the robot has passed through, it notifies the server side of “occupancy release” through the communication module of the first waypoint (S840).

[0181] The work robot moves along a path to the second stop (elevator) that has already been determined according to the above path plan (S850).

[0182] The work robot receives a modified route plan from the server according to some change in the driving environment, verifies the received route plan, modifies the initial plan based on the current standard, and modifies the second waypoint to an additional loading station for goods.

[0183] The work robot moves towards the modified second waypoint (a station for additional loading of goods) and waits for “occupancy permission” from the server at the assigned waiting position at the second waypoint.

[0184] When the worker robot receives a “permission to occupy” from the server, it occupies the second waypoint (i.e., loads additional items).

[0185] When the sensor at the second stopover (additional loading point) detects that the robot has completed loading additional items, it notifies the server side of “occupancy release” through the communication module at the second stopover.

[0186] Meanwhile, according to another embodiment of the present invention, the work robot moves along a path to the first waypoint (automatic door) according to a path plan received from the server and a modified initial plan (Revision plan).

[0187] While moving, the worker robot requests a "waiting position assignment" from the server to occupy (use) the first waypoint. The waiting position is the closest unoccupied location from the robot's current direction, awaiting permission to occupy.

[0188] Work robots wait in their assigned waiting positions for "occupancy permission" from the server. While the first robot to enter the space is granted the right to occupy, priority can be given to robots that urgently need to move.

[0189] When the work robot receives “occupancy permission” from the server, it occupies (i.e. uses) the first waypoint (automatic door) and passes through it.

[0190] Once the worker robot receives the occupancy permit, it immediately executes the command, as it has already received a plan with instructions for occupancy and passage.

[0191] When a worker robot approaches a door, the server opens the automatic door and maintains it open until the robot passes through. Each task instruction can have a time limit. If a failure occurs, the user can be notified or an alternative task can be performed. For example, if a task is canceled or an error occurs that prevents further execution, the opened automatic door can be closed again.

[0192] Next, when the robot passes through the automatic door, the work robot checks whether its position is the position where it passed through the automatic door, and records the passage in the work report and transmits it.

[0193] Next, the FMS server recognizes that the robot has finished using the resource and notifies the automatic door communication module to release the open state.

[0194] The work robot moves along the path to the next waypoint (Revision conditions on page 8) already determined according to the above work Revision plan until it reaches the destination.

[0195] Without this kind of recursive detailed planning, users can pre-write the route to the destination and all the necessary wait-seize-release commands along the way.

[0196] Because the current position of the work robot can change dynamically, a detailed plan is dynamically created at the time of job execution, and flexible operation is possible because the plan is reflected based on the dynamic current situation.

[0197] Since the elevator moves between floors, a change in the map is added, and after arriving at the destination floor, a revision plan is created to use the elevator to go back to the destination or to the next destination floor when changing elevators.

[0198] When using an elevator, it can lead to plans for user cancellation, emergency measures (in case of a fire, arriving at the designated floor, opening the elevator door, and moving to the designated location), waiting locations and user notifications in case of an error, etc., so it creates a more complex plan than automatic doors, and detailed plans of these different resources are recursively analyzed and added until the work is completed.

[0199] Figures 9 to 11 are exemplary diagrams for explaining the operation of generating work information for transport work management according to an embodiment of the present invention.

[0200] Referring to FIG. 9, the present invention is characterized in that, rather than having the user explicitly designate the entire process of moving the autonomous robot, the user calculates the movement path from the current location of the robot, determines whether there are external facilities or devices such as elevators / automatic doors that must be used along the path, or areas that must perform specific functions, and automatically generates a detailed plan and instructions necessary for moving to the destination and records and manages the execution process.

[0201] The robot service software framework of the present invention can be, for example, ROCON. Beyond the limitations of existing robot services that rely solely on the functions of a single robot, it can integrate various robots into real-world settings and connect them with IoT sensors and devices to provide valuable robot services. It is also possible to implement services using multiple robots in a concert-like manner, harmonizing with the surrounding environment and people.

[0202] In the present invention, a job is a type of mission or goal for a service. A job may consist of a series of instructions based on robot functions. In the present invention, a worker is an entity (usually a robot) that performs tasks for the user.

[0203] Site Configuration may include a Sharing Map for the target service environment and annotated semantic information.

[0204] Scheduler refers to job scheduling (on-demand, scheduled, recurring) and assigning robots (automatic, manual).

[0205] Auth stands for user management service (authentication, authorization).

[0206] Preset means a predefined job or shortcut to launch.

[0207] Notification means informing users of meaningful events.

[0208] Report refers to work reports, statistics, and analysis reports.

[0209] Fleet management service refers to a global plan for detailed planning injection and resource management (shared objects in the service environment).

[0210] The IOT operator manages external resources (e.g., building facilities (elevators, automatic doors)) and common operation control for resource use.

[0211] Common UI can mean a common built-in user interface.

[0212] Balcony can mean full status display for task creation, scheduling and calendar viewing, history, and worker management.

[0213] The Fleet Management UI is a map-based user interface for site configuration and monitoring. Custom UI refers to a service-specific user interface. A custom service can refer to a service-specific backend service.

[0214] There is a Client SDK (ClientSDK), for example, a software development kit for ROCON clients.

[0215] A Virtual Worker is a virtual robot (excluding physical properties) used to test FMS functionality, as robots are often in short supply.

[0216] A front-end terminal, or user terminal, is a computing device located on the user side and includes a user interface, such as a display screen, that allows the user to check the robot's path plan. Since the detailed plan automatically established according to this embodiment varies depending on the type / location of resources deployed by the user, it is necessary to provide a UI (path inspector) that allows the user to check the detailed path plan.

[0217] The user terminal includes a processing unit, memory, a display unit, and a communication module. Specifically, the user can communicate with the robot management server and the robot via the user terminal graphical user interface, and can easily check task information, the robot's current status, route information, and logistics status information via the display screen.

[0218] The user terminal can input user request information through a display unit, etc., and generate user requested work information by further considering the current status of the logistics robot and the situation of the workplace.

[0219] Referring to FIG. 9, the user terminal (100) performs a request to create a task to be performed by a user or a robot of a linked system.

[0220] The robot management server (200) performs structural analysis of the task and searches for the location of the destination or waypoint.

[0221] The robot management server (200) assigns a robot (300) to perform a task.

[0222] The robot management server (200) plans the shortest path from the current location of the robot (300) to the destination, and checks whether resources (automatic doors, elevators, traffic control areas, etc.) that must be sequentially occupied by the robots one by one or that require linkage with other systems are being used in the shortest path planning.

[0223] The robot management server (200) creates a detailed path plan to the entry or exit location of each resource.

[0224] The robot management server (200) can add work instructions necessary for linking with the FMS server or external systems (e.g., elevators, automatic doors, PLCs, PCs, etc.) when using each resource.

[0225] The robot management server (200) automatically inserts the detailed path plan as a detailed work instruction into the work instruction of the original work request presented by the user, thereby establishing (revisioning) and modifying the detailed path plan. Here, the robot management server (200) can repeatedly perform the operation of establishing the detailed path plan.

[0226] The robot (300) performs work according to the work plan determined after reviewing the modified detailed path plan. The robot (300) updates the progress and results of the work to the user terminal (100) and the robot management server (200).

[0227] In Fig. 10, the first path (810) represents destination information included in the work request information generated by the user.

[0228] In Fig. 10, the second path (820) represents a simple shortest path within the adjacent area in which the robot can move.

[0229] In Fig. 10, the third path (830) represents a work plan based on a modified path plan that takes into account the resource (automatic door) that requires passage (wait-occupy-pass-release).

[0230] In Fig. 11, the fourth path (910) is a movement plan presented based on the work request information of the user terminal (100), and the fifth path (920) represents a movement plan with a detailed plan added by the robot management server (200).

[0231] FIG. 12 and FIG. 13 are exemplary diagrams for explaining a transit node occupancy processing operation according to an embodiment of the present invention.

[0232] Referring to Figure 12, this is a drawing for explaining the operation of occupying a waypoint node in order for multiple robots to pass through an automatic door (waypoint node).

[0233] Multiple robots request the allocation of waiting positions to sequentially use automatic doors (waypoint nodes).

[0234] The multi-robot waits in a waiting position until it receives permission to occupy the resource (automatic door). Once granted permission, it uses the resource (automatic door). Resource use includes entering the automatic door area, waiting for the automatic door to open, and passing through the automatic door.

[0235] When multiple robots pass through the automatic door, they are notified of the occupancy release.

[0236] Afterwards, the multi-robot requests the allocation of a waiting position for the second automatic door.

[0237] The multi-robot waits in a waiting position until it receives permission to occupy, after which it uses a second resource (an automatic door). Resource use includes entering the automatic door area, waiting for the automatic door to open, and passing through the automatic door.

[0238] When the multi-robot passes through the second automatic door, it notifies the release of the occupancy.

[0239] Referring to FIG. 13, the robot management server (200) selects one of a plurality of candidate waiting locations (1420, 1422, 1424, 1426, 1428, 1429) within a preset distance from an automatic door (1410), which is a transit node, and assigns it as a waiting location for a logistics robot (1430).

[0240] Specifically, the robot management server (200) searches for candidate waiting positions (1420, 1422, 1424, 1426, 1428, 1429) around the automatic door (1410), excludes candidate waiting positions (1424, 1429) already assigned to a given robot from the search results, and then assigns the candidate waiting position (1420) closest to the current position of the logistics robot (1430) as the waiting position.

[0241] When there is only one logistics robot in standby, the robot management server (200) transmits occupancy permission information to the logistics robot.

[0242] Meanwhile, when there are multiple logistics robots (1430, 1432, 1434) in a standby state, the robot management server (200) can determine the occupancy priority for the multiple logistics robots (1430, 1432, 1434) and transmit occupancy permission information to each of the multiple logistics robots (1430, 1432, 1434) so ​​that the automatic door (1410) is occupied according to the determined occupancy priority.

[0243] The robot management server (200) can determine the occupancy priority using the first score for the width of the overlapping area of ​​the waiting area and the waiting area of ​​the logistics robot waiting in the waiting area. Referring to FIG. 13, since the first score for the first logistics robot (1430) is calculated to be high, the occupancy priority of the first logistics robot (1430) can be determined as the highest.

[0244] Additionally, the robot management server (200) can determine the occupancy priority using the second score for the shortest distance between the center of the transit node and the waiting logistics robot. Referring to FIG. 13, the second score for the first logistics robot (1430) is calculated to be high, so the occupancy priority of the first logistics robot (1430) can be determined as the highest.

[0245] Additionally, the robot management server (200) can determine the occupancy priority using the third score for the angle between the center of the waypoint node and the direction of travel of the waiting logistics robot. Referring to FIG. 13, the third score for the third logistics robot (1434) is calculated to be high, so the occupancy priority of the third logistics robot (1434) can be determined as the highest.

[0246] Meanwhile, although the robot management server (200) is described as determining the occupancy priority using one of the first, second, and third scores, it is not necessarily limited to this. For example, the robot management server (200) may also determine the occupancy priority of the logistics robots (1430, 1432, 1434) by calculating (summing, averaging, variance, etc.) the first, second, and third scores.

[0247] The above description is merely an example of the technical idea of ​​the embodiment of the present invention, and those skilled in the art to which the embodiment of the present invention pertains can make various modifications and variations without departing from the essential characteristics of the embodiment of the present invention. Therefore, the embodiment of the present invention is not intended to limit the technical idea of ​​the embodiment of the present invention, but to explain it, and the scope of the technical idea of ​​the embodiment of the present invention is not limited by these embodiment. The protection scope of the embodiment of the present invention should be interpreted by the following claims, and all technical ideas within a scope equivalent thereto should be interpreted as being included in the scope of the rights of the embodiment of the present invention.

[0248] <Explanation of symbols>

[0249] 100: User terminal

[0250] 200: Robot Management Server

[0251] 300: Robot

Claims

1. In a method for performing robot transit node occupancy processing in a robot management server, A step of receiving occupancy request information from the robot when the robot moves to a waypoint node according to a previously generated work plan; A step of allocating a waiting position based on the above occupancy request information, determining whether to grant occupancy based on the waiting status, and transmitting the occupancy permission information to the robot so that the transit node is occupied; and Step of receiving occupancy release information when the robot leaves the above transit node A method for handling occupancy of a waypoint node of a robot for transportation, characterized in that it includes a.

2. In paragraph 1, The above transit node is, Refers to resources placed on the movement path of the robot according to the above work plan. A method for handling occupancy of a waypoint node of a robot, characterized in that the above resource includes at least one of an automatic door, an elevator, and a traffic control area.

3. In paragraph 2, The step of receiving the above occupancy request information is: Including the current location and resource information of the above robot, A method for processing occupancy of a robot's waypoint node, characterized in that the above resource information includes the type and location of the above resource.

4. In paragraph 3, The steps to ensure that the above transit node is occupied are: A method for processing occupancy of a waypoint node of a robot, characterized in that one of the candidate waiting locations existing within a preset distance from the waypoint node is selected and assigned as the waiting location of the robot.

5. In paragraph 4, The steps to ensure that the above transit node is occupied are: A method for processing occupancy of a waypoint node by a robot, characterized in that the method comprises: searching for the candidate waiting positions around the waypoint node, excluding the candidate waiting positions already assigned to a given robot from the search results, and then assigning the candidate waiting position closest to the current position of the robot as the waiting position.

6. In paragraph 1, The steps to ensure that the above transit node is occupied are: A method for processing occupancy of a robot's waypoint node, characterized in that when there is only one robot in the above-mentioned standby state, occupancy permission information is transmitted to the robot.

7. In paragraph 1, The steps to ensure that the above transit node is occupied are: A method for processing occupancy of a waypoint node by a robot, characterized in that when there are multiple robots in the above-mentioned standby state, the occupancy priority for the multiple robots is determined, and the occupancy permission information is transmitted to each of the multiple robots so that the waypoint node is occupied according to the determined occupancy priority.

8. In paragraph 7, The steps to ensure that the above transit node is occupied are: A method for processing occupancy of a waypoint node of a robot, characterized in that the occupancy priority is determined by using a first score for the width of the waiting area of ​​the waiting position and the overlapping area of ​​the robot waiting in the waiting area.

9. In paragraph 7, The steps to ensure that the above transit node is occupied are: A method for processing occupancy of a waypoint node by a robot, characterized in that the occupancy priority is determined by using a second score for the shortest distance between the center of the waypoint node and the waiting robot.

10. In paragraph 7, The steps to ensure that the above transit node is occupied are: A method for processing occupancy of a waypoint node by a robot, characterized in that the occupancy priority is determined by using a third score for the angle between the center of the waypoint node and the direction in which the waiting robot is moving.

11. In paragraph 1, The step of receiving the above occupancy release information is: A method for processing occupancy of a waypoint node by a robot, characterized in that after receiving the above occupancy release information, when occupancy request information for a new waypoint node is received from the robot or the robot moves to a new waypoint node, a modification plan for updating the work plan is transmitted to the robot.

12. In the robot task management server, The robot task management server comprises a memory storing one or more programs for performing the process of occupying a robot's waypoint node; and one or more processors for performing operations for performing the process of occupying a robot's waypoint node according to the one or more programs, and the operations performed by the processors include: A step of receiving occupancy request information from the robot when the robot moves to a waypoint node according to a previously generated work plan; A step of allocating a waiting position based on the above occupancy request information, determining whether to grant occupancy based on the waiting status, and transmitting the occupancy permission information to the robot so that the transit node is occupied; and Step of receiving occupancy release information when the robot leaves the above transit node A robot management server comprising:

13. In paragraph 12, The above transit node is, It means a resource placed on the movement path of the robot according to the above work plan, and the resource includes at least one of an automatic door, an elevator, and a traffic control area, A robot management server, characterized in that the step of receiving the above occupancy request information includes the current location and resource information of the robot, and the resource information includes the type and location of the resource.

14. In paragraph 13, The steps to ensure that the above transit node is occupied are: A robot management server characterized in that it selects one of the candidate waiting locations existing within a preset distance from the above-mentioned waypoint node and assigns it as the waiting location of the robot.

15. In paragraph 12, The steps to ensure that the above transit node is occupied are: A robot management server characterized in that, when there is only one robot in the above standby state, it transmits occupancy permission information to the robot.

16. In paragraph 12, The steps to ensure that the above transit node is occupied are: A robot management server characterized in that, when there are multiple robots in the above-mentioned standby state, the occupancy priority for the multiple robots is determined, and the occupancy permission information is transmitted to each of the multiple robots so that the transit node is occupied according to the determined occupancy priority.

Images