Method and device for waking up a robot in a shutdown state

Abstract

The present invention provides a method for waking up a robot in a shutdown state, which is executed by a server for providing a robot control service, the method including the steps of: the server responding to a shutdown request from a terminal for controlling robot operation, wherein the shutdown request is generated by the terminal in response to a shutdown operation input by a user, the shutdown request including configurable wake-up time information and identification information of the robot to be shut down, and the wake-up time information and the identification information of the robot to be shut down are added to the shutdown request; and sending, to the robot to be shut down, an associated task related to the shutdown task and a shutdown command to which the wake-up time information is added, so that the robot to be shut down executes the shutdown command after completing the associated task, enters a shutdown state in which it is not connected to the terminal and the server after executing the shutdown command, and starts up according to the wake-up time information in the shutdown command, wherein the number of robots to be shut down is one or more.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This patent application claims priority to a Chinese patent application filed on March 27, 2023, with application number 202310305983.9, the entire contents of which are incorporated herein by reference.

[0002] The present invention relates to the field of robot control, and more particularly to a method for waking up a robot in a shutdown state. [Background technology]

[0003] With the rapid development of the robotics industry, the number of robotic devices that are accessed by a server for providing robot control services is increasing explosively.

[0004] In real-world scenarios in large-scale plants with multiple facilities, it is necessary to shut down numerous robots at the end of the day or on holidays. For example, when shutting down hundreds of automated guided vehicles (AGVs), each robot must finish its current task before shutting down; it cannot be shut down immediately. Manual operation is extremely time-consuming, and each piece of equipment must be started up manually one by one at the start of work. Due to the large number of robots, shutting down the robots and waking them up after they are shut down takes a lot of time, resulting in low efficiency and a low degree of automation. Summary of the Invention

[0005] A first aspect of the present invention provides a method for waking up a robot in a shutdown state, the method being executed by a server for providing a robot control service, the method comprising: a step of responding to a shutdown request from a terminal for controlling robot operation, wherein the shutdown request is generated by the terminal in response to a shutdown operation input by a user, the shutdown operation including settable wake-up time information and identification information of the robot to be shut down, and the wake-up time information and the identification information of the robot to be shut down are added to the shutdown request; transmitting the associated task related to the shutdown task and the shutdown command to which the wake-up time information is added, based on identification information of the robot to be shut down, to the robot to be shut down, so that the robot to be shut down executes a shutdown command after completing the associated task, enters a shutdown state in which it is not connected to the terminal and the server after executing the shutdown command, and starts up according to the wake-up time information in the shutdown command; The number of robots to be shut down is one or more.

[0006] A second aspect of the present invention provides a method for waking up a robot in a shutdown state, the method being executed by a terminal for controlling robot operation, the method comprising: the terminal, in response to a shutdown operation input by a user, including settable wake-up time information and identification information of a robot to be shut down, transmits a shutdown request to a server for providing a robot control service, the shutdown request including the wake-up time information and the identification information of the robot to be shut down, thereby causing the server to execute a wake-up method in a shutdown state of any of the robots; The number of robots to be shut down is one or more.

[0007] A third aspect of the present invention provides a terminal, the terminal comprising: The device includes a first response module that, in response to a shutdown operation input by a user, includes settable wake-up time information and identification information of a robot to be shut down, sends a shutdown request to a server for providing a robot control service, to which the wake-up time information and the identification information of the robot to be shut down are added, thereby causing the server to execute a wake-up method in a shutdown state of any of the robots.

[0008] A fourth aspect of the present invention provides a scheduling server for providing a robot control service, the scheduling server comprising: a second response module for responding to a shutdown request from a terminal for controlling robot operation, the shutdown request being generated by the terminal in response to a shutdown operation input by a user, the shutdown request including configurable wake-up time information and identification information of the robot to be shut down, and the wake-up time information and the identification information of the robot to be shut down being added to the shutdown request; a startup / shutdown control module for transmitting the associated task related to the shutdown task and the shutdown command to which the wake-up time information is added to the robot to be shut down based on identification information of the robot to be shut down, so that the robot to be shut down executes a shutdown command after completing the associated task, enters a shutdown state in which it is not connected to the terminal and the server after executing the shutdown command, and starts up according to the wake-up time information in the shutdown command; The number of robots to be shut down is one or more.

[0009] A fifth aspect of the present invention provides a system for managing robots, including the terminal and the scheduling server. [Effects of the Invention]

[0010] A method for waking up a robot in a shutdown state according to an embodiment of the present invention involves setting shutdown parameter information via a terminal, and sending a task related to the shutdown task and a shutdown command to be shut down via a server, which then causes the robot to execute the shutdown command after completing the task, enters the shutdown state after executing the shutdown command, and starts up in the shutdown state according to the wake-up time information in the shutdown command. This eliminates the need for the robot to manually shut down after completing its current task, enabling automatic startup and shutdown of the robot, which is advantageous for realizing one-key group shutdown and one-key group startup for large groups of robots, and improves the efficiency of shutdown and startup for large groups of robots. [Brief explanation of the drawings]

