Robot Call System, Method, Device and Storage Medium Based on LoRa

Abstract

This application relates to a robot call system, method, device, and storage medium based on LoRa. The system includes a LoRa gateway, at least one call terminal that establishes LoRa communication with the LoRa gateway, and a robot cluster. The call terminal encapsulates and generates a robot call request based on a custom serial communication protocol, and sends the robot call request to the LoRa gateway. The LoRa gateway responds to the robot call request, identifies a target robot from the robot cluster, and sends a control instruction to the target robot. The target robot moves to the position of the call terminal in response to the control instruction.

Description

Technical Field

[0001] <Cross - Reference to Related Applications> This application claims priority to a Chinese patent application filed on December 15, 2022, with application number 202211616673.0 and application title "Robot Call System, Method, Device and Storage Medium Based on LoRa", and all of its contents are incorporated herein by reference.

[0002] This application relates to the field of robot technology, and particularly to a robot call system, method, device and storage medium based on LoRa (Long Range).

Background Art

[0003] With the development of robot technology, more and more industries are beginning to use robots. Especially in the food and beverage industry, in order to reduce labor costs and improve efficiency, robots are being used to replace some human labor.

[0004] In the current food and beverage robot service system, a customer calls a food and beverage robot to the customer's location through a call terminal and has the robot provide services. Since communication between the call terminal and the food and beverage robot generally occurs via a WiFi network, data transmission strongly depends on the network. When network instability or disconnection occurs, data reception delays and losses occur, the stability and accuracy of data transmission are poor, and there is a problem of low call success rate.

Summary of the Invention

Problems to be Solved by the Invention

[0005] According to each embodiment of the present application, the present application provides a robot call system, method, computer device, computer - readable storage medium and computer program product based on LoRa.

Means for Solving the Problems

[0006] In a first aspect, the present application provides a robot call system based on LoRa. The call system includes a LoRa gateway, at least one call terminal that establishes LoRa communication with the LoRa gateway, and a robot cluster. The call terminal encapsulates and generates a robot call request based on a custom serial communication protocol, and transmits the robot call request to the LoRa gateway. The LoRa gateway responds to the robot call request, identifies a target robot from the robot cluster, and transmits a control command to the target robot. The target robot moves to the position of the call terminal in response to the control command.

[0007] In a second aspect, the present application further provides a call method applied to a LoRa gateway. The method includes: obtaining a robot call request encapsulated and generated by a call terminal based on a custom serial communication protocol; responding to the robot call request and identifying a target robot from the robot cluster; transmitting a control command to the target robot so that the target robot moves to the position of the call terminal in response to the control command.

[0008] In a third aspect, the present application further provides another call method applied to a call terminal. The method includes: encapsulating and generating a robot call request based on a custom serial communication protocol, transmitting the robot call request to the LoRa gateway so that the LoRa gateway identifies a target robot based on the robot call request, and transmitting a control command to the target robot so that the target robot moves to the position of the call terminal in response to the control command.

[0009] In a fourth aspect, the present application further provides another call control method applied to a robot. The method includes: Obtaining a control command generated by a LoRa gateway based on a robot call request transmitted from a calling terminal and transmitted from the LoRa gateway, Moving to the position of the calling terminal in response to the control command, and the like.

[0010] In a fifth aspect, the present application further provides a computer device. The computer device includes a memory storing a computer program and a processor. When the processor executes the computer program, the method is realized.

[0011] In a sixth aspect, the present application further provides a computer-readable storage medium. A computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the method is realized.

[0012] In a seventh aspect, the present application further provides a computer program product. The computer program product includes a computer program, and when the computer program is executed by a processor, the method is realized.

[0013] Details of one or more embodiments of the present application are described in the following drawings and description. Other features, objects, and advantages of the present application will become apparent from the specification, drawings, and claims.

[0014] To more clearly explain the embodiments of the present invention or the technical solutions according to the prior art, the drawings necessary for describing the embodiments or the prior art are briefly explained. The drawings described below are only embodiments of the present invention, and it is obvious that those skilled in the art can obtain the drawings of other embodiments based on these drawings without creative efforts.

Brief Description of Drawings

[0015]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

DETAILED DESCRIPTION OF THE INVENTION

[0016] To facilitate the understanding of the present application, the present application will be described more comprehensively below with reference to the drawings. The drawings show preferred embodiments of the present application. However, the present application can be implemented in many different forms and is not limited to the embodiments described in this specification. Rather, these embodiments are provided to more thoroughly and comprehensively understand the inventive content of the present application.

[0017] Unless otherwise defined, all scientific and technical terms used in this specification have the same meaning as commonly understood by those skilled in the art. The terms used in the specification of the present application are only used to explain specific embodiments and are not intended to limit the present application. The term "and / or" used in this specification includes any and all combinations of one or more of the listed related elements.

[0018] In some embodiments, as shown in the architecture diagram of FIG. 1, a robot call system based on LoRa is provided. Referring to FIG. 1, the system includes a LoRa gateway 101, at least one call terminal 102 that establishes LoRa communication with the LoRa gateway, and a robot cluster 103. The LoRa gateway 101 performs LoRa communication with the robots in the robot cluster 103 and the call terminal 102 respectively. After receiving a robot call request, the LoRa gateway 101 identifies a target robot 1031 from the robot cluster 103 and controls the target robot 1031 to move to the position of the call terminal 102. It should be noted that the robot cluster 103 includes at least one robot.

[0019] The target robot 1031 is one of the robots in the robot cluster 103 that accesses the LoRa gateway 101, and it moves to the call terminal 102 to provide services. The call terminal 102, the robots in the robot cluster 103, and the LoRa gateway 101 constitute a LoRa local area network. Even when the network is disconnected or becomes unstable, the data transmission between the call terminal 102, the robots in the robot cluster 103, and the LoRa gateway 101 is not inhibited. That is, the robots in the robot cluster 103 can respond to the robot call request in a timely manner, so they can quickly arrive at the position of the call terminal 102, improving the call success rate.

[0020] As an option, compared with 4G, WIFI, etc., the LoRa local area network can achieve a longer propagation distance with the same power consumption, and it is not affected by the appearance of mobile terminals in the environment or the sudden increase of WIFI terminals, for example, in terms of data transmission.

