Method and device for waking up a robot from a shut-down 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 the priority of a Chinese patent application filed on March 27, 2023, with application number 202310305983.9, and all of its content is incorporated herein by reference.

[0002] The present invention relates to the field of robot control, and in particular, to a wake - up method for a robot in a shutdown state.

Background Art

[0003] With the rapid development of the robot industry, the number of robot devices accessed by a server for providing robot control services has increased explosively.

[0004] In the actual scene of a large - scale plant equipped with multiple facilities, it is necessary to shut down a large number of robots during daily leaving work or holidays. For example, when shutting down hundreds of automated guided vehicles (AGVs), it is necessary to shut them down after the current tasks of each robot are completed, and they cannot be shut down immediately. Manual operation is very time - consuming, and it is also necessary to manually start each facility one by one at the start of work. Due to the large number of robots, it takes a lot of time for the shutdown and wake - up of robots in the shutdown state, not only with low efficiency but also with a low degree of automation.

Summary of the Invention

[0005] The first aspect of the present invention provides a wake - up method for a robot in a shutdown state, and the method is executed by a server for providing robot control services. A step of responding to a shutdown request from a terminal for robot operation control, wherein the shutdown request is generated by the terminal in response to a shutdown operation input by the user, which includes configurable wake-up time information and identification information of the robot to be shut down, and the wake-up time information and identification information of the robot to be shut down are added to the shutdown request. The process includes sending the associated tasks 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 the identification information of the robot to be shut down, such that the robot to be shut down executes a shutdown command after completing associated tasks, enters a shut-down state where 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 from a shutdown state, the method being performed by a terminal for robot operation control, The terminal, in response to a shutdown operation input by the user, which includes configurable wake-up time information and identification information of the robot to be shut down, sends a shutdown request to a server providing robot control services, to which the wake-up time information and identification information of the robot to be shut down are added, thereby causing the server to perform a wake-up method for any of the robots in a shut-down state. The number of robots to be shut down is one or more.

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

[0008] A fourth aspect of the present invention provides a scheduling server for providing robot control services, the scheduling server is A second response module for responding to a shutdown request from a terminal for robot operation control, wherein the shutdown request is generated by the terminal in response to a shutdown operation input by the user, which includes configurable wake-up time information and identification information of the robot to be shut down, and the wake-up time information and identification information of the robot to be shut down are added to the shutdown request, the second response module The system includes a startup / shutdown control module for sending the robot to be shut down the associated tasks related to the shutdown task and the 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 associated tasks, enters a shut-down state where 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 robot management system including the terminal and the scheduling server. [Effects of the Invention]

[0010] The 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 shutdown command to the robot to be shut down, along with related tasks associated with the shutdown task and wake-up time information, via a server. This causes the robot to execute the shutdown command after completing the related tasks, enters a shutdown state after executing the shutdown command, and is then started up in the shutdown state according to the wake-up time information in the shutdown command. This eliminates the need to manually shut down the robot after its current task is completed, enabling automatic robot startup and shutdown. This is advantageous for achieving one-key group shutdown and one-key group startup for large groups of robots, and can improve the efficiency of shutting down and starting large groups of robots. [Brief explanation of the drawing]

[0011] [Figure 1] This is a flowchart illustrating a method for waking up a robot from a shutdown state according to an embodiment of the present invention. [Figure 2a] This is a schematic diagram of the shutdown process for a wake-up method in the shutdown state of a normal shutdown mode according to an embodiment of the present invention. [Figure 2b] This is a schematic diagram of the shutdown operation interface on the monitoring client side. [Figure 3] This is a schematic diagram of the processing process for AGVs that should be shut down when the shutdown conditions are met. [Figure 4] This is a schematic diagram of the processing process for AGVs that should be shut down if they do not meet the one-key shutdown conditions. [Figure 5] This is a schematic diagram of the state changes identified by the server during a normal shutdown of an AGV in normal shutdown mode, and the transition conditions between state changes. [Figure 6] This is a schematic diagram of the processing process for the shutdown mode with charging capabilities. [Figure 7] It is a schematic diagram of a processing process in a shutdown mode for releasing a load on-site. [Figure 8] It is a schematic diagram of a shutdown cancellation process. [Figure 9] It is a schematic diagram of a terminal according to an embodiment of the present invention. [Figure 10] It is a schematic diagram of a scheduling server according to an embodiment of the present invention. [Figure 11] It is a schematic diagram of a terminal and a scheduling server according to an embodiment of the present invention.

Mode for Carrying Out the Invention

[0012] In order to make the object, 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] As shown in FIG. 1, FIG. 1 is a flowchart for realizing a wake-up method in a shutdown state of a robot according to an embodiment of the present invention. The method includes steps 101 to 103.