[0011] [Figure 1] 2 is a flowchart illustrating a method for waking up a robot in a shutdown state according to an embodiment of the present invention. [Figure 2a] 2 is a schematic diagram of a shutdown process of a wake-up method in a shutdown state of a normal shutdown mode according to an embodiment of the present invention; FIG. [Figure 2b] FIG. 10 is a schematic diagram of a shutdown operation interface on the monitoring client side; [Figure 3] FIG. 1 is a schematic diagram of the processing process of an AGV that should be shut down and meets the shutdown conditions. [Figure 4] 1 is a schematic diagram of the processing process of an AGV that does not meet the one-key shutdown conditions and should be shut down; [Figure 5] 1 is a schematic diagram of state changes identified by the server during graceful shutdown of an AGV in normal shutdown mode, and transition conditions between state changes. [Figure 6] FIG. 1 is a schematic diagram of a process for a charge-enabled shutdown mode. [Figure 7] FIG. 1 is a schematic diagram of the treatment process of the shutdown mode of in-place load release. [Figure 8] FIG. 1 is a schematic diagram of a shutdown cancellation process. [Figure 9] 1 is a schematic diagram of a terminal according to an embodiment of the present invention; [Figure 10] FIG. 2 is a schematic diagram of a scheduling server according to an embodiment of the present invention; [Figure 11] 2 is a schematic diagram of a terminal and a scheduling server according to an embodiment of the present invention; DETAILED DESCRIPTION OF THE INVENTION

[0012] In order to make the objectives, technical means and advantages of the present invention clearer, the present invention will be described in more detail below with reference to the drawings.

[0013] 1, which is a flowchart illustrating a method for waking up a robot in a shutdown state according to an embodiment of the present invention. The method includes steps 101 to 103.

[0014] In step 101, in response to a shutdown operation including at least settable wake-up time information and identification information of the robot to be shut down input by the user, the terminal for controlling robot operation transmits a shutdown request to a server for providing robot control services, the shutdown request including at least the wake-up time information and the identification information of the robot to be shut down.

[0015] For example, the shutdown operation further includes at least one of selectable shutdown mode information and configurable shutdown lifecycle information, which is used to set a shutdown wait time to control the execution and completion of the shutdown process of the robot to be shut down.

[0016] In step 102, in response to a shutdown request from the terminal for controlling robot operation, the server transmits to the robot to be shut down a related task related to the shutdown task and a shutdown command to which at least the wake-up time information is added, based on the identification information of the robot to be shut down.

[0017] For example, the shutdown request may further include at least one of shutdown lifecycle information and shutdown mode information, where the shutdown mode includes one or a combination of a normal shutdown mode, a charge-enabled shutdown mode, and an in-situ load release shutdown mode.

[0018] The normal shutdown mode is used to wake up a robot in a shutdown state without any shutdown condition constraints.

[0019] The charge-enabled shutdown mode is used to wake up a low-power robot in a shutdown state when its current power level is lower than a predetermined power threshold.

[0020] The in-place unload shutdown mode is used to wake up a robot in a shutdown state that can unload the load.

[0021] As an example, a shutdown task in an embodiment of the present invention includes a shutdown operation that a robot to be shut down performs in response to a shutdown command from a server and a wake-up operation in a shutdown state, and an associated task related to a shutdown task includes a task that needs to be executed to complete the shutdown task. The associated task is related to the shutdown mode, and different shutdown modes may correspond to different associated tasks. A charge-enabled shutdown mode corresponds to the associated task of moving to a charging station and charging. A shutdown mode with on-site load release corresponds to the associated task of releasing the load. Furthermore, different shutdown modes may correspond to the same associated task, i.e., moving to a shutdown pause position, thereby gathering robots in a shutdown state and facilitating robot management. Those skilled in the art will understand that the charge-enabled shutdown mode and the shutdown mode with on-site load release are shutdown modes with condition constraints.

[0022] The shutdown mode is not limited to the above modes, but may be specifically designed according to the service needs of the application scenario. The associated task is not limited to the above tasks, but may be specifically determined according to the service needs of the application scenario.

[0023] For example, in response to a shutdown request, the server creates a related task related to the shutdown task and generates a shutdown command, thereby reducing interactions with terminals and robots and improving efficiency. By sending the related task to a robot to be shut down that meets the shutdown condition and sending a shutdown command to a robot to be shut down that has completed the related task, it is possible to not only reduce the occupation of the server's bandwidth but also to balance the shutdown with the tasks being executed by the robot to be shut down.

[0024] The robots to be shut down that meet the shutdown conditions and have completed their associated tasks may be determined based on the status of the robots to be shut down identified by the server.

[0025] As an example, the current state of the robot to be shut down is further monitored in real time within the shutdown lifecycle, thereby improving the accuracy of the robot state information.

[0026] If the shutdown lifecycle is within the shutdown lifecycle and is not about to end, the related tasks are sent to the robots to be shut down, and the robots to be shut down that do not satisfy the shutdown conditions are processed, thereby improving the reliability of the shutdown operation, contributing to the balance between tasks and shutdown, and avoiding a dead cycle due to an abnormality.

[0027] At least when the shutdown lifecycle is about to end, a shutdown command is sent to the robots that have completed the related tasks and should be shut down, thereby preventing the shutdown command from being sent later than the end of the shutdown lifecycle, improving the centralized processing power of the server and improving the reliability of shutdowns by a large number of robot groups.

[0028] After the shutdown lifecycle is completed, the server switches to normal operation mode and returns the current status of all robots to be shut down to the terminal. This allows the user to obtain the robot status and perform corresponding manual processing, which is useful for robot management. In an embodiment of the present invention, the server controls the robot status according to its operation mode. For example, when the server's operation mode is "normal operation mode," the server controls the robot to be in an operating state, such as loading or unloading. For example, when the server's operation mode is "shutdown mode," the server controls the robot to be in a non-operating state (shutdown waiting state). The server's shutdown modes include a normal shutdown mode, a charging-enabled shutdown mode, and an on-site load release shutdown mode. For example, if the server analyzes that the normal shutdown mode is attached to the shutdown request, the server switches to normal shutdown mode and, in the normal shutdown mode, identifies the current status of all online AGVs to be shut down as waiting for shutdown and unable to charge. If the server analyzes that the charging-enabled shutdown mode is attached to the shutdown request, the server switches to charging-enabled shutdown mode and identifies the status of each online AGV to be shut down as waiting for shutdown and able to charge.