[0021] Exemplarily, the call terminal 102 encapsulates and generates a robot call request based on a custom serial communication protocol, and transmits the robot call request to the LoRa gateway 101. The LoRa gateway 101 responds to the robot call request, identifies the target robot 1031 from the robot cluster 103, and transmits a control command to the target robot 1031. The target robot 1031 responds to the control command and moves to the position of the call terminal 102.

[0022] The custom serial communication protocol is a customized serial communication protocol. As can be understood, the custom serial communication protocol may be a new customized serial communication protocol, or may be obtained by customizing and modifying an existing serial communication protocol. Data frames communicated between the robot, the LoRa gateway, and the call terminal can all be encapsulated by the custom serial communication protocol.

[0023] The above LoRa-based robot call system constructs a LoRa-based robot call system and encapsulates and generates a robot call request based on a custom serial communication protocol, thereby identifying a target robot in response to the robot call request, generating a control command, controlling the target robot to move to the position of the call terminal, improving the accuracy and stability of data transmission, and improving the call success rate.

[0024] In some embodiments, the control command includes a unique identifier of the call terminal. The target robot 1031 identifies the position of the call terminal 102 on the map based on the unique identifier of the call terminal 102, and moves to the position of the call terminal 102 based on the position on the map.

[0025] The position on the map is the position of the call terminal in the operating environment of the robot call system based on the LoRa. For example, when the operating environment is a restaurant, the position on the map is the position of the call terminal in the map of the restaurant.

[0026] Exemplarily, the target robot 1031 identifies the position of the call terminal 102 on the map based on the correspondence between the unique identifier of the call terminal 102 and the position on the map, and moves to the position of the call terminal 102 based on the position on the map.

[0027] In other embodiments, a map of the operating environment is pre-stored in the target robot 1031, and the map includes the position of the call terminal 102 on the map in the operating environment (specifically including X and Y coordinates, and may further include angular information such as θ), and the association information of the unique identifier corresponding to the call terminal 102.

[0028] When the target robot 1031 receives the unique identifier of the call terminal 102, it is possible to identify the position of the corresponding call terminal 102 on the map based on the unique identifier.

[0029] In the above-described embodiments, the position of the call terminal is accurately positioned based on the correspondence between the unique identifier of the call terminal and the position on the map.

[0030] In some embodiments, the control command includes the position of the call terminal 102 on the map, and the target robot 1031 moves to the position of the call terminal 102 based on the position on the map, and the position on the map is identified by the LoRa gateway 101 based on the unique identifier of the call terminal 102 in the robot call request.

[0031] Exemplarily, after receiving a robocall request transmitted from the call terminal 102, the LoRa gateway 101 identifies the position of the call terminal 102 on the map based on the correspondence between the unique identifier of the call terminal 102 in the robocall request and the position on the map, and generates a control command including the position on the map. After receiving the control command including the position on the map, the target robot 1031 moves to the position of the call terminal 102 based on the position on the map.

[0032] In other embodiments, the LoRa gateway 101 may only include the gateway side that realizes communication between the call terminal 102 and the robot cluster 103.

[0033] In other embodiments, the LoRa gateway 101 includes a gateway side and a cloud platform side.

[0034] In other embodiments, the gateway side and the cloud platform side can communicate with each other. The gateway side is configured to communicate with the call terminal 102, and the cloud platform side is configured to communicate with the robot cluster 103.

[0035] Optionally, the communication method between the gateway side and the cloud platform side is not limited.

[0036] In other embodiments, the gateway side realizes communication between the call terminal 102 and the robot cluster 103, and the cloud platform side may cooperate with the gateway to perform related data calculations.

[0037] In other embodiments, the LoRa gateway 101 stores in advance a map of the corresponding operating environment, which includes the position of the call terminal 102 on the map in the operating environment (specifically including X and Y coordinates, and may further include angular information such as θ), and the association information of the unique identifier corresponding to the call terminal 102. After receiving the robot call request sent by the call terminal 102, the LoRa gateway 101 identifies the position of the call terminal 102 on the map based on the correspondence between the unique identifier of the call terminal 102 and the position on the map in the robot call request, and sends the position on the map as part of the control command to the target robot 1031. After receiving the control command including the position on the map, the target robot 1031 moves to the position of the call terminal 102 based on the position on the map.

[0038] In other embodiments, specifically, the gateway side stores in advance a map of the corresponding operating environment and performs calculations.

[0039] In other embodiments, the cloud platform side stores in advance a map of the corresponding operating environment, and after obtaining the unique identifier of the call terminal 102 from the gateway side, calculates the position of the call terminal 102 on the map corresponding to the unique identifier and sends it to the gateway side. Then, the gateway side sends the position on the map as part of the control command to the target robot 1031. After receiving the control command including the position on the map, the target robot 1031 may move to the position of the call terminal 102 based on the position on the map.

[0040] In some embodiments, the custom serial communication protocol has a customized session mode field. After the target robot 1031 arrives at the position of the call terminal 102, it further encapsulates and generates an arrival message based on the custom serial communication protocol, and sends the arrival message to the LoRa gateway 101. The arrival message encapsulates a second session mode identifier representing a second session mode for sending response information that does not include related data.

[0041] The LoRa gateway 102 sends an arrival prompt command to the call terminal 102 in response to the arrival message, and based on the second session mode identifier, returns response information that does not include related data to the target robot 1031.

[0042] The call terminal 102 responds to the arrival prompt command and sends arrival prompt information indicating that the target robot 1031 has already arrived at the call terminal.

[0043] The session mode is a communication mode between the session start side and the session requested side, which is set according to the usage scenario, and the number of types may be one or more.

[0044] As can be understood, the custom serial communication protocol defines a session mode field, and the data frame encapsulated using the custom serial communication protocol includes the session mode field. The data frame transmitted from the session start side includes the session mode field, and the session requested side identifies the session mode field in the data frame to specify the session mode of the current session and returns the corresponding data frame. Information representing the session mode, i.e., the session mode identifier, is written into the session mode field. As can be understood, in different session modes, the session mode fields are different, and there are a first session mode, a second session mode, a third session mode, a fourth session mode, etc. depending on the different session mode fields. The first session mode identifier is for writing information representing the first session mode into the session mode field, and the second session mode identifier is for writing information representing the second session mode into the session mode field.