[0014] In step 101, a terminal for robot operation control responds to a shutdown operation including at least wake-up time information that can be set by a user and identification information of a robot to be shut down, and transmits a shutdown request with at least the wake-up time information and the identification information of the robot to be shut down added to a server for providing a robot control service.

[0015] As an example, the shutdown operation further includes at least one of selectable shutdown mode information and settable shutdown lifecycle information. The shutdown lifecycle information is used to set a shutdown waiting time so as to control the execution and end of the shutdown process of the robot to be shut down.

[0016] In step 102, in response to a shutdown request from a terminal for robot operation control, 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] As an example, at least one of shutdown lifecycle information and shutdown mode information is further added to the shutdown request. The shutdown mode includes one or a combination of a normal shutdown mode, a shutdown mode corresponding to charging, and a shutdown mode for releasing the load in-situ.

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

[0019] The shutdown mode corresponding to charging is used to wake up in the shutdown state for a low-power robot whose current power amount is lower than a predetermined power amount threshold.

[0020] The shutdown mode for releasing the load in-situ is used to wake up in the shutdown state for a robot capable of releasing the load.

[0021] As an example, the shutdown task in an embodiment of the present invention includes a shutdown operation performed by the robot to be shut down in response to a shutdown command from a server, and a wake-up operation in the shutdown state, and related tasks associated with the shutdown task include tasks that must be performed in order to complete the shutdown task. Related tasks are related to shutdown modes, and different shutdown modes may correspond to different related tasks. In a charging-enabled shutdown mode, the related task is to move to a charging station and charge. In a shutdown mode that releases the load in place, the related task is to release the load. Also, different shutdown modes may correspond to the same related task, namely, the task of 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 charging-enabled shutdown mode and the shutdown mode that releases the load in place are conditional shutdown modes.

[0022] Furthermore, the shutdown mode is not limited to the above modes and may be designed according to the specific service needs of the application scenario. Related tasks are not limited to the above tasks and may be determined according to the specific service needs of the application scenario.

[0023] For example, a server can improve efficiency by reducing interaction with terminals and robots in response to a shutdown request by creating related tasks and generating shutdown commands. By sending related tasks to robots that meet the shutdown conditions and then sending shutdown commands to robots that have completed those tasks, the server can not only reduce its bandwidth usage but also balance the tasks being performed by the robots that need to be shut down with the shutdown process itself.

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

[0025] As an example, the current state of robots that should be shut down is monitored in real time within the shutdown lifecycle. This improves the accuracy of robot status information.

[0026] Within the shutdown lifecycle, and when the shutdown lifecycle is not yet complete, the system sends the relevant tasks to the robots that should be shut down and processes the robots that do not meet the shutdown conditions. This improves the reliability of the shutdown operation, contributes to balancing tasks and shutdowns, and avoids getting stuck in a dead cycle due to anomalies.

[0027] At least when the shutdown lifecycle is nearing its end, a shutdown command is sent to the robots that have completed their related tasks and are ready to shut down. This ensures that the sending of shutdown commands does not occur after the end of the shutdown lifecycle, improving the server's centralized processing capacity and enhancing the reliability of shutdowns by a large number of robots.

[0028] After the shutdown lifecycle is complete, 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 status of the robots and perform corresponding manual processing, which is useful for robot management. In the embodiments of the present invention, the server controls the status of the robots according to its own operation mode. For example, if the server's operation mode is "normal operation mode," it controls the robots to be in an operational state such as loading or unloading. For example, if the server's operation mode is "shutdown mode," it controls the robots to be in an inoperable state (waiting to shut down). The server's shutdown modes include normal shutdown mode, charging-enabled shutdown mode, and on-the-spot load release shutdown mode. For example, if the server analyzes that a shutdown request includes normal shutdown mode, the server switches to normal shutdown mode and, in normal shutdown mode, identifies the current status of all online AGVs to be shut down as waiting to shut down and unable to charge. If the server analyzes that a shutdown request includes charging-enabled shutdown mode, the server switches to charging-enabled shutdown mode and identifies the status of each online AGV to be shut down as waiting to shut down and able to charge.

[0029] For example, the shutdown lifecycle may start counting from the moment a shutdown request is received, and the time remaining until it is about to end may be determined based on a configured time threshold. For instance, if the time threshold is 30 seconds and the shutdown lifecycle is 5 minutes, the 30 seconds immediately preceding the end of the shutdown lifecycle may be understood as the time remaining until it is about to end.

[0030] In step 103, the robot to be shut down responds to the associated task and the shutdown command by first executing the associated task, completing the associated task, and then executing the shutdown command. After executing the shutdown command, the robot to be shut down enters a shutdown state, disconnected from the terminal and 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 group of robots.