[0029] As an example, the shutdown lifecycle may start timing upon receiving a shutdown request, and the impending end time may be determined based on a configured time threshold. For example, if the time threshold is 30 seconds and the shutdown lifecycle is 5 minutes, the last 30 seconds of the shutdown lifecycle may be considered to be the impending end time.

[0030] In step 103, the robot to be shut down responds to the associated task and the shutdown command, first executes the associated task, and executes the shutdown command after completing the associated task. After executing the shutdown command, the robot to be shut down enters a shutdown state in which it is not connected to the terminal and the server, and in the shutdown state, starts up according to the wake-up time information in the shutdown command.

[0031] Here, the number of robots to be shut down is one or more, or the robots to be shut down are a large number of robots to be shut down.

[0032] The same shutdown operation includes the identification information of at least one robot to be shut down, and the identification information of multiple robots to be shut down corresponds to the same wake-up time information, the same shutdown mode, and the same shutdown lifecycle, thereby realizing one-key group shutdown and one-key group startup.

[0033] In an embodiment of the present invention, the server can perform shutdown operations for a large number of robots by using the identification information of the robots to be shut down, set in the terminal, achieving the effect of one-key shutdown.Furthermore, the robots enter a shutdown state where they are not connected to the terminal or server, and appear to be in a shutdown state, but in fact are in a sleep state where they are sending listening frames to the terminal and / or server, thereby achieving a true shutdown of the robots.The wake-up time information set in the terminal allows robots in a shutdown state to start up themselves, reducing manual startup operations and improving the automation and intelligence of robot startup and shutdown.

[0034] To facilitate understanding of the present invention, the following description will be given taking an AGV as an example, but it should be understood that the present invention is not limited to AGVs and can be applied to any other controlled robots.

[0035] The technical terms used in this embodiment will be explained below.

[0036] Monitoring client: It is an application program for providing human-computer interaction to control AGVs through the server, and can run on terminals such as intelligent terminals and computer terminals.

[0037] Shutdown modes include normal shutdown mode, charge-enabled shutdown mode, and instant load release shutdown mode. The charge-enabled shutdown mode and instant load release shutdown mode are the normal shutdown mode with additional restrictive conditions. The following table describes each shutdown mode. [Table 1]

[0038] Allocation Library: Located on the scheduling side (server side), it is used to allocate tasks to AGVs. During the shutdown process, it allocates AGVs to the nearest shutdown pause position.

[0039] The main status of the AGV identified by the server is as follows: First state: Waiting for shutdown and unable to charge. Second state: A state matching the shutdown pause position. Third state: Waiting for a shutdown command to be sent. Fourth state: Waiting for shutdown and ready to charge.

[0040] 2a, which is a schematic diagram of a shutdown process of a wake-up method in a shutdown state of a normal shutdown mode according to an embodiment of the present invention, includes steps 201 to 205.

[0041] In step 201, the monitoring client provides the user with the option of selecting a shutdown mode and setting shutdown parameters, and in response to the shutdown operation input by the user, including the shutdown parameters, sends a shutdown request to the server, to which the shutdown parameters are attached.

[0042] As an example, the shutdown parameters include a shutdown lifecycle for setting a shutdown wait time, wake-up time information, device ID information of the AGV to be shut down, and a shutdown mode. Here, the shutdown mode is a normal shutdown mode. The values ​​of the wake-up time information and shutdown lifecycle input by the user are limited to avoid sending unreasonable requests. For example, if the current time is 19:15 on March 27, 2023, and the wake-up time input by the user is 20:00 on March 26, 2023, and the wake-up time is earlier than the current time, the request is considered to be an unreasonable shutdown request.

[0043] Referring to Figure 2b, Figure 2b is a schematic diagram of the shutdown operation interface on the monitoring client side. This interface includes controls for selecting the shutdown mode, shutdown waiting time, i.e., the shutdown lifecycle, wake-up time, and the number of AGVs to be shut down. The same shutdown lifecycle, wake-up time, and shutdown mode are set for multiple AGVs to be shut down. That is, the same shutdown lifecycle, wake-up time, and shutdown mode are set for AGVs to be shut down in the same shutdown operation input by the user, thereby realizing group shutdown operation and group startup operation, and AGVs to be shut down in the same shutdown request share the same wake-up time.

[0044] In step 202, in response to the received shutdown request, the server analyzes the shutdown request, and based on the analysis result, determines that the selected shutdown mode is a normal shutdown mode, and then verifies the shutdown parameters to avoid the calculated wake-up time being a negative value.

[0045] If the verification is successful, a success response message is returned to the monitoring client, which then notifies the user that the shutdown process has started successfully, and step 203 is executed. If the verification fails, a failure response message is returned to the monitoring client, and the cause of the failure is added to the message, allowing the monitoring client to notify the user of the failure of the shutdown process and the cause of the failure.

[0046] For example, the shutdown request analysis function is realized by adding an analysis function for the shutdown request message to the message processing index table, analyzing the shutdown parameters in the shutdown request message within the function, encapsulating a reply message indicating whether the shutdown was successful, constructing an information structure parameter object for switching the server's operating mode, calling and enabling a function for setting an identification value of the server's operating mode, and triggering the server to switch to the shutdown operating mode. For example, the reply message may include a return value indicating information such as failure to cancel, receipt of an invalid value, failure to analyze the shutdown parameters, successful execution of the shutdown operation, successful cancellation of the shutdown operation, the shutdown waiting time being less than the minimum value, the shutdown waiting time being greater than the maximum value, or invalid shutdown mode, and different information has a different return value.

[0047] In step 203, the server switches from the current normal operation mode to the normal shutdown mode, and in the normal shutdown mode, identifies the current status of all online AGVs to be shut down as a first status used to indicate that they are waiting to shut down and cannot be charged.