[0045] The session requested side determines that it is necessary to return a data frame without related data to the session start side by identifying that the received data frame includes a field corresponding to the second session mode. For example, the second session mode field customized in the custom serial communication protocol is 0x02. After the target robot arrives at the position of the call terminal, the target robot sends arrival prompt information to the LoRa gateway. If the session mode field of the data frame received by the LoRa gateway is 0x02, it means that the LoRa gateway needs to return a data frame without data to the target robot, indicating that the LoRa gateway recognizes that the target robot has arrived at the position of the call terminal.

[0046] The arrival message is a message sent to the LoRa gateway when the target robot arrives at the call terminal, and is used to indicate that the target robot has already arrived at the call terminal. The arrival message includes at least one of the call terminal address, arrival command, current position information, etc.

[0047] The arrival prompt command is a command sent from the LoRa gateway to prompt the call terminal that the target robot has already arrived at the call terminal.

[0048] The arrival prompt information is information that prompts the arrival of the target robot, and is generated by the call terminal when the target robot arrives at the position of the call terminal. The arrival prompt information includes at least one of voice prompt and light prompt. For example, the arrival prompt information may notify the arrival of the robot by voice or by light, and this embodiment is not limited thereto.

[0049] In some embodiments, as shown in the flowchart of FIG. 2, a call method is provided, and taking the application of the method to the LoRa gateway 101 in FIG. 1 as an example, the following steps are included.

[0050] In step 201, the call terminal obtains a robot call request generated by encapsulation based on a custom serial communication protocol.

[0051] Exemplarily, when the user needs to call the robot, the call terminal can perform a robot call operation. The call terminal responds to the robot call operation, generates a robot call request by encapsulation based on a custom serial communication protocol, and can send the robot call request to the LoRa gateway.

[0052] In some embodiments, when the call terminal encapsulates and generates a robot call request based on a custom serial communication protocol, it can write a first session mode identifier to the session mode field of the custom serial communication protocol. Therefore, the robot call request includes the first session mode identifier that specifies using the first session mode for communication. The LoRa gateway can extract the first session mode identifier from the obtained robot call request.

[0053] In step 202, in response to the robot call request, identify the target robot from the robot cluster.

[0054] Exemplarily, the LoRa gateway responds to the robot call request and identifies the target robot from the robot cluster based on at least one of the location information and the status information.

[0055] The location information is the real-time location information of the robot. The status information is used to indicate whether the target robot is in an idle state. Optionally, the status information specifically includes an idle state and an occupied state. The occupied state may be a comprehensive state and may include sub-states such as meal delivery, dish collection, and call, but is not limited thereto.

[0056] In other embodiments, the robot can report its location information and status information at a preset frequency.

[0057] In other embodiments, the LoRa gateway can send inquiries to at least one robot at a preset frequency and obtain the location information and status information reported by the robot. Alternatively, when it is necessary to identify the location information and status information of the robot, the LoRa gateway sends a temporary inquiry to at least one robot and obtains the location information and status information reported by the robot.

[0058] In other embodiments, the LoRa gateway may include only the gateway side that realizes the communication between the calling terminal and the robot cluster.

[0059] In other embodiments, the LoRa gateway includes the gateway side and the cloud platform side.

[0060] In other embodiments, the gateway side and the cloud platform side can communicate with each other. The gateway side is configured to communicate with the calling terminal 102, and the cloud platform side is configured to communicate with the robot cluster.

[0061] Optionally, the communication mode between the gateway side and the cloud platform side is not limited.

[0062] In other embodiments, the gateway side is configured to realize the communication between the calling terminal and the robot cluster 103, and the cloud platform side may cooperate with the gateway to perform related data calculations.

[0063] In other embodiments, the LoRa gateway responds to the robot call request, identifies the target robot from the robot cluster based on at least one of the location information and the status information. Specifically, the gateway side identifies the target robot from the robot cluster based on at least one of the location information and the status information. The cloud platform side may also identify the target robot from the robot cluster based on at least one of the location information and the status information, and there is no limitation here.

[0064] In step 203, the target robot is sent a control command to move to the location of the calling terminal in response to the control command.

[0065] Exemplarily, when the LoRa gateway searches for the target robot, it sends a control command to the target robot. The target robot responds to the control command, switches the status information to the occupied state, and moves to the position of the call terminal based on the control command.

[0066] In some embodiments, after the target robot moves to the position of the call terminal in response to the control command by sending a control command to the target robot, the LoRa gateway determines the current session mode as the first session mode based on the session mode field in the received robot call request, and returns a data frame with call response success information that conforms to the first session mode to the call terminal.

[0067] The call response success information is response information indicating call success. After the robot call is successful, the LoRa gateway returns the corresponding data frame with the call response success information to the call terminal so that the call terminal can recognize the success of the robot call.

[0068] It should be noted that there are differences in the content of the call response success information returned for different session modes. In this embodiment, since the robot call request includes the first session mode identifier, the session mode for responding to the robot call request is specified as the first session mode, and after the robot call is successful, the LoRa gateway can generate the consistent call response success information according to the first session mode.

[0069] In the above call method, a robot call system based on LoRa is constructed, and the robot call request is encapsulated and generated based on the custom serial communication protocol, so as to identify the target robot in response to the robot call request, generate a control command, control the target robot to move to the position of the call terminal, improve the accuracy and stability of data transmission, and thus improve the call success rate.

[0070] In some embodiments, the first session mode represented by the first session mode identifier is a session mode in which it is necessary to transmit response information including relevant data. The method further includes, if there is no target robot in the idle state, returning call response failure information to the calling terminal based on the first session mode identifier.

[0071] As can be understood, the session callee determines that it is necessary to return a data frame including relevant data to the session start side by identifying that the received data frame includes a field corresponding to the first session mode. For example, in a custom serial communication protocol, the customized first session mode field is 0x01, and in a session where the robot checks the connection status with the LoRa gateway (there are 4 connection statuses, namely 0x00 unregistered, 0x01 registered, 0x02 logged in, and 0x03 disconnected), if the session mode field in the data frame received by the LoRa gateway is 0x01, the LoRa gateway returns a data frame including relevant data, specifically a data frame with the connection status, to the robot.