[0032] Each shutdown operation includes identification information for at least one robot to be shut down, and identification information for multiple robots to be shut down corresponds to the same wake-up time information, as well as the same shutdown mode and the same shutdown lifecycle. This enables one-key group shutdown and one-key group startup.

[0033] In this embodiment of the present invention, the server can perform shutdown operations on a vast number of robots based on identification information of robots to be shut down set on the terminal, achieving the effect of one-key shutdown. Furthermore, it avoids the situation where a robot appears to be in a shut-down state but is actually in a sleep state sending listening frames to the terminal and / or server, thus achieving a true shutdown of the robot. Based on wake-up time information set on the terminal, robots in a shut-down state can start up on their own, 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 explanation will use an AGV (Automated Guided Vehicle) as an example. It should be understood that the present invention is not limited to AGVs and is applicable to any other controlled robot.

[0035] The following explains the technical terms related to this embodiment.

[0036] Monitoring client: An application program that provides human-computer interaction to control AGVs via a server, and can run on terminals such as intelligent terminals and computer terminals.

[0037] Shutdown modes include a normal shutdown mode, a charging-enabled shutdown mode, and an on-the-spot load-relieving shutdown mode. The charging-enabled shutdown mode and the on-the-spot load-relieving shutdown mode are variations of the normal shutdown mode with additional restrictions. The following table describes each shutdown mode. [Table 1]

[0038] Assignment Library: Located on the scheduling side (server side), it is used to assign tasks to AGVs. In the shutdown process, it assigns AGVs to the nearest shutdown pause location.

[0039] The main states of the AGV identified by the server are as follows: First state: Waiting to shut down and unable to charge. Second state: Matched to the shutdown pause position. Third state: Waiting for the shutdown command to be sent. Fourth state: Waiting to shut down and ready to charge.

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

[0041] In step 201, the monitoring client provides the user with the option to select a shutdown mode and set shutdown parameters, and in response to the shutdown operation entered by the user, including the shutdown parameters, sends a shutdown request to the server to which the shutdown parameters are added.

[0042] For example, shutdown parameters include a shutdown lifecycle for setting the shutdown wait time, wake-up time information, device identifier (Device ID) information for the AGV to be shut down, and a shutdown mode. Here, the shutdown mode is the normal shutdown mode. The wake-up time information and shutdown lifecycle values ​​entered by the user are restricted to prevent the submission of unreasonable requests. For example, if the current time is 7:15 PM on March 27, 2023, and the wake-up time entered by the user is 8:00 PM on March 26, 2023, and the wake-up time is earlier than the current time, it will be considered an unreasonable shutdown request.

[0043] Referring to Figure 2b, which is a schematic diagram of the shutdown operation interface on the monitoring client side, this interface includes controls for selecting the shutdown mode, shutdown wait time (i.e., shutdown lifecycle), wake-up time, and the number of the AGV to be shut down. Multiple AGVs to be shut down are configured with the same shutdown lifecycle, wake-up time, and shutdown mode. In other words, AGVs to be shut down in the same shutdown operation entered by the user are uniformly configured with the same shutdown lifecycle, wake-up time, and shutdown mode, thereby enabling group shutdown and group startup operations, and AGVs to be shut down in the same shutdown request share the same wake-up time.

[0044] In step 202, the server responds to the received shutdown request by analyzing the request, determining based on the analysis results that the selected shutdown mode is a normal shutdown mode, and then verifying 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 sent back to the monitoring client, which then informs the user that the shutdown process has started successfully, and step 203 is executed. If the verification fails, a failure response message is sent back to the monitoring client. The cause of the failure is added to this message, so that the monitoring client can inform the user of the failure of the shutdown process and the cause of the failure.

[0046] For example, the shutdown request parsing function is implemented by adding a parsing function for shutdown request messages in the message processing index table, performing parsing of shutdown parameters in the shutdown request message within that function, encapsulating a reply message indicating whether the shutdown was successful or not, constructing an information structure parameter object for switching the server's operating mode, calling a function to set an identification value for the server's operating mode to activate it, and triggering the server to switch to shutdown operation mode. For example, the response message may include return values ​​indicating information such as cancellation failure, invalid value received, failure to parse shutdown parameters, successful execution of the shutdown operation, successful cancellation of the shutdown operation, shutdown wait time less than the minimum value, shutdown wait time greater than the maximum value, and invalid shutdown mode, with different information having different return values.

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

[0048] As an example, you can further trigger the start of shutdown lifecycle timing and prevent new tasks from entering the allocation library.

[0049] In step 204, the server determines whether the shutdown lifecycle has ended.

[0050] When the shutdown lifecycle ends, the shutdown process terminates, the server exits normal shutdown mode and switches to normal operation mode, sends the current status of each AGV to be shut down to the assignment library, and sends a success response message to the monitoring client with information about the AGVs that should be shut down abnormally, thereby informing the user which AGVs should be shut down abnormally.