[0048] An example would be to further trigger the start of timing the shutdown lifecycle and prohibit the entry of new tasks into the allocation library.

[0049] In step 204, the server determines whether the shutdown lifecycle is complete.

[0050] When the shutdown lifecycle is completed, the current shutdown process is completed, the server exits the normal shutdown mode, switches to the normal operation mode, sends the current status of each AGV device to be shut down to the allocation library, and returns a success response message to the monitoring client, which includes information on the AGV that should be shut down abnormally, so that the monitoring client can present to the user which AGV that should be shut down is abnormal.

[0051] In this step, for example, each time the server completes the traversal of all AGVs identified as not in a shutdown state during the shutdown lifecycle, it calls a function for retrieving a shutdown report to report shutdown abnormality information. The function first updates the corresponding content in a container that collects shutdown abnormality information, then encapsulates all the information in the container into a message and sends it to the monitoring client for processing. The function for retrieving a shutdown report also sends abnormality information added to the shutdown result response message to the monitoring client for processing. For example, the abnormality information may include at least one of the following: the AGV is in a loaded state, the AGV is in a low-power state, the AGV itself is in an abnormal state, the AGV is in a locked state, and the AGV is shelf-bound.

[0052] The response message in this step includes a label field for indicating attributes and a status value. A first value in the label field indicates that the response message is reporting the shutdown status of the AGV during the shutdown process, and a second value in the label field indicates that the response message is reporting the shutdown status information of the AGV after the shutdown process has been completed. Different status values ​​indicate different states, such as the AGV itself being in an abnormal state, the AGV still performing a task, the AGV being in a low-power state, the AGV being in a loading state, the default state, the AGV being sorted to a shutdown pause position, the AGV equipment being moved to a shutdown pause position and waiting for a shutdown command to be sent, and the AGV equipment being sent a shutdown command.

[0053] If the shutdown lifecycle has not ended, the server monitors the current status of the robot to be shut down in real time, preferably returns the current status of the AGV to be shut down, and executes step 205. In step 205, the server determines whether the shutdown lifecycle has reached a set time threshold to determine whether the shutdown lifecycle will end soon.

[0054] When the shutdown lifecycle reaches a set time threshold, it indicates that the shutdown lifecycle is about to end, and a shutdown command is sent to the AGV to be shut down in a third state, and the current state of the AGV to be shut down is identified as a state in which the shutdown command is being executed, thereby causing the AGV to respond to the shutdown command and execute the shutdown. Here, the third state is used to indicate a state in which the shutdown command is waiting to be sent, and the shutdown command includes shutdown operation information and wake-up time information. For example, the shutdown operation information may be to automatically restart the shutdown at a set time, the set time being controlled by the wake-up time information, and the shutdown operation information may be to immediately shut down without restarting.

[0055] As an example, the server monitors the situation in which the AGV to be shut down performs a shutdown operation, and after the shutdown operation is completed, identifies the current state of the AGV to be shut down as a shutdown state.

[0056] After the AGV that should be shut down is shut down, it cuts off communication with the server and terminal, enters a shutdown state, and triggers the start of clocking the wake-up time. When the clock reaches the wake-up time, the AGV that should be shut down starts up by itself.

[0057] As another example, after the AGV to be shut down completes the shutdown operation, it reports to the server and then returns to step 204. When the server receives the shutdown message reported from the AGV to be shut down, it identifies the current state of the AGV to be shut down as a shutdown state and returns the shutdown state of each AGV to be shut down to the monitoring client.

[0058] As an example, the shutdown lifecycle is monitored by the server recording the start time of the process, then periodically calculating the difference between the current time and the start time and comparing it with the shutdown lifecycle, thereby controlling the shutdown lifecycle.

[0059] If the shutdown life cycle has not reached the set time threshold, it indicates that the shutdown life cycle is not about to end, and executes the processing process of the AGVs to be shut down that satisfy the shutdown conditions and the processing process of the AGVs to be shut down that do not satisfy the shutdown conditions, and then returns to step 204.

[0060] As an example, in the normal shutdown mode, an AGV in the first state to be shut down may be determined as an AGV that satisfies the shutdown condition, and an AGV in the first state, the second state, the third state, a state in which a shutdown command is being executed, or a state other than the shutdown state may be determined as an AGV that does not satisfy the shutdown condition. As shown in FIG. 3, FIG. 3 is a schematic diagram of a processing process for an AGV that satisfies the shutdown condition to be shut down. This includes steps 3051 to 3054.

[0061] In step 3051, the allocation library on the scheduling side (server side) efficiently aggregates the AGVs to be shut down by matching the AGVs to be shut down that are in the first state with the shutdown pause location that is closest to the AGVs to be shut down.

[0062] The server determines whether the shutdown pause position is matched, and if the shutdown pause position is matched, executes step 3052; otherwise, determines that the AGV to be shut down does not meet the shutdown condition, and ends this process.

[0063] Regarding the AGVs that should be shut down according to the shutdown pause position:

[0064] In step 3052, the server identifies the current state of the AGV to be shut down as a second state, which is used to indicate that the AGV has matched the shutdown pause position.

[0065] In step 3053, the server generates a task and a command to move to the shutdown pause position based on the shutdown pause position information output from the allocation library, and transmits the task and the command to move to the shutdown pause position to the AGV to be shut down, causing the AGV to execute the task to move to the shutdown pause position in response to the command. Here, the command to move to the shutdown pause position is added with the shutdown pause position information.