[0072] The call response failure information is response information representing a call failure. As can be understood, after the robot call fails, that is, when there is no target robot, the LoRa gateway returns a corresponding data frame with the call success / failure response information to the calling terminal so that the calling terminal can recognize the robot call failure.

[0073] Exemplarily, after the LoRa gateway receives a robot call request, it is found that all the robots accessing the LoRa gateway are in the occupied state, that is, there is no robot in the idle state. At this time, based on the first session mode identifier, the current session mode is specified as the first session mode, and a corresponding data frame with call response failure information is returned to the calling terminal.

[0074] In this embodiment, by using the first session mode identifier to return call response failure information to the calling terminal, the calling terminal is timely informed of the call situation, and the waste of resources caused by the calling terminal making calls for a long time is avoided.

[0075] In some embodiments, the custom serial communication protocol has a customized session mode field, the robot call request includes a first session mode identifier in the session mode field, the custom serial communication protocol further has a customized source address field, and the robot call request further includes the address of the calling terminal in the source address field. After the target robot moves to the position of the calling terminal in response to the control command by sending a control command to the target robot, further, based on the address of the calling terminal, returning call response success information that matches the first session mode identifier to the calling terminal is included.

[0076] The source address field is the source address field in a data frame encapsulated based on a custom serial communication protocol, that is, the address field on the session start side. In order to distinguish whether the session start side is a LoRa gateway, a robot, or a call terminal, it is necessary to make a difference in three addresses. As can be understood, the session requested side can obtain the address of the session start side by identifying the source address field in the data frame and accurately return the corresponding data frame. For example, the address field of the LoRa gateway is 0x00, the address field of the call terminal is 0x01, and the robot address field is 0x02. In a session where the source address field in the data frame received by the LoRa gateway is 0x02, it means that the start side of the session is a robot, and the LoRa gateway returns the corresponding data frame to the robot based on the source address field.

[0077] In this embodiment, by specifying the source address field, accurate transmission of data can be realized, and the call success rate is improved.

[0078] In some embodiments, responding to a robot call request and identifying a target robot from a robot cluster includes obtaining status information reported from the robot cluster and, based on the status information, identifying a robot with an idle status from the robot cluster as the target robot.

[0079] The status information includes, but is not limited to, any one of an idle state, an occupied state, and a forced occupied state.

[0080] The idle state means that the robot is unoccupied, the occupied state means that the robot is being occupied, and the forced occupied state means that the robot has encountered an emergency situation during the movement to the position of the call terminal, such as a sudden shutdown of the robot or immobility due to an obstacle.

[0081] Exemplarily, after receiving a robocall request, the LoRa gateway obtains the status information reported from the accessed robot cluster. If the status information includes any one of an idle state, an occupied state, and a forced occupation state, the LoRa gateway identifies a robot with the status information being the idle state from the robot cluster as the target robot based on the status information.

[0082] In some embodiments, identifying a robot with the status information being the idle state from the robot cluster as the target robot based on the status information means that if there is only one robot in the idle state, the robot is identified as the target robot. However, if multiple robots in the idle state are searched, it includes identifying the target robot based on the location information.

[0083] In the above-described embodiments, by identifying the target robot in the idle state based on the status information, it enables the target robot to move to the location of the call terminal in a timely manner, improving the call success rate.

[0084] In some embodiments, responding to the robocall request and identifying the target robot from the robot cluster includes obtaining the status information and location information reported from the robot cluster, obtaining the location of the call terminal on the map, identifying a robot with the status information being the idle state from the robot cluster based on the status information, and identifying the robot closest to the call terminal among the robots with the status information being the idle state as the target robot based on the location of the call terminal on the map and the location information.

[0085] Exemplarily, the LoRa gateway acquires the status information and location information reported from the robot cluster, and the location of the call terminal on the map. When the number of robots with status information in the idle state identified from the robot cluster based on the status information is at least two, based on the location of the call terminal on the map and the location information, the robot closest to the call terminal among the robots with status information in the idle state is identified as the target robot.

[0086] Note that being closest to the call terminal may mean that the straight-line distance between the robot and the call terminal is the shortest, the actual path between the robot and the call terminal is the shortest, or the map planned path between the robot and the call terminal is the shortest. However, this embodiment does not limit this.

[0087] In the above-described embodiment, when there are at least two robots in the idle state, by identifying the robot closest to the call terminal as the target robot, it is guaranteed that the target robot arrives at the call terminal quickly, and the call time is shortened.

[0088] In some embodiments, after the target robot arrives at the location of the call terminal, an arrival message encapsulated based on the custom serial communication protocol transmitted from the target robot is received. The arrival message encapsulates a second session mode identifier representing a second session mode for transmitting response information not including related data. In response to the arrival message, the call terminal is controlled to output arrival prompt information indicating that the robot has already arrived at the call terminal, and based on the second session mode identifier, the target robot is made to return response information not including related data.

[0089] Exemplarily, after the target robot arrives at the call terminal, an arrival message is encapsulated and generated based on a custom serial communication protocol and sent to the LoRa gateway. After receiving the arrival message, the LoRa gateway sends an arrival prompt command to the call terminal to prompt the arrival of the robot, and the call terminal outputs arrival prompt information in response to the arrival prompt command.

[0090] In this embodiment, the second session identifier specifies that the session mode between the receiving side of the robot call request and the robot is the second session mode, ensuring accurate data transmission and reliable data transfer. Also, after the target robot arrives at the position of the call terminal, the call terminal outputs arrival prompt information to prompt the arrival of the target robot to the user.

[0091] In some embodiments, when receiving a one-way message encapsulated based on a custom serial communication protocol and including a third session mode identifier, no corresponding processing is performed on the received one-way message. In the third session mode represented by the third session mode identifier, no response is required.

[0092] A one-way message is a message sent in one direction, that is, the sending side only sends the message and does not wait for a response.

[0093] As can be understood, a one-way message is specified according to the session scenario. For example, in a session scenario where a robot sends heartbeat data to the LoRa gateway or the robot reports location information and status information to the LoRa gateway, the message sent by the robot is a one-way message and no response from the receiving side is required.