[0051] In this step, as an example, within the shutdown lifecycle, each time the server has completed traversing all AGVs that should be shut down and have been identified as being in a non-shutdown state, a function for retrieving shutdown reports is called to report shutdown anomaly information. This function first updates the corresponding content in the container that collects shutdown anomaly 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 shutdown reports also sends anomaly information attached to the shutdown result response message to the monitoring client for processing. For example, anomaly information may include at least one of the following: the AGV is loaded, the AGV is in a low-power state, the AGV itself is in an anomaly state, the AGV is locked, or the AGV has shelf binding.

[0052] The response message in this step includes a label field to indicate an attribute and a status value. Here, if the label field has a first value, it identifies that the shutdown status of the AGV is being reported while the shutdown process is in progress, and if the label field has a second value, it identifies that the shutdown status information of the AGV is being reported after the shutdown process has been completed. Different status values ​​indicate different states, for example, the AGV itself is in an abnormal state, the AGV is still performing a task, the AGV is in a low-power state, the AGV is in a loaded state, the default state, the AGV has been selected for the shutdown pause position, the AGV equipment has moved to the shutdown pause position and is waiting to receive a shutdown command, and the AGV equipment has received a shutdown command.

[0053] If the shutdown lifecycle has not ended, the current state of the robot to be shut down is monitored in real time, preferably the current state of the AGV to be shut down is returned, and step 205 is performed. In step 205, the server determines whether the shutdown lifecycle has reached a set time threshold and whether the shutdown lifecycle is about to end.