[0066] As an example, in step 3054, the AGV to be shut down determines whether the task to move to the shutdown pause position is completed, and if the task to move to the shutdown pause position is completed, reports a message to the server indicating that the task to move to the shutdown pause position is completed, thereby causing the server to identify the current state of the AGV to be shut down as the third state, which is used to indicate that the AGV is waiting for a shutdown command to be sent.

[0067] As another example, the server monitors the execution status of a task for moving the AGV to be shut down to a shutdown pause position, and when the task for moving to the shutdown pause position is completed, identifies the current state of the AGV to be shut down as a third state.

[0068] If the task to move to the shutdown pause position has not been completed, the AGV to be shut down will process the movement abnormality.

[0069] As shown in Figure 4, Figure 4 is a schematic diagram of the processing process of the AGV equipment that does not meet the one-key shutdown conditions and should be shut down. The server executes the following steps 4051 to 4053.

[0070] In step 4051, it is determined whether the AGV to be shut down is in an irrecoverable abnormal state. If so, the AGV to be shut down is identified as an abnormal shutdown device, and the AGV to be shut down is prohibited from entering the shutdown process; if not, step 4052 is executed.

[0071] In step 4052, determine whether the AGV to be shut down satisfies the shutdown power budget. If so, record the abnormality information of the AGV to be shut down and prohibit the AGV to be shut down from entering the shutdown process; if not, execute step 4053.

[0072] In step 4053, determine whether the AGV to be shut down is compatible with low-power charging. If so, identify the current state of the AGV to be shut down as a state requiring charging, and execute the charging-compatible shutdown mode processing process; if not, identify the AGV to be shut down as a low-power device, and prohibit the AGV from entering the shutdown processing process.

[0073] Steps 4051 to 4053 do not have a strict order. Referring to Figure 5, Figure 5 is a schematic diagram of the state changes identified by the server during normal shutdown of the AGV in normal shutdown mode, and the transition conditions between the state changes.

[0074] After the shutdown process is complete, the AGV that should be shut down due to a shutdown error can be manually shut down. The user inputs a shutdown command, which includes the equipment identifier information and wake-up time of the specified AGV to be shut down, but does not include the shutdown lifecycle. In response to the shutdown command, the monitoring client sends a forced shutdown request to the server, including the equipment identifier information and wake-up time. The server's Content Management Service (CMS) manually triggers analysis of the forced shutdown request and returns a forced shutdown response message to the monitoring client. The forced shutdown response message includes a return value indicating forced shutdown failure information (the AGV equipment status is not idle, loaded, or in a shutdown pause position), receipt of an invalid parameter value, failure to analyze the forced shutdown request, or successful forced shutdown execution.

[0075] In this embodiment, after one related process is performed on all online AGVs to be shut down in the life cycle, the server can report the abnormal devices and the causes of the abnormalities detected in the process to the monitoring client. The monitoring client displays this information and notifies the user which devices are in an abnormal shutdown state and which devices need to be manually processed in advance.

[0076] The charging-enabled shutdown mode is used to charge and then shut down AGVs that do not meet the shutdown power budget. When the server switches from normal mode to the charging-enabled one-key shutdown mode, it does not input a new task into the allocation library, but identifies the status of each online AGV device to be shut down in the allocation library as a fourth status. The fourth status indicates a status where the device is waiting to be shut down and can be charged.

[0077] Referring to Figure 6, Figure 6 is a schematic diagram of the processing process of the charge-enabled shutdown mode, which includes steps 601 to 606 after the server analyzes the shutdown request and verifies the shutdown parameters.

[0078] In step 601, the server switches to a shutdown mode that supports charging, and identifies the state of each online AGV device that should be shut down as a fourth state that is waiting for shutdown and is capable of charging.

[0079] In step 602, the server's allocation library matches the location of a charging station to the AGV to be shut down.

[0080] In step 603, a task and command for moving to the charging station for charging are generated, and the task and command are sent to the AGV to be shut down, so that the AGV to be shut down responds with the task and command for moving to the charging station for charging, executes the task for moving to the charging station for charging, and calls the charging process to charge. Here, the task and command for moving to the charging station for charging are added with the location information of the matching charging station.

[0081] As an example, in step 604, the AGV to be shut down reports a message to the server indicating that the task of moving to the charging station and charging has been completed, and reports the current power state to the server.

[0082] As another example, the server monitors the execution status of a task for the AGV to be shut down to move to a charging station and charge, and when the task for moving to the charging station and charging is completed, executes step 605, monitors the current amount of power of the AGV to be shut down, and executes step 605.

[0083] In step 605, the server updates the current status of the AGV to be shut down, which indicates the current power state.

[0084] In step 606, the server determines whether the shutdown power threshold is met based on the current power state.

[0085] If the shutdown energy threshold is met, the current state of the AGV to be shut down is identified as a first state, the timing of the shutdown lifecycle is started, and processing of the AGV to be shut down that meets the shutdown condition within the shutdown lifecycle is executed.

[0086] If the shutdown power threshold is not met, return to step 605 .

[0087] As an example, in a charge-compatible shutdown mode, an AGV to be shut down whose current electrical quantity state satisfies the shutdown electrical quantity threshold and an AGV to be shut down that is in a first state may be determined as the AGV to be shut down that satisfies the shutdown conditions.

[0088] The in-place unload shutdown mode is used to handle AGVs that are in a loaded state (e.g., laden) and must be shut down.

[0089] Referring to Figure 7, Figure 7 is a schematic diagram of the process of the in-place load release shutdown mode, which includes steps 701 to 703. Steps 701 to 702 are similar to steps 201 to 202.

[0090] In step 703, the server detects whether the AGV to be shut down supports on-the-spot offloading.

[0091] If the server detects that the AGV to be shut down supports on-the-spot load release, it generates a task and an instruction for on-the-spot load release and sends the task and instruction to the AGV to be shut down so that the AGV to be shut down executes the task for on-the-spot load release.