[0094] The third session mode identifier is for writing information representing the third session mode into the session mode field.

[0095] To make it understandable, the session requested party needs to determine that it is necessary to return a data frame without relevant data to the session start side by identifying that the received data frame contains a field corresponding to the third session mode. For example, in a custom serial communication protocol, the customized third session mode field is 0x03. In a session where a robot periodically sends heartbeat data indicating that the robot is online to a LoRa gateway, if the session mode field of the data frame received by the LoRa gateway is 0x03, it means that the LoRa gateway does not need to respond to the received data frame.

[0096] In this embodiment, the third session identifier specifies that the session mode between the LoRa gateway and the robot is the third session mode, ensuring accurate data transmission and guaranteeing the reliability of data transmission.

[0097] In some embodiments, during the movement of the target robot to the position of the call terminal, if the status information of the target robot is identified and the status information indicates that the target robot has been forcibly occupied, a forced occupation response process is performed.

[0098] The forced occupation response process is a process performed when the status information of the target robot is in a forced occupation state.

[0099] Exemplarily, when the target robot shuts down due to power failure during movement to the position of the call terminal, the target robot switches the status information to the forced occupation state immediately before shutdown. After the LoRa gateway identifies that the status information of the target robot is in the forced occupation state, it performs a forced occupation response process. For example, the LoRa gateway sends a call failure message to the call terminal, and the call terminal displays the call failure. The LoRa gateway may re-acquire the status information of all accessed robots, find the robot in the idle state closest to the call terminal as the target robot, and control the target robot to move to the position of the call terminal.

[0100] In this embodiment, by identifying the status information of the target robot during movement to the call terminal, when the status information of the target robot is in the forced occupation state, the call terminal can be timely notified of the call failure, or a new robot can be moved to the call terminal, thereby improving the call success rate.

[0101] In other embodiments, as shown in FIG. 3, another call method is provided, which specifically includes the following steps.

[0102] In S301, the call terminal encapsulates and generates a robot call request including a first session mode identifier in the session mode field based on a custom serial communication protocol having a customized session mode field.

[0103] In S302, the LoRa gateway responds to the robot call request and identifies the robot with the status information in the idle state and closest to the call terminal as the target robot from the robot cluster.

[0104] In S303, the LoRa gateway sends a control command to the target robot.

[0105] In S304, the LoRa gateway returns call response success information that matches the first session mode identifier to the calling terminal.

[0106] In some embodiments, if there is no target robot in the idle state, call response failure information is returned to the calling terminal based on the first session mode identifier.

[0107] In S305, the control command includes the unique identifier of the calling terminal. The target robot identifies the position of the calling terminal on the map based on the unique identifier of the calling terminal and moves to the position of the calling terminal based on the position on the map.

[0108] Furthermore, while the target robot is moving to the position of the calling terminal, the LoRa gateway identifies the status information of the target robot. If the status information indicates that the target robot has been forcibly occupied, a call failure message is sent to the calling terminal. The LoRa gateway may re-acquire the status information of all accessed robots, find the idle robot closest to the calling terminal and identify it as the target robot, and control the target robot to move to the position of the calling terminal.

[0109] In some embodiments, the control command includes the position of the calling terminal on the map. The target robot moves to the position of the calling terminal based on the position on the map. The position on the map is identified by the LoRa gateway using the unique identifier of the calling terminal in the robot call request.

[0110] In S306, the target robot moves to the position of the calling terminal, switches the status information to the occupied state, and after arriving at the position of the calling terminal, encapsulates and generates an arrival message based on the custom serial communication protocol and sends it to the LoRa gateway.

[0111] In S307, the LoRa gateway responds to the arrival message and sends an arrival prompt command to the calling terminal. The arrival message encapsulates a second session mode identifier that represents a second session mode for sending response information without associated data.

[0112] In S308, the LoRa gateway returns response information without associated data to the target robot based on the second session mode identifier.

[0113] In S309, the calling terminal responds to the arrival prompt command and outputs arrival prompt information indicating that the target robot has already arrived at the calling terminal.

[0114] In this embodiment, by the session mode field in the robot call request encapsulated by the custom serial communication protocol, based on the first session mode field, the call response success information matching the first session mode identifier is returned to the call side, thereby improving the accuracy and stability of data transmission. When the target robot's status information is in a forced occupation state during the robot's movement to the position of the calling terminal, timely corresponding processing is performed to improve the call success rate.

[0115] In some embodiments, the custom serial communication protocol is a custom protocol based on SLIP (Serial Line Internet Protocol). That is, custom modifications are made to the SLIP protocol to obtain the custom serial communication protocol of the present application, which is also called the custom SLIP protocol format.

[0116] In some embodiments, referring to FIG. 4, a custom SLIP protocol format is provided. The specific description and explanation of the SLIP protocol format are as follows.

[0117] Two END characters. Each data frame starts with an END character and ends with an END character.

[0118] Frame Number (frame number). In both sessions, the frame number is automatically incremented by 1 each time the frame is successfully transmitted. If the transmission fails three times, the frame number is also automatically incremented by 1 when the next new frame is transmitted. When the value of the frame number accumulates to 255, it starts accumulating from 0 again and cycles like this. If the data frame is a response frame, the frame number is the number of the last received non-response frame, that is, it responds only to the last received non-response frame.

[0119] SRC (session start side address, i.e., source address field) and DEST (session requested side address). That is, in each session, the data frame contains the addresses of both the session start side and the session requested side. Exemplarily, if the address of the LoRa gateway is defined as 0x00, the address of the call terminal is 0x01, and the address of the robot is 0x10, when the SRC of a certain data frame is 0x00 and the DEST is 0x10, it can be determined that the data frame is a data frame transmitted from the LoRa gateway to the robot.

[0120] Type (session mode field). That is, by specifying the Type field, the session mode between the session start side and the session requested side can be specified. Exemplarily, the session start side is A and the session requested side is B and they agree. There is no distinction between master and slave for both of them, and master and slave are only distinguished for a single session. The session start side is the master (A), and the session requested side is the slave (B).