[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, which is in a third state. The current state of the AGV to be shut down is identified as the state in which the shutdown command is being executed, causing the AGV to respond to the shutdown command and perform the shutdown. Here, the third state is used to indicate a state that is waiting for the transmission of a shutdown command, and the shutdown command includes shutdown operation information and wake-up time information. For example, the shutdown operation information may be to automatically restart at a set time, and the set time is controlled by the wake-up time information. Alternatively, the shutdown operation information may be to shut down immediately without restarting.

[0055] For example, the server monitors the status of AGVs that should be shut down performing the shutdown operation, and after the shutdown operation is complete, identifies the current state of the AGVs that should be shut down as the shutdown state.

[0056] After the AGV that should be shut down has shut down, it disconnects from the server and terminals, enters a shutdown state, triggers the start of wake-up timekeeping, and when the timer reaches the wake-up time, the AGV that should be shut down starts up on its own.

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

[0058] For example, the shutdown lifecycle is monitored by the server recording the start time of the process, then calculating the difference between the current time and the start time at regular intervals, and comparing it with the shutdown lifecycle to control the shutdown lifecycle.

[0059] If the shutdown lifecycle has not reached the set time threshold, it indicates that the shutdown lifecycle is not about to end, and the processing steps for AGVs that should be shut down because the shutdown conditions are met are executed, as well as the processing steps for AGVs that should be shut down because the shutdown conditions are not met, and then the process returns to step 204.

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

[0061] In step 3051, the scheduling (server) assignment library efficiently aggregates AGVs to be shut down by matching the AGV to be shut down with the nearest shutdown pause position for each AGV that is in the first state.

[0062] The server determines whether or not it has found a match for the shutdown pause position. If it has found a match for the shutdown pause position, it executes step 3052; otherwise, it determines that the AGV to be shut down does not meet the shutdown conditions and terminates this process.

[0063] Regarding the AGV that should be shut down based on 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, and the second state is used to indicate that the AGV has matched the shutdown pause position.

[0065] In step 3053, the server generates a task and command to move to the shutdown pause location based on the shutdown pause location information output from the assignment library, and sends the task and command to move to the shutdown pause location to the AGV that should be shut down, causing the AGV to respond to the command and execute the task to move to the shutdown pause location. Here, the shutdown pause location information is attached to the command to move to the shutdown pause location.

[0066] For example, in step 3054, the AGV to be shut down determines whether the task to move to the shutdown pause position has been completed. If the task to move to the shutdown pause position has been completed, it reports a message to the server indicating that the task to move to the shutdown pause position has been completed. The server then identifies the current state of the AGV to be shut down as a third state, and this third state is used to indicate that the AGV is waiting to receive a shutdown command.

[0067] As another example, the server monitors the execution status of a task to move an AGV to be shut down to a shutdown pause position, and when the task to move to the shutdown pause position is completed, it 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 is not completed, the AGV that should be shut down will perform a movement anomaly procedure.

[0069] As shown in Figure 4, Figure 4 is a schematic diagram of the processing process for AGV equipment that should be shut down if the one-key shutdown conditions are not met. 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 unrecoverable abnormal state. If so, the AGV to be shut down is identified as a shutdown abnormal device and is prohibited from entering the shutdown process; otherwise, step 4052 is executed.

[0071] In step 4052, it is determined whether the AGV to be shut down meets the shutdown power requirement. If so, abnormal information for the AGV to be shut down is recorded, and the AGV to be shut down is prevented from entering the shutdown process; otherwise, step 4053 is executed.

[0072] In step 4053, it is determined whether the AGV to be shut down supports low-power charging. If so, the current state of the AGV to be shut down is identified as a state that should be charged, and the charging-enabled shutdown mode processing process is executed. Otherwise, the AGV to be shut down is identified as a low-power device, and it is prohibited 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 a normal shutdown of the AGV in normal shutdown mode, and the transition conditions between state changes.

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

[0075] In this embodiment, during the lifecycle, after performing a single related process for all online AGVs that should be shut down, the server can report the abnormal devices and causes of the abnormalities detected in that process to the monitoring client. The monitoring client displays this information to notify the user which devices are in a shutdown abnormal state and which devices require manual processing beforehand.

[0076] The charge-enabled shutdown mode is used to charge AGVs that need to be shut down but do not meet the shutdown power requirements before shutting them down. When the server switches from normal mode to the charge-enabled one-key shutdown mode, it does not enter a new task into the assignment library and identifies the status of each online AGV device to be shut down in the assignment library as a fourth state. The fourth state indicates a state where the device is waiting to be shut down and is ready to be charged.

[0077] Referring to Figure 6, which is a schematic diagram of the processing process for a charging-enabled shutdown mode, the process 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 charging-enabled shutdown mode and identifies the status of each online AGV device to be shut down as a fourth state, which is both awaiting shutdown and ready for charging.

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

[0080] In step 603, a task and command are generated to move to a charging station and charge, and these tasks and commands are sent to the AGV to be shut down. The AGV to be shut down responds with the task and command to move to a charging station and charge, executes the task to move to a charging station and charge, and invokes the charging process to charge. Here, the task and command to move to a charging station and charge are accompanied by the location information of the matched charging station.

[0081] For example, in step 604, the AGV that is to be shut down reports to the server a message indicating that it has completed the task of moving to the charging station and charging, and also reports to the server its current power status.

[0082] As another example, the server monitors the status of the task to move the AGV to the charging station and charge it, and if the task to move to the charging station and charge it is completed, it executes step 605, monitors the current power level of the AGV to be shut down, and executes step 605.

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

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

[0085] If the shutdown power threshold is met, the current state of the AGV to be shut down is identified as the first state, the shutdown lifecycle timing is started, and processing of the AGV to be shut down that meets the shutdown conditions 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 charging-enabled shutdown mode, an AGV that should be shut down because its current electrical state satisfies the shutdown electrical threshold, and an AGV that should be shut down because it is in a first state, may be determined as the AGV that should be shut down because it satisfies the shutdown conditions.

[0088] The shutdown mode, which releases the load on the spot, is used to handle AGVs that need to be shut down while under load (e.g., loaded).

[0089] Referring to Figure 7, which is a schematic diagram of the shutdown mode processing process that releases the load in place, 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 immediate load release.

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

[0092] For example, after receiving a completion message for a task to release the load on the spot, the server identifies the current state of the AGV that should be shut down as a non-loaded state.

[0093] As another example, the server monitors the execution status of tasks to release the load on the spot, and when those tasks are complete, it identifies the current state of the AGV that should be shut down as a non-loaded state.

[0094] To facilitate the execution of the process for AGVs that should be shut down because they meet the shutdown conditions, AGVs that are not under load and should be shut down are identified as AGVs that should be shut down in the first state, the shutdown lifecycle is started, and the process for AGVs that meet the shutdown conditions and should be shut down is executed within the shutdown lifecycle.

[0095] After the AGV to be shut down releases its load, the associated location information corresponding to the load identifier (e.g., cargo number) in the first table of the database is updated. The first table contains at least the correspondence between the load identifier, the current location information releasing the load, the information of the AGV to be shut down, and the task information. After switching the server to normal operation mode, the server switches the starting position of the load identifier task to the current location releasing the load, as recorded in the first table, so that the AGV to be shut down, after being started, loads its original load on the spot and returns to the state it was in before releasing the load on the spot.

[0096] When the server detects that an AGV that should be shut down does not support immediate load release, it collects anomaly information and sends a response message to the monitoring client that includes information about the AGV that should be shut down abnormally.

[0097] In this step, a mapping container is used to store identification information of the abnormal device. The key value is the device identifier of the AGV to be shut down, and the numerical value is the abnormal information structure. This data structure includes a shutdown process termination identifier and a shutdown abnormality type. Here, different numerical values ​​in the shutdown process termination identifier indicate that the process has not terminated or that the process has terminated, respectively. Different numerical values ​​in the shutdown abnormality type indicate different types, such as the AGV device being in a loaded state, the AGV device being in a low-power state, the AGV device being in a task execution state, the AGV device itself being in an abnormal state, the AGV device being in a stay state, or the AGV device having shelf binding.

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

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

[0100] Referring to Figure 8, which is a schematic diagram of the shutdown cancellation process, this shutdown cancellation process is used to terminate the currently running shutdown process. This includes steps 801 to 802.

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

[0102] In step 802, the server parses the shutdown cancellation request, determines it to be a shutdown cancellation, clears the shutdown lifecycle time to end the current shutdown lifecycle, terminates any currently running tasks, exits the current shutdown mode, switches to normal operation mode, terminates the shutdown process, and sends a shutdown cancellation success response to the monitoring client to notify the user that the shutdown operation has been canceled.

[0103] In this embodiment, related tasks associated with the shutdown task are triggered by the allocation library and generated when the server processes the output of the allocation library using a function for handling the shutdown task. Instructions for related tasks are generated when a function for instruction encapsulation calls the protocol plug-in interface, inputs the necessary parameters, encapsulates them in an instruction packet, and sends the instruction packet to the AGV via the transmission interface for execution.

[0104] This embodiment enables the shutdown of multiple AGVs in a designated area, allows the shutdown process to be canceled at any time, and enables automatic startup when the wake-up time is reached, thereby improving the startup and shutdown efficiency of multiple AGVs and simplifying user operation. By executing the shutdown process on AGVs that meet the shutdown conditions, it ensures a balance between running tasks and shutdowns, guaranteeing that shutdowns are performed only after tasks have been prioritized and shutdown conditions such as power consumption reaching the required level have been met. This prevents situations where AGVs cannot start and cannot start and perform tasks online, and ensures that AGVs that can be shut down are reliably shut down. Reply messages sent from the server to the terminal can display detailed information about each AGV that should be shut down to the user, allowing for manual intervention with AGVs that cannot be shut down and improving AGV management.

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

[0106] Referring to Figure 10, Figure 10 is a schematic diagram of a scheduling server according to an embodiment of the present invention, and this scheduling server is A second response module for responding to a shutdown request from a terminal for robot operation control, wherein the shutdown request is generated by the terminal in response to a shutdown operation input by the user, which includes configurable wake-up time information and identification information of the robot to be shut down, and the wake-up time information and identification information of the robot to be shut down are added to the second response module. The system includes a startup / shutdown control module for sending related tasks related to the shutdown task and a shutdown command to be shut down, with the wake-up time information added, to a robot to be shut down, 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 related tasks, enters a shut-down state where it is not connected to terminals and servers after executing the shutdown command, and starts up according to the wake-up time information in the shutdown command.

[0107] For example, a scheduling server is: It further includes a state acquisition module for obtaining the current state of robots that should be shut down.

[0108] Referring to Figure 11, which is a schematic diagram of a terminal and a scheduling server according to an embodiment of the present invention. The terminal includes memory and a processor, the memory storing a computer program, and the processor executes the computer program to perform the steps of the wake-up method for a robot in a shutdown state according to an embodiment of the present invention. The scheduling server includes memory and a processor, the memory storing a computer program, and the processor executes the computer program to perform the steps of the wake-up method for 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 also include at least one storage device located away from the processor.

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

[0111] Embodiments of the present invention further provide a computer-readable storage medium in which a computer program is stored, and when the computer program is executed by a processor, the steps of the wake-up method for a robot in a shutdown state according to embodiments of the present invention are performed.

[0112] The embodiments of the device / network-side equipment / storage medium are basically similar to the embodiments of the method, so the explanation is simple, and relevant sections can be found by referring to the partial explanation of the embodiments of the method.

[0113] In this specification, relational terms such as “first” and “second” are used solely to distinguish one entity or action from another, and do not necessarily require or imply that any actual relationship or order exists between these entities or actions. Furthermore, the terms “includes,” “added,” or any other variation thereof are intended to cover non-exclusive inclusion, and a process, method, article, or device containing a set of elements includes not only those elements but also other elements not explicitly listed, or elements specific to such a process, method, article, or device. Unless further restrictions are imposed, an element limited by the phrase “includes one…” does not preclude other identical elements from being present in a process, method, article, or device containing such element.

[0114] The foregoing are merely preferred embodiments of the present invention and do not limit it. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should all be within the scope of protection of the present invention.

Claims

1. A method for waking up a robot from a shutdown state, which is performed by a server providing robot control services. The server responds to a shutdown request from a terminal for robot operation control, wherein the shutdown request is generated by the terminal in response to a shutdown operation input by the user, which includes configurable wake-up time information and identification information of the robot to be shut down, and the wake-up time information and identification information of the robot to be shut down are added to the shutdown request. The server includes the step of sending the robot to be shut down the associated tasks related to the shutdown task and the shutdown command to which the wake-up time information is added, based on the identification information of the robot to be shut down, to the robot to be shut down, such that the robot executes a shutdown command after the robot to be shut down has completed the associated tasks, enters a shut-down state where 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. A method for waking up a robot from a shutdown state, characterized by the following:

2. The server, in response to the shutdown request, sends to the robot to be shut down, based on the identification information of the robot to be shut down, the associated tasks related to the shutdown task and the shutdown command to which the wake-up time information is added, The server, in response to the shutdown request, creates the associated tasks related to the shutdown task and generates the shutdown instruction to which the wake-up time information is added. The server takes the step of sending the associated task to the robot to be shut down that satisfies the shutdown conditions so that the robot to be shut down performs the associated task, The server includes the step of sending the shutdown command to the robot that has completed the associated task so that the robot to be shut down executes the shutdown command, A method for waking up a robot in a shut-down state, as described in feature 1.

3. The shutdown operation further includes shutdown mode information, and each robot to be shut down corresponds to the same shutdown mode. The step of creating the associated tasks related to the shutdown task and generating the shutdown instruction to which the wake-up time information is added in response to the shutdown request is: The steps include: analyzing the shutdown request and obtaining information attached to the shutdown request; The steps include creating the associated task based on the shutdown mode information attached to the shutdown request, The process includes the step of generating a shutdown command to which the wake-up time information is added, based on the wake-up time information added to the shutdown request, The step of sending the associated task to the robot to be shut down that meets the aforementioned shutdown conditions is: The steps include determining which robot to be shut down satisfies the shutdown conditions based on the current state of the robot to be shut down, The step of transmitting the associated task to the robot to be shut down that satisfies the aforementioned shutdown conditions, The method for waking up a robot in a shut-down state as described in feature 2.

4. The shutdown operation further includes a shutdown lifecycle for setting a shutdown waiting time, and each robot to be shut down corresponds to the same shutdown lifecycle. The shutdown request is further accompanied by the shutdown lifecycle, The step of sending the associated task to the robot to be shut down that meets the aforementioned shutdown conditions is: Within the shutdown lifecycle, and if the shutdown lifecycle is not about to end, the step includes sending the associated task to the robot to be shut down that satisfies the shutdown conditions, The step of sending the shutdown command to the robot that has completed the aforementioned related task is: If the shutdown lifecycle is nearing its end, the step includes sending the shutdown command to the robot that has completed the associated task and is to be shut down, The aforementioned method, If the shutdown lifecycle has not yet ended, the steps include 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 meet the shutdown conditions, if it is within the shutdown lifecycle and the shutdown lifecycle is not about to end. The method for waking up a robot in a shut-down state as described in feature 2.

5. Processing the robots that should be shut down but do not meet the aforementioned shutdown conditions is: If the robot to be shut down is in an unrecoverable abnormal state, the robot to be shut down is identified as a shutdown abnormal robot, If the robot to be shut down is in a recoverable abnormal state and the shutdown power requirement is met, the abnormal information of the robot to be shut down is recorded. If the robot to be shut down is in a recoverable abnormal state, does not meet the shutdown power requirement, and is compatible with low-power charging, the state of the robot to be shut down is identified as a state requiring charging, and the shutdown state is woken up in a charging-compatible shutdown mode. If the robot to be shut down is in a recoverable abnormal state, does not meet the shutdown power requirements, and does not support low-power charging, the robot to be shut down is identified as a low-power robot. The method for waking up a robot in a shut-down state as described in feature 4.

6. The aforementioned robot is a mobile robot, The step of sending the associated task to the robot to be shut down that meets the aforementioned shutdown conditions is: A step of matching the robot to be shut down, which is in a first state, with the nearest shutdown pause position, and if the matching of the shutdown pause position 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 in a state of waiting to be shut down and unable to be charged, and the second state is used to indicate that the robot to be shut down is in a state of matching with the shutdown pause position, The steps include creating the associated tasks and shutdown command for the robot to be shut down to move to the shutdown pause position, The steps include transmitting the associated tasks for moving to the shutdown pause position and the shutdown command to the robot to be shut down in the second state, thereby causing the robot to be shut down in the second state to perform the task for moving to the shutdown pause position, The steps include: obtaining the execution status of a task for moving the robot to be shut down to the shutdown pause position, and, if the task for moving to the shutdown pause position is completed, identifying the current state of the robot to be shut down as a third state, wherein the third state is used to indicate that the robot to be shut down is waiting for the transmission of the shutdown command; The step of sending the shutdown command to the robot that has completed the aforementioned related task is: The process includes the step of sending the shutdown command to the robot to be shut down, which is in the third state, thereby causing the robot to be shut down to perform a shutdown operation. A method for waking up a robot in a shut-down state, as described in feature 3.

7. The aforementioned shutdown mode is a normal shutdown mode, and this normal shutdown mode is used to wake up a robot in a shutdown state for robots without shutdown condition constraints. The step of creating the associated task based on the shutdown mode information attached to the shutdown request is: Based on the normal shutdown mode information, the step of identifying the current state of the robot to be shut down as a first state, The steps include creating the associated tasks and the shutdown command for the robot to be shut down to move to the shutdown pause position, The method for waking up a robot in a shut-down state according to feature 6.

8. The aforementioned shutdown mode is a charging-enabled shutdown mode, and the charging-enabled shutdown mode is used to wake up a low-power robot in a shutdown state if its current power level is lower than a predetermined power level threshold. The step of creating the associated task based on the shutdown mode information attached to the shutdown request is: A step of identifying the current state of the robot to be shut down as a fourth state based on the aforementioned shutdown mode information for charging, wherein the fourth state is used to indicate that the robot to be shut down is in a state where it is waiting to be shut down and is ready to be charged. The steps include matching the location of the charging station to the robot to be shut down in the fourth state, The steps include creating the associated tasks and shutdown command for the robot to be shut down to move to the charging station and be charged, Before transmitting the relevant task to the robot to be shut down that meets the aforementioned shutdown conditions, further, By transmitting the associated tasks and the shutdown command to the robot to be shut down in the fourth state, the robot to be shut down in the fourth state is made to perform the associated tasks for moving to the charging station and charging, The steps include: obtaining the current power 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 obtained current power state; identifying the current state of the robot to be shut down as the first state if the current power state satisfies the shutdown power threshold; and transmitting the associated task to the robot to be shut down that satisfies the shutdown conditions. The method for waking up a robot in a shut-down state according to feature 6.

9. The aforementioned shutdown mode is a shutdown mode that releases the load in place, and this shutdown mode that releases the load in place is used to wake up a robot in a shutdown state that is capable of releasing the load. The step of creating the associated task based on the shutdown mode information attached to the shutdown request is: If it is detected that there is a robot to be shut down that supports on-site load release, the process includes the step of creating the associated tasks and shutdown command for on-site load release to the robot to be shut down, Before transmitting the relevant task to the robot to be shut down that meets the aforementioned shutdown conditions, further, By transmitting the associated task for releasing the load on the spot and the shutdown command to the detected robot to be shut down, the detected robot to be shut down is made to execute the associated task for releasing the load on the spot. The process includes obtaining the execution status of the related task for releasing the load on the robot to be shut down in place, identifying the current state of the robot to be shut down as a first state when the task for releasing the load on place is completed, and transmitting the related task to the robot to be shut down that satisfies the shutdown conditions. The method for waking up a robot in a shut-down state according to feature 6.

10. The robots to be shut down in the same shutdown request share the same wake-up time information. A method for waking up a robot in a shut-down state, as described in feature 1.

11. A method for waking up a robot from a shut-down state, which is performed by a terminal for robot operation control. The method includes the step of causing a server to perform the wake-up method for a robot in a shut-down state according to any one of claims 1 to 10, by sending a shutdown request to a server for providing robot control services, to which the wake-up request is further augmented with the wake-up time information and the identification information of the robot to be shut down, in response to a shutdown operation that includes configurable wake-up time information and identification information of the robot to be shut down, input by a user, The number of robots to be shut down is one or more. A method for waking up a robot from a shutdown state, characterized by the following:

12. The first response module includes, in response to a shutdown operation input by a user which includes configurable wake-up time information and identification information of the robot to be shut down, a shutdown request to a server providing robot control services, to which the wake-up request is further augmented with the wake-up time information and identification information of the robot to be shut down, thereby causing the server to perform the wake-up method for the robot in the shutdown state described in any one of claims 1 to 10. A terminal characterized by the following features.

13. A second response module for responding to a shutdown request from a terminal for robot operation control, wherein the shutdown request is generated by the terminal in response to a shutdown operation input by the user, which includes configurable wake-up time information and identification information of the robot to be shut down, and the wake-up time information and identification information of the robot to be shut down are added to the shutdown request, the second response module The system includes a startup / shutdown control module for sending the robot to be shut down the associated tasks related to the shutdown task and the 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 associated tasks, enters a shut-down state where it is not connected to the terminal and 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. A scheduling server for providing robot control services characterized by the following features.

14. The terminal described in claim 12 and the scheduling server described in claim 13 are included. A robot management system characterized by the following features.

Images