[0092] As an example, after receiving a completion message of a task for unloading on the spot, the server identifies the current state of the AGV to be shut down as an unloaded state.

[0093] As another example, the server monitors the execution status of a task for unloading on the spot, and when the task for unloading on the spot is completed, identifies the current state of the AGV to be shut down as an unloaded state.

[0094] In order to facilitate the execution of processing of the AGV to be shut down that satisfies the shutdown condition, the AGV to be shut down that is in a non-loaded state is identified as an AGV to be shut down that is in a first state, timing of the shutdown lifecycle is started, and processing of the AGV to be shut down that satisfies the shutdown condition is executed within the shutdown lifecycle.

[0095] After the AGV to be shut down unloads its load on the spot, update the related location information corresponding to the load identifier (e.g., cargo number) in the first table of the database. The first table includes at least the correspondence between the load identifier, the current location information of the load to be unloaded, the information of the AGV to be shut down, and the task information. After switching the server to the normal operation mode, the server switches the starting location of the load identifier task to the current location of the load to be unloaded recorded in the first table, so that the AGV to be shut down can load its original load on the spot after starting up and return to the state before unloading its load on the spot.

[0096] When the server detects that the AGV to be shut down does not support on-site load unloading, it collects abnormality information and returns a response message to the monitoring client, which includes information about the AGV to be shut down due to an abnormality.

[0097] In this step, a mapping container is used to store the identification information of the abnormal equipment. The key value is the equipment identifier of the AGV to be shut down, and the value is an abnormality information structure. The data structure includes a shutdown process completion identifier and a shutdown abnormality type. Here, different values ​​in the shutdown process completion identifier indicate that the process is not completed or completed, respectively. Different values ​​in the shutdown abnormality type indicate different types, such as the AGV equipment with the shutdown abnormality being in a loading state, the AGV equipment with the shutdown abnormality being in a low-power state, the AGV equipment with the shutdown abnormality being in a task-running state, the AGV equipment with the shutdown abnormality being in an abnormal state itself, the AGV equipment being in a stay state, the AGV equipment being shelf-bound, etc.

[0098] A function to retrieve reported robot information is called to retrieve the reported information by the AGV's equipment identifier, and the reported information related to communication with the monitoring client is appended.

[0099] For example, in a shutdown mode that releases a load on the spot, an AGV in the first state or the no-load state to be shut down may be determined as an AGV that satisfies the shutdown condition. It should be understood that the processing processes in each shutdown mode may be alternative or combined according to business needs. When the shutdown mode is alternative, the processing processes in each shutdown mode are executed independently. When the shutdown modes are combined, for example, when the business needs are to release a load, then charge, and then shut down, or to release a load and shut down after releasing the load, or to shut down after completing load release and charging in parallel, the processing processes in each shutdown mode may be combined.

[0100] 8, which is a schematic diagram of a shutdown cancellation process, which is used to terminate a currently running shutdown process, including steps 801 and 802.

[0101] In step 801, the monitoring client sends a shutdown cancel request to the server in response to a shutdown cancel operation input by the user.

[0102] In step 802, the server analyzes the shutdown cancellation request, determines it as a shutdown cancellation, clears the shutdown lifecycle time to end the current shutdown lifecycle, terminates the current running task, ends the current shutdown mode, switches to normal operation mode, terminates the shutdown process, and returns a shutdown cancellation success response to the monitoring client to notify the user that the shutdown operation has been canceled.

[0103] In this embodiment, an associated task related to the shutdown task is triggered by the allocation library, and is generated by the server processing the output of the allocation library using a function for processing the shutdown task. An instruction for the associated task is generated by a function for instruction encapsulation calling a protocol plug-in interface, inputting necessary parameters, encapsulating the packet into an instruction packet, and sending the instruction packet to the AGV via a transmission interface for execution.

[0104] This embodiment enables the shutdown of multiple AGVs in a designated area. The shutdown process can be canceled at any time during the shutdown process, and the AGVs can automatically start up when their wake-up time arrives. This improves the startup and shutdown efficiency of multiple AGVs and simplifies user operation. By executing the shutdown process for AGVs that meet the shutdown conditions, a balance is maintained between the ongoing tasks and the shutdown. The shutdown is performed only after the shutdown conditions are met, such as when tasks are prioritized or when the required power level is reached. This prevents AGVs from being unable to start up and start up to perform tasks online, and ensures that AGVs that can be shut down are shut down reliably. A reply message sent from the server to the terminal displays detailed information about each AGV to be shut down, allowing the user to manually intervene in AGVs that cannot be shut down, improving AGV management.

[0105] FIG. 9 is a schematic diagram of a terminal according to an embodiment of the present invention, which includes: The device includes a first response module that, in response to a shutdown operation input by a user, includes configurable wake-up time information and identification information of a robot to be shut down, sends a shutdown request to a server for providing a robot control service, to which the wake-up time information and the identification information of the robot to be shut down are added, thereby causing the server to execute steps of a wake-up method in a shutdown state of any of the robots.

[0106] Referring to FIG. 10, FIG. 10 is a schematic diagram of a scheduling server according to an embodiment of the present invention, which includes: a second response module for responding to a shutdown request from a terminal for controlling robot operation, the shutdown request being generated by the terminal in response to a shutdown operation input by a user, the shutdown request including configurable wake-up time information and identification information of the robot to be shut down, and the wake-up time information and the identification information of the robot to be shut down being added to the shutdown request; and a startup / shutdown control module for transmitting to the robot to be shut down related tasks associated with the shutdown task and a shutdown command to which the wake-up time information is added based on the identification information of the robot to be shut down, so that the robot to be shut down executes a shutdown command after completing the related task, enters a shutdown state in which it is not connected to the terminal and the server after executing the shutdown command, and starts up according to the wake-up time information in the shutdown command.