[0121] In some embodiments, there are three types of sessions between A and B. In the first session mode, A starts the session and B responds by including relevant data. In the second session mode, A starts the session and B responds without relevant data. In the third session mode, A starts the session and B does not need to respond. In this embodiment, as an option, the session mode includes, but is not limited to, the first session mode, the second session mode, the third session mode, etc. Exemplarily, when the Type field on the sending side is set to 0x01, the sending side reads and checks the relevant information of the receiving side, and the receiving side needs to respond by including relevant data. When the Type field on the sending side is set to 0x02, the sending side sets, modifies, and notifies the receiving side, and the receiving side needs to respond by including relevant data. When the Type field on the sending side is set to 0x03, the sending side sets, modifies, and notifies the receiving side, and the receiving side does not need to respond by including relevant data. When the Type field on the receiving side is set to 0x10, for the data frames with the received Type fields being 0x01 and 0x02, the receiving side responds by including relevant data in the response frame. When the Type field on the receiving side is set to 0x20, for the data frame with the received Type field being 0x03, the receiving side responds only without including relevant data in the response frame. When the Type field on the receiving side is set to 0x05, for the data frame with the received Type field being 0x03, the receiving side does not respond and is mainly used for real-time data transmission, pass-through, broadcast communication, etc.

[0122] The ID (operation scene), that is, the ID field, specifies the session scene in which the session start side and the session requested side are located. Exemplarily, the ID field can be set according to the usage scene. For example, when the ID is 0x02, it indicates that the session start side and the session requested side are checking the connection state. When the ID is 0x20, it indicates that the session start side and the session requested side are passing data through. When the ID is 0x03, it indicates that the session start side and the session requested side are sending heartbeat data.

[0123] PayloadLength (length of the data payload) is used to represent the size of the user data transmitted in the data frame. Exemplarily, it is used to represent the size of the actually transmitted Data0……DataN. Data0……DataN (0 to N data) indicates the actually transmitted data. Checksum functions to check for data transmission errors. The principle of the check is (FrameNumber + SRC + DEST + Type + ID + PayloadLength + DATA0 +…DATAn) ^ 0xFF. If there are replacement characters in the frame content, it is necessary to calculate the checksum based on the original data.

[0124] In this embodiment, the custom SLIP protocol format encapsulates the data frame in the session, ensuring the accuracy and stability of data transmission.

[0125] In some embodiments, as shown in FIG. 5, another calling method is provided. Taking the application of this method to the calling terminal 102 as an example, it includes the following steps.

[0126] In step 501, encapsulate and generate a robot call request based on the custom serial communication protocol.

[0127] In step 502, send a robot call request to the LoRa gateway so that the LoRa gateway identifies the target robot based on the robot call request, and send a control command to the target robot so that the target robot moves to the position of the call terminal in response to the control command.

[0128] In some embodiments, the method further includes outputting arrival prompt information in response to an arrival prompt command. The arrival prompt command is generated by the LoRa gateway in response to an arrival message encapsulated and generated based on a custom serial communication protocol transmitted from the target robot after the target robot arrives at the position of the call terminal.

[0129] In some embodiments, as shown in FIG. 6, another call method is provided, and the application of the method to the target robot 1031 is taken as an example for description, and the following steps are included.

[0130] In step 601, obtain a control command transmitted from the LoRa gateway, and the control command is generated by the LoRa gateway based on a robot call request transmitted from the call terminal.

[0131] In step 602, move to the position of the call terminal in response to the control command.

[0132] In some embodiments, the control command includes a unique identifier of the call terminal. The method further includes identifying the position of the call terminal on the map based on the unique identifier of the call terminal, and moving to the position of the call terminal based on the position on the map.

[0133] In some embodiments, the control command includes the position of the call terminal on the map. The method further includes moving to the position of the call terminal based on the position on the map, and the position on the map is identified by the LoRa gateway based on the unique identifier of the call terminal in the robot call request.

[0134] In some embodiments, after arriving at the position of the calling terminal, the method further includes encapsulating and generating an arrival message based on a custom serial communication protocol and sending it to a LoRa gateway. The arrival message encapsulates a second session mode identifier that represents a second session mode for sending response information that does not include associated data.

[0135] It should be understood that each step of the flowchart according to each of the above-described embodiments is sequentially shown along the arrows, but these steps are not necessarily sequentially executed in the order indicated by the arrows. Unless explicitly stated in this specification, there is no strict order restriction on the execution of these steps, and these steps may be executed in other orders. Also, at least a part of the steps in the flowchart according to each of the above-described embodiments may include a plurality of steps or a plurality of stages, and these steps or stages are not necessarily completely executed at the same timing, may be executed at different timings, and the order in which these steps or stages are executed is not necessarily sequential, and may be executed in order or alternately with at least a part of other steps or stages.

[0136] Based on the same inventive concept, the embodiments of the present application further provide a calling device for implementing the above-described calling method. Since the embodiments for solving the technical problems provided by the device are similar to the embodiments described in the above method, the specific limitations in one or more embodiments of the calling device provided below may refer to the limitations on the above calling method and are omitted here.

[0137] In some embodiments, as shown in FIG. 7, a calling device is provided, which includes a first acquisition module 701, a determination module 702, and a control module 703.

[0138] The first acquisition module 701 acquires a robot call request generated by encapsulating a call terminal based on a custom serial communication protocol.

[0139] The specific module 702 responds to the robot call request and identifies a target robot from the robot cluster.

[0140] The control module 703 sends a control command to the target robot so that the target robot moves to the position of the call terminal in response to the control command.

[0141] In some embodiments, specifically, the specific module 702 acquires status information reported from the robot cluster, and based on the status information, identifies a robot whose status information is in an idle state from the robot cluster as the target robot.

[0142] In some embodiments, specifically, the specific module 702 acquires status information, position information reported from the robot cluster, and the position of the call terminal on the map, identifies a robot whose status information is in an idle state from the robot cluster based on the status information, and based on the position of the call terminal on the map and the position information, identifies the robot closest to the call terminal among the robots whose status information is in an idle state as the target robot.