[0107] As an example, the scheduling server may: It further includes a status acquisition module for acquiring the current status of the robot to be shut down.

[0108] 11 is a schematic diagram of a terminal and a scheduling server according to an embodiment of the present invention. The terminal includes a memory and a processor, a computer program stored in the memory, and the processor executes the computer program to perform steps of the method for waking up a robot in a shutdown state according to an embodiment of the present invention. The scheduling server includes a memory and a processor, a computer program stored in the memory, and the processor executes the computer program to perform steps of the method for waking up a robot in a shutdown state according to an embodiment of the present invention.

[0109] The memory may include random access memory (RAM) and may include at least one non-volatile memory (NVM), such as a magnetic disk memory. Optionally, the memory may be at least one storage device located remotely from the processor.

[0110] The processor may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc., or may be a Digital Signal Processing (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component.

[0111] An embodiment of the present invention further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs steps of a method for waking up a robot in a shutdown state according to an embodiment of the present invention.

[0112] The embodiments of the device / network side device / storage medium are basically similar to the embodiments of the method, so the explanation is simple, and you can refer to the explanation of part of the embodiments of the method for the relevant parts.

[0113] As used herein, relational terms such as "first" and "second" are used solely to distinguish one entity or operation from another and do not necessarily require or imply the existence of any actual relationship or order between those entities or operations. Furthermore, the terms "comprises," "in addition to," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or device that includes a set of elements not only includes those elements, but also other elements not expressly listed or inherent in such process, method, article, or device. Absent more limitations, elements qualified by the phrase "comprises ..." do not exclude the presence of other identical elements in the process, method, article, or device that includes said elements.

[0114] The above is only a preferred embodiment of the present invention, and is not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for waking up a robot in a shutdown state, the method being executed by a server for providing a robot control service, a step in which the server responds to a shutdown request from a terminal for controlling robot operation, the shutdown request being generated by the terminal in response to a shutdown operation input by a user, the shutdown operation including settable wake-up time information and identification information of the robot to be shut down, and the wake-up time information and the identification information of the robot to be shut down being added to the shutdown request; the server transmits to the robot to be shut down the associated task related to the shutdown task and the shutdown command to which the wake-up time information is added, based on identification information of the robot to be shut down, so that the robot to be shut down executes a shutdown command after completing the associated task, enters a shutdown state in which it is not connected to the terminal and the server after executing the shutdown command, and starts up in accordance with wake-up time information in the shutdown command; the number of robots to be shut down is one or more; A method for waking up a robot in a shutdown state, comprising:

2. the step of the server transmitting, in response to the shutdown request, to the robot to be shut down, the associated task related to the shutdown task and the shutdown command to which the wake-up time information is added, based on identification information of the robot to be shut down, the server, in response to the shutdown request, creates the associated task associated with the shutdown task and generates the shutdown command to which the wake-up time information is added; the server transmitting the related task to the robot to be shut down that satisfies a shutdown condition so that the robot to be shut down executes the related task; the server sending the shutdown command to the robot that has completed the related task, so that the robot that has completed the related task executes the shutdown command; 2. The method for waking up a robot in a shutdown state according to claim 1.

3. The shutdown operation further includes shutdown mode information, and each of the robots to be shut down corresponds to the same shutdown mode; The step of creating the associated task related to the shutdown task in response to the shutdown request and generating the shutdown command to which the wake-up time information is added includes: analyzing the shutdown request and obtaining information to be added to the shutdown request; creating the associated task based on shutdown mode information attached to the shutdown request; generating the shutdown command to which the wake-up time information is added based on wake-up time information added to the shutdown request; The step of transmitting the related task to the robot to be shut down that satisfies the shutdown condition includes: determining the robot to be shut down that satisfies the shutdown condition based on the current state of the robot to be shut down; sending the associated task to the robot to be shut down that satisfies the shutdown condition; 3. The method for waking up a robot in a shutdown state according to claim 2.

4. The shutdown operation further includes a shutdown life cycle for setting a shutdown waiting time, and each robot to be shut down corresponds to the same shutdown life cycle; The shutdown request further includes the shutdown lifecycle; The step of transmitting the related task to the robot to be shut down that satisfies the shutdown condition includes: sending the associated task to the robot to be shut down that satisfies the shutdown condition within the shutdown lifecycle and when the shutdown lifecycle is not about to end; The step of sending the shutdown command to the robot to be shut down that has completed the associated task includes: If the shutdown lifecycle is about to end, sending the shutdown command to the robot to be shut down that has completed the associated task; The method comprises: If the shutdown lifecycle has not ended, monitoring the current state of the robot to be shut down in real time; The method further includes the step of processing the robot to be shut down that does not satisfy the shutdown condition within the shutdown lifecycle and when the shutdown lifecycle is not about to end.

3. The method for waking up a robot in a shutdown state according to claim 2.

5. Processing the robot to be shut down that does not satisfy the shutdown condition includes: If the robot to be shut down is in an abnormal state that cannot be recovered from, identifying the robot to be shut down as an abnormal robot to be shut down; If the robot to be shut down is in a recoverable abnormal state and meets the shutdown power budget, recording abnormality information of the robot to be shut down; If the robot to be shut down is in a recoverable abnormal state, does not meet the shutdown power budget, and is compatible with low-power charging, identify the state of the robot to be shut down as a state that requires charging, and perform a wake-up of the shutdown state in a shutdown mode that supports charging; Identifying the robot to be shut down as a low-power robot if the robot to be shut down is in a recoverable abnormal state, does not meet the shutdown power budget, and is not compatible with low-power charging; 5. The method for waking up a robot in a shutdown state according to claim 4.

6. the robot is a mobile robot, The step of transmitting the related task to the robot to be shut down that satisfies the shutdown condition includes: a step of matching the robot to be shut down in a first state with the closest shutdown pause location, and if the matching of the shutdown pause location is successful, identifying the current state of the robot to be shut down as a second state, wherein the first state is used to indicate that the robot to be shut down is waiting for shutdown and cannot be charged, and the second state is used to indicate that the robot to be shut down is in a state matched with the shutdown pause location; creating the associated task and the shutdown command for the robot to be shut down to move to the shutdown pause position; sending the associated task and the shutdown command to the robot to be shut down in the second state to execute the task to move to the shutdown pause position; acquiring an execution status of a task for moving to the shutdown pause position of the robot to be shut down, and when the task for moving to the shutdown pause position is completed, identifying a current state of the robot to be shut down as a third state, the third state being used to indicate that the robot to be shut down is in a state waiting for transmission of the shutdown command; The step of sending the shutdown command to the robot to be shut down that has completed the associated task includes: transmitting the shutdown command to the robot to be shut down in the third state, thereby causing the robot to perform a shutdown operation; 4. The method for waking up a robot in a shutdown state according to claim 3.

7. the shutdown mode is a normal shutdown mode, and the normal shutdown mode is used to perform a wake-up in a shutdown state for a robot that has no shutdown condition constraints; The step of creating the associated task based on shutdown mode information added to the shutdown request includes: identifying a current state of the robot to be shut down as the first state based on the normal shutdown mode information; creating the associated task and the shutdown command for the robot to be shut down to move to the shutdown pause position; 7. The method for waking up a robot in a shutdown state according to claim 6.

8. the shutdown mode is a charge-enabled shutdown mode, and the charge-enabled shutdown mode is used to wake up a low-power robot whose current power amount is lower than a predetermined power amount threshold in a shutdown state; The step of creating the associated task based on shutdown mode information added to the shutdown request includes: Identifying a current state of the robot to be shut down as a fourth state based on the charge-enabled shutdown mode information, the fourth state being used to indicate that the robot to be shut down is waiting for shutdown and is in a state where charging is possible; matching the location of a charging station to the robot to be shut down in the fourth state; creating the associated task and the shutdown command for the robot to be shut down to move to the charging station and charge; before transmitting the associated task to the robot to be shut down that satisfies the shutdown condition, transmitting the associated task for moving to the charging station and charging and the shutdown command to the robot to be shut down in the fourth state, causing the robot to be shut down in the fourth state to execute the associated task for moving to the charging station and charging; acquiring a current power energy state of the robot to be shut down, updating the current state of the robot to be shut down in the fourth state based on the acquired current power energy state, and if the current power energy state satisfies a shutdown power energy threshold, identifying the current state of the robot to be shut down as a first state, and transmitting the associated task to the robot to be shut down that satisfies the shutdown condition.

7. The method for waking up a robot in a shutdown state according to claim 6.

9. the shutdown mode is a shutdown mode for releasing a load on the spot, and the shutdown mode for releasing a load on the spot is used to wake up a robot capable of releasing a load in a shutdown state; The step of creating the associated task based on shutdown mode information added to the shutdown request includes: When detecting that the robot to be shut down supports on-the-spot load offloading, creating the associated task and the shutdown command for the robot to be shut down to offload on-the-spot; before transmitting the associated task to the robot to be shut down that satisfies the shutdown condition, transmitting the associated task for immediately releasing a load and the shutdown command to the detected robot to be shut down, thereby causing the detected robot to be shut down to execute the associated task for immediately releasing a load; acquiring an execution status of the associated task for releasing a load on the spot of the robot to be shut down, and when the task for releasing a load on the spot is completed, identifying a current state of the robot to be shut down as a first state, and transmitting the associated task to the robot to be shut down that satisfies the shutdown condition; 7. The method for waking up a robot in a shutdown state according to claim 6.

10. The robots to be shut down in the same shutdown request share the same wake-up time information.

2. The method for waking up a robot in a shutdown state according to claim 1.

11. A method for waking up a robot in a shutdown state, the method being executed by a terminal for controlling robot operation, a step of causing a server for providing a robot control service to execute the method for waking up a robot in a shutdown state according to any one of claims 1 to 10, by transmitting a shutdown request to the server for providing a robot control service in response to a shutdown operation input by a user, the shutdown request including the wake-up time information and the identification information of the robot to be shut down; the number of robots to be shut down is one or more; A method for waking up a robot in a shutdown state, comprising:

12. a first response module for, in response to a shutdown operation input by a user, including settable wake-up time information and identification information of a robot to be shut down, transmitting a shutdown request to a server for providing a robot control service, to which the wake-up time information and the identification information of the robot to be shut down are added, thereby causing the server to execute the method for waking up a robot in a shutdown state according to any one of claims 1 to 10; A terminal characterized by:

13. a second response module for responding to a shutdown request from a terminal for controlling robot operation, the shutdown request being generated by the terminal in response to a shutdown operation input by a user, the shutdown request including settable wake-up time information and identification information of the robot to be shut down, and the wake-up time information and the identification information of the robot to be shut down being added to the shutdown request; a startup / shutdown control module for transmitting the associated task related to the shutdown task and the shutdown command to which the wake-up time information is added to the robot to be shut down based on identification information of the robot to be shut down, so that the robot to be shut down executes a shutdown command after completing the associated task, enters a shutdown state in which it is not connected to the terminal and the server after executing the shutdown command, and starts up in accordance with wake-up time information in the shutdown command; the number of robots to be shut down is one or more; A scheduling server for providing a robot control service.

14. A system including the terminal according to claim 12 and the scheduling server according to claim 13. A system for managing robots.

Images