[0143] In some embodiments, the custom serial communication protocol has a customized session mode field, the robot call request includes a first session mode identifier in the session mode field, the custom serial communication protocol further has a customized source address field, and the robot call request further includes the address of the call terminal in the source address field. After the target robot moves to the position of the call terminal in response to the control instruction by sending a control instruction to the target robot, specifically, the control module 703 returns call response success information that matches the first session mode identifier to the call terminal based on the address of the call terminal.

[0144] In some embodiments, the first session mode represented by the first session mode identifier is a session mode that needs to send response information including relevant data. If there is no target robot in the idle state, the control module 703 returns call response failure information to the call terminal based on the first session mode identifier.

[0145] In some embodiments, during the process of the target robot moving to the position of the call terminal, the specific module 702 identifies the state information of the target robot, and when the state information indicates that the target robot has been forcibly occupied, performs forced occupation countermeasure processing.

[0146] In some embodiments, the specific module 702 receives an arrival message generated by encapsulating based on a custom serial communication protocol transmitted from the target robot after the target robot arrives at the position of the call terminal. The arrival message encapsulates a second session mode identifier representing a second session mode for transmitting response information that does not include relevant data. In response to the arrival message, an arrival prompt command is generated, and the arrival prompt command controls the call terminal to output arrival prompt information, and based on the second session mode identifier, the target robot is caused to return response information that does not include relevant data. The arrival prompt information is for prompting that the target robot has already arrived at the call terminal.

[0147] In some embodiments, as shown in FIG. 8, another call device is provided, which includes a first generation module 801 and a transmission module 802.

[0148] The first generation module 801 generates by encapsulating a robot call request based on a custom serial communication protocol.

[0149] The transmission module 802 transmits the robot call request to the LoRa gateway so that the LoRa gateway identifies the target robot based on the robot call request, and transmits a control command to the target robot so that the target robot moves to the position of the call terminal in response to the control command.

[0150] In some embodiments, the device further includes a prompt module that outputs arrival prompt information in response to the arrival prompt command. The arrival prompt command is generated by the LoRa gateway in response to an arrival message generated by encapsulating based on a custom serial communication protocol transmitted from the target robot after the target robot arrives at the position of the call terminal.

[0151] In some embodiments, as shown in FIG. 9, another calling device is provided, which includes a second acquisition module 901 and a response module 902.

[0152] The second acquisition module 901 acquires a control command transmitted from the LoRa gateway, and the control command is generated based on the robot call request transmitted from the call terminal by the LoRa gateway.

[0153] The response module 902 moves to the position of the call terminal in response to the control command.

[0154] In some embodiments, the control command includes the position of the call terminal on the map, and specifically, the response module 902 moves to the position of the call terminal based on the position on the map. The position on the map is identified based on the unique identifier of the call terminal in the robot call request by the LoRa gateway.

[0155] In some embodiments, the control command includes the unique identifier of the call terminal. Specifically, the response module 902 identifies the position of the call terminal on the map based on the unique identifier of the call terminal, and moves to the position of the call terminal based on the position on the map.

[0156] In some embodiments, the device further includes a second generation module, which, after arriving at the position of the call terminal, encapsulates and generates an arrival message based on a custom serial communication protocol and transmits it to the LoRa gateway. The arrival message encapsulates a second session mode identifier representing a second session mode for transmitting response information without including associated data.

[0157] All or part of each module in the above-described calling device can be realized by software, hardware, and combinations thereof. Each of the above-described modules may be incorporated into the processor of a computer device in the form of hardware, may be independent of the processor of the computer device, or may be stored in the memory of the computer device in the form of software so as to be called by the processor to execute operations corresponding to each of the above-described modules.

[0158] In some embodiments, a computer device is provided, and the computer device may be a gateway, a robot, or a call terminal, and its internal structure diagram is shown in FIG. 10. The computer device includes a processor, a memory, and a communication interface connected via a system bus. The processor of the computer device provides computing and control functions. The memory of the computer device includes a non-volatile storage medium and an internal memory. The operating system (OS) and computer program are stored in the non-volatile storage medium. The internal memory provides an operating environment for the operating system and computer program in the non-volatile storage medium. The communication interface of the computer device communicates with an external terminal via a network connection. When the computer program is executed by the processor, the above-described calling method is realized.

[0159] The configuration shown in FIG. 10 is only a configuration block diagram of a part related to the technical means of the present application, and does not limit the computer device to which the technical means of the present application is applied. It is understandable to those skilled in the art that a specific computer device may include more or fewer components than the illustrated components, may combine specific components, or may have a different arrangement of components.

[0160] In some embodiments, a computer device comprising a memory and a processor is provided, and the memory stores a computer program which, when executed by the processor, implements the steps in the embodiments of each of the above methods.

[0161] In some embodiments, a computer-readable storage medium storing a computer program is provided, and when the computer program is executed by a processor, the steps in the embodiments of each of the above methods are implemented.

[0162] In some embodiments, a computer program product storing a computer program is provided, and when the computer program is executed by a processor, the steps in the embodiments of each of the above methods are performed.

[0163] A person skilled in the art can understand and implement all or part of the processes in the above-described embodiments, and can complete them by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium, and when the computer program is executed, it can include the processes of the above-described embodiments of each method. Also, any reference to the memory, database, or other media used in each embodiment provided in the present application can include at least one of non-volatile and volatile memories. Non-volatile memory can include read-only memory (ROM), tapes, floppy disks, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM (registered trademark)), phase change memory (PCM), graphene memory, and the like. Volatile memory can include random access memory (RAM) or external cache memory, and the like. For illustration purposes and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), and the like. The database according to each embodiment provided in the present application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, and the like, and are not limited thereto. The processor according to each embodiment provided in the present application can be a general-purpose processor, a central processor, a graphics processor, a digital signal processor, programmable logic, data processing logic based on quantum computing, and the like, and is not limited thereto.

[0164] Each of the technical features of the above-described embodiments can be arbitrarily combined. For the sake of brevity of description, not all combinations of the technical features in the above-described embodiments are described. However, as long as these combinations of technical features do not conflict, they should be considered to be within the scope described in this specification.

[0165] The above-described embodiments merely show some embodiments of the present application. Although the description is specific and detailed, it should not be construed as limiting the protection scope of the invention. It should be noted that those skilled in the art can make some modifications and improvements without departing from the spirit of the present application, and all of these also belong to the protection scope of the present invention. Therefore, the protection scope of the present invention should conform to the scope of the claims.

Claims

1. A robot call system based on LoRa, wherein the robot call system comprises a LoRa gateway, at least one call terminal that establishes LoRa communication with the LoRa gateway, and a robot cluster, the call terminal encapsulates and generates a robot call request based on a custom serial communication protocol, and transmits the robot call request to the LoRa gateway, the LoRa gateway responds to the robot call request, identifies a target robot from the robot cluster, and transmits a control command to the target robot, the target robot moves to the position of the call terminal in response to the control command. A robot call system based on LoRa.

2. The control command includes a unique identifier of the call terminal, and the target robot further, identifies the position of the call terminal on the map based on the unique identifier of the call terminal, and moves to the position of the call terminal based on the position on the map. The LoRa-based robot call system according to claim 1, characterized in that.

3. The control command includes the position of the call terminal on the map, and the target robot further, moves to the position of the call terminal based on the position on the map, wherein the position on the map is identified by the LoRa gateway based on the unique identifier of the call terminal in the robot call request. The LoRa-based robot call system according to claim 1, characterized in that.

4. The custom serial communication protocol includes a customized session mode field, and after the target robot arrives at the position of the call terminal, the target robot further encapsulates and generates an arrival message based on the custom serial communication protocol, and transmits an arrival message in which a second session mode identifier representing a second session mode for transmitting response information not including related data is encapsulated to the LoRa gateway, the LoRa gateway further responds to the arrival message, transmits an arrival prompt command to the call terminal, and returns response information not including related data to the target robot based on the second session mode identifier. The calling terminal further outputs arrival prompt information for responding to the arrival prompt command and prompting that the target robot has already arrived at the calling terminal. The LoRa-based robot call system according to claim 1 is characterized by this.

5. The LoRa gateway includes a gateway side and a cloud platform side. The LoRa-based robot call system according to claim 1 is characterized by this.

6. The gateway side and the cloud platform side can communicate with each other. The gateway side communicates with the calling terminal, and the cloud platform side communicates with the robot cluster. The LoRa-based robot call system according to claim 5 is characterized by this.

7. The gateway side realizes communication between the calling terminal and the robot cluster, and the cloud platform side cooperates with the gateway to perform calculation of related data. The LoRa-based robot call system according to claim 5 is characterized by this.

8. A call method applied to a LoRa gateway, The method includes: acquiring a robot call request generated by encapsulating by a calling terminal based on a custom serial communication protocol; responding to the robot call request and identifying a target robot from a robot cluster; sending a control command to the target robot so that the target robot moves to the position of the calling terminal in response to the control command. The call method includes these steps.

9. Responding to the robot call request and identifying a target robot from a robot cluster includes: acquiring status information reported from the robot cluster; identifying a robot with idle status information from the robot cluster as the target robot based on the status information. The call method according to claim 8 is characterized by this.

10. Responding to the robot call request and identifying a target robot from a robot cluster includes: acquiring status information and position information reported from the robot cluster; acquiring the position of the calling terminal on the map; identifying a robot with idle status information from the robot cluster based on the status information. Based on the position of the call terminal on the map and the position information, identifying the robot closest to the call terminal among the robots in the idle state as the target robot, and, including this, the call method according to claim 8, characterized in that.

11. The custom serial communication protocol includes a customized session mode field, the robot call request includes a first session mode identifier in the session mode field, the custom serial communication protocol further includes a customized source address field, and the robot call request further includes the address of the call terminal in the source address field. After sending a control command to the target robot so that the target robot moves to the position of the call terminal in response to the control command, further, Based on the address of the call terminal, including returning call response success information matching the first session mode identifier to the call terminal, the call method according to claim 8, characterized in that.

12. The first session mode represented by the first session mode identifier is a session mode that needs to send response information including related data. The method further includes, If there is no target robot in the idle state, including returning call response failure information to the call terminal based on the first session mode identifier, the call method according to claim 11, characterized in that.

13. The method further includes, During the process of the target robot moving to the position of the call terminal, identifying the state information of the target robot, and, If the state information indicates that the target robot has been forcibly occupied, including performing forced occupation countermeasure processing, the method according to any one of claims 8 to 12, characterized in that.

14. The method further includes, After the target robot arrives at the position of the call terminal, receiving an arrival message in which a second session mode identifier representing a second session mode for sending response information not including related data, generated by encapsulating based on the custom serial communication protocol sent from the target robot, is encapsulated. In response to the arrival message, generate an arrival prompt command for prompting that the target robot has already arrived at the call terminal so as to control the call terminal to output arrival prompt information by the arrival prompt command, and based on the second session mode identifier, return response information that does not include related data to the target robot, which is included in the call method according to claim 8.

15. A call method applied to a call terminal, generating and encapsulating a robot call request based on a custom serial communication protocol, and transmitting the robot call request to a LoRa gateway so that the LoRa gateway identifies a target robot based on the robot call request, and transmitting a control command to the target robot so that the target robot moves to the position of the call terminal in response to the control command, which is included in the call method.

16. A call method applied to a robot, obtaining a control command generated based on a robot call request transmitted from a call terminal by the LoRa gateway from the LoRa gateway, and moving to the position of the call terminal in response to the control command, which is included in the call method.

17. The control command includes a unique identifier of the call terminal, Moving to the position of the call terminal in response to the control command is identifying the position of the call terminal on a map based on the unique identifier of the call terminal, and moving to the position of the call terminal based on the position on the map, which is included, or The control command includes the position of the call terminal on the map, Moving to the position of the call terminal in response to the control command is including moving to the position of the call terminal based on the position on the map, wherein the position on the map is identified by the LoRa gateway using the unique identifier of the call terminal in the robot call request, which is the call method according to claim 16.

18. A computer device, including a memory and a processor, wherein a computer program is stored in the memory, and when the computer program is executed by the processor, the method according to any one of claims 8 to 17 is implemented, which is a computer device.

19. A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the method according to any one of claims 8 to 17 is performed. A computer-readable storage medium.

20. A computer program product, wherein the computer program product includes a computer program, and when the computer program is executed by a processor, the method according to any one of claims 8 to 17 is performed. A computer program product.

Images