CN112025713A - Method and system for synchronizing waybill states of robot and cloud - Google Patents
Method and system for synchronizing waybill states of robot and cloud Download PDFInfo
- Publication number
- CN112025713A CN112025713A CN202010939087.4A CN202010939087A CN112025713A CN 112025713 A CN112025713 A CN 112025713A CN 202010939087 A CN202010939087 A CN 202010939087A CN 112025713 A CN112025713 A CN 112025713A
- Authority
- CN
- China
- Prior art keywords
- event
- robot
- distribution
- task
- cloud server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
- B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
- B25J11/00—Manipulators not otherwise provided for
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
- B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
- B25J9/00—Programme-controlled manipulators
- B25J9/16—Programme controls
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
- B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
- B25J9/00—Programme-controlled manipulators
- B25J9/16—Programme controls
- B25J9/1679—Programme controls characterised by the tasks executed
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B25—HAND TOOLS; PORTABLE POWER-DRIVEN TOOLS; MANIPULATORS
- B25J—MANIPULATORS; CHAMBERS PROVIDED WITH MANIPULATION DEVICES
- B25J9/00—Programme-controlled manipulators
- B25J9/16—Programme controls
- B25J9/1679—Programme controls characterised by the tasks executed
- B25J9/1689—Teleoperation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q10/00—Administration; Management
- G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
- G06Q10/083—Shipping
Landscapes
- Engineering & Computer Science (AREA)
- Mechanical Engineering (AREA)
- Robotics (AREA)
- Business, Economics & Management (AREA)
- Economics (AREA)
- Quality & Reliability (AREA)
- Marketing (AREA)
- Operations Research (AREA)
- Human Resources & Organizations (AREA)
- Strategic Management (AREA)
- Tourism & Hospitality (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Theoretical Computer Science (AREA)
- Entrepreneurship & Innovation (AREA)
- Development Economics (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The invention discloses a method and a system for synchronizing waybill states of a robot and a cloud end, which are convenient for the robot to stably pull delivery tasks from the cloud end in time through a CHECKSUM abstract alignment mode, avoid the situation of task loss, and simultaneously, the robot synchronizes decision results and the execution states of the delivery tasks to the cloud end in an event form, so that a user can know the state of the robot in time conveniently, the working efficiency and the working accuracy of the robot are improved, and the robot can provide more abundant and more accurate service for clients.
Description
[ technical field ] A method for producing a semiconductor device
The invention relates to the field of robots, in particular to a method and a system for synchronizing waybill states of a robot and a cloud.
[ background of the invention ]
With the rapid development of the robot industry, various service robots emerge endlessly, and the robots are widely applied in life and work. Robots that are now serviced within a building typically have flat-floor delivery capabilities within the building and have multiple bays for items stored therein so that the robot can deliver items at multiple different destinations in a single pass. Meanwhile, in modern buildings, especially business office buildings and shopping mall buildings, the general floors are very high, and for the delivery task of crossing floors in the buildings, the robot needs to take the elevator to move between different floors. The robot acquires the tasks to be executed from the cloud server at any time and synchronizes the execution condition of the current task when the delivery task is completed, so that a user can remotely operate the robot in a mobile phone mode and the like and know the execution state of the current task of the robot at any time. Meanwhile, the cloud server is also an essential link for completing robot task allocation and scheduling for the perception of the robot task execution state. However, under complex building conditions, especially when the network signal is unstable, the robot and the cloud are difficult to align data, so that technical problems of unstable, untimely and inaccurate order synchronization easily occur.
[ summary of the invention ]
The invention provides a method and a system for synchronizing waybill states of a robot and a cloud, which solve the technical problems.
The technical scheme for solving the technical problems is as follows: a method for synchronizing waybill states of a robot and a cloud comprises the following steps:
step 2, the robot initiates a ping/pong request to the cloud server at a preset frequency to acquire real-time checksum data allocated to the robot, and when the real-time checksum data is changed with the checksum data acquired last time, a task list is acquired from the cloud server, wherein the task list comprises a delivery task corresponding to the real-time checksum data and a current allocation state of the delivery task;
step 3, the cloud server interacts with the robot according to a preset flow, receives a decision result fed back by the robot in an event form, and continuously modifies the current distribution state of the distribution tasks in the task list according to the decision result until the current distribution state of the distribution tasks is changed into the process;
and 4, when the robot executes the distribution task, continuously sending the current execution state of the distribution task to the cloud server in an event form.
In a preferred embodiment, the robot is divided into a candidate robot and a target robot, the cloud server interacts with the robot according to a preset flow, receives a decision result fed back by the robot in an event form, and continuously modifies a current distribution state of a distribution task in a task list according to the decision result, specifically including the following steps:
s301, after receiving the task list, the alternative robot generates a corresponding first event according to a first decision result and sends the first event to the cloud server, wherein the first event comprises a pre-distribution waybill refusing event or a pre-distribution waybill accepting event;
s302, the cloud server receives first events sent by all the alternative robots, selects a target robot from the alternative robots which are pre-distributed, modifies the current distribution state of the distribution tasks in the task list into a distributed state, and generates corresponding real-time checksum data;
s303, the target robot acquires real-time checksum data distributed to the target robot through a ping/pong request, acquires the modified task list from the cloud server when the real-time checksum data is changed with the checksum data acquired last time, generates a corresponding second event according to a second decision result, and sends the second event to the cloud server, wherein the second event comprises an event of refusing to distribute waybills or an event of accepting to distribute waybills;
s304, the cloud server receives a second event sent by the target robot, if the second event is an event of accepting and distributing waybill, the current distribution state of the distribution task is modified to be in progress, if the second event is an event of refusing to distribute waybill, the operation returns to S302 to reselect the target robot, and the steps S303 and S304 are executed until one target robot accepts the distribution task or the overtime of the distribution task is reached.
In a preferred embodiment, the method further comprises a waybill canceling step, wherein the waybill canceling step specifically comprises the following steps:
when a user cancels the executing delivery task from a cloud server, the cloud server modifies the current execution state of the delivery task in a task list into a user application cancellation state and generates corresponding real-time checksum data;
the target robot acquires real-time checksum data distributed to the target robot through a ping/pong request, acquires a modified task list from the cloud server when the real-time checksum data is changed with the checksum data acquired last time, generates a corresponding third event according to a third decision result, and sends the third event to the cloud server, wherein the third event comprises an event of refusing to cancel the waybill or an event of accepting to cancel the waybill;
and the cloud server receives a third event sent by the target robot, and modifies the current execution state of the distribution task according to the third event, so that a user can conveniently inquire a cancellation result through the cloud server.
In a preferred embodiment, the robot feeds back each decision result and the execution state of the delivery task to the cloud server in the form of an event, and specifically includes the following steps:
s401, generating an increasing and unique new event id for the new event of the distribution task according to time, the identity certification of the robot, the identity certification of the station and the current event id recorded in the database;
s402, uploading a new event comprising the new event id to the cloud server, and when uploading fails due to a network transmission problem, recording the new event as an unsent successful event;
and S403, retransmitting the unsent successful events according to the sequence of the new event ids from small to large according to the cycle of the ping/pong request and the network signal strength.
In a preferred embodiment, after receiving the new event, the cloud server checks whether the new event id is greater than the entered maximum event id and whether the state of the delivery task included in the new event is returned, and if the check is passed, modifies the state of the delivery task in the task list according to the information of the new event, otherwise, only the new event is entered, but the state of the delivery task in the task list is not modified.
A second aspect of the present embodiment provides a waybill status synchronization system between a robot and a cloud, including the robot and a cloud server, where the cloud server includes a waybill allocation module, a first interaction module, and a status receiving module,
the waybill distribution module is used for inputting a distribution task created by a user, generating a corresponding waybill, and calculating real-time checksum data of the distribution task according to waybill information and the current distribution state of the distribution task;
the first interaction module is used for interacting with the robot according to a preset flow, receiving a decision result fed back by the robot in an event form, and continuously modifying the current distribution state of the distribution tasks in the task list according to the decision result until the current distribution state of the distribution tasks is consistent with any target robot and is changed into the process;
the state receiving module is used for receiving the current execution state of the distribution task sent by the robot in an event form;
the robot comprises a request module, a second interaction module and a state sending module,
the request module is used for the robot to send ping/pong requests to the cloud server at a preset frequency, obtain real-time checksum data allocated to the robot, and obtain a task list from the cloud server when the real-time checksum data is changed with the checksum data obtained last time, wherein the task list comprises a delivery task corresponding to the real-time checksum data and a current allocation state of the delivery task;
the second interaction module is used for feeding back a decision result for the distribution task to the cloud server in an event form;
the state sending module is used for continuously sending the current execution state of the distribution task to the cloud server in an event form when the distribution task is executed.
In a preferred embodiment, the second interactive module specifically comprises a first decision unit and a second decision unit, the first decision unit is arranged at the candidate robot, the second decision unit is arranged at the target robot,
the first decision unit is used for generating a corresponding first event according to a first decision result and sending the corresponding first event to the cloud server after receiving the task list, wherein the first event comprises a pre-distribution waybill refusing event or a pre-distribution waybill accepting event;
the second decision unit is used for acquiring real-time checksum data allocated to the second decision unit through a ping/pong request, acquiring the modified task list from the cloud server when the real-time checksum data is changed with the checksum data acquired last time, generating a corresponding second event according to a second decision result, and sending the second event to the cloud server, wherein the second event comprises an event of refusing to allocate the waybill or an event of accepting to allocate the waybill;
the first interactive module specifically includes a first allocation unit and a second allocation unit,
the first distribution unit is used for receiving first events sent by all the alternative robots, selecting a target robot from the alternative robots which are subjected to pre-distribution, modifying the current distribution state of the distribution tasks in the task list into a distributed state, and generating corresponding real-time checksum data;
and the second distribution unit is used for receiving a second event sent by the target robot, modifying the current distribution state of the distribution task to be in progress if the second event is an order accepting and distributing event, and driving the first distribution unit to reselect the target robot if the second event is an order refusing and distributing event until one target robot receives the distribution task or the overtime time of the distribution task is reached.
In a preferred embodiment, the cloud server further comprises a waybill cancellation module, the target robot further comprises a third decision unit,
the waybill canceling module is used for modifying the current execution state of the distribution tasks in the task list into user application canceling when a user cancels the distribution tasks being executed to the cloud server, and generating corresponding real-time checksum data; the system comprises a target robot, a cloud server and a server, wherein the target robot is used for receiving a first event sent by the target robot and sending a distribution task to the cloud server;
the third decision unit is configured to acquire real-time checksum data allocated to the third decision unit through a ping/pong request, acquire a modified task list from the cloud server when the real-time checksum data changes from the checksum data acquired last time, generate a corresponding third event according to a third decision result, and send the third event to the cloud server, where the third event includes a rejection of a waybill cancellation event or an acceptance of a waybill cancellation event.
In a preferred embodiment, the status sending module specifically includes:
the generating unit is used for generating an increasing and unique new event id for the new event of the distribution task according to the time, the identity certification of the robot, the identity certification of the station and the current event id recorded in the database;
the uploading unit is used for uploading a new event comprising the new event id to the cloud server, and when uploading fails due to a network transmission problem, the new event is recorded as an unsent successful event;
and the retransmission unit retransmits the unsent successful events according to the cycle of the ping/pong request and the network signal strength in the order of the new event ids from small to large.
In a preferred embodiment, the state receiving module is specifically configured to check whether a new event id is greater than a maximum event id entered and whether a state of a delivery task included in the new event is backed off after receiving the new event, modify the state of the delivery task in a task list according to information of the new event if the check is passed, otherwise, only enter the new event, but not modify the state of the delivery task in the task list.
The invention provides a method and a system for synchronizing waybill states of a robot and a cloud end, which are convenient for the robot to stably pull delivery tasks from the cloud end in time in a CHECKSUM alignment mode, avoid the situation of task loss, and simultaneously synchronize decision results and the execution states of the delivery tasks from the robot to the cloud end in an event form, so that a user can know the state of the robot in time conveniently, the working efficiency and the working accuracy of the robot are improved, and the robot can provide more abundant and more accurate service for clients.
In order to make the aforementioned and other objects, features and advantages of the present invention comprehensible, preferred embodiments accompanied with figures are described in detail below.
[ description of the drawings ]
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the embodiments will be briefly described below, it should be understood that the following drawings only illustrate some embodiments of the present invention and therefore should not be considered as limiting the scope, and for those skilled in the art, other related drawings can be obtained according to the drawings without inventive efforts.
Fig. 1 is a schematic flowchart of a waybill status synchronization method of a robot and a cloud in embodiment 1;
fig. 2 is a schematic structural diagram of the waybill state synchronization system of the robot and the cloud in embodiment 2.
[ detailed description ] embodiments
In order to make the objects, technical solutions and advantageous effects of the present invention more clearly apparent, the present invention is further described in detail below with reference to the accompanying drawings and the detailed description. It should be understood that the detailed description and specific examples, while indicating the preferred embodiment of the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention.
Fig. 1 is a schematic flow chart of a waybill state synchronization method for a robot and a cloud provided in embodiment 1 of the present invention, as shown in fig. 1, including the following steps:
In a preferred embodiment, there are two different flows depending on whether the user specifies the robot. When the user specifies the robot, the current distribution state of the distribution task is the distributed state, and the cloud server calculates the real-time checksum data of the distribution task according to information such as the distribution task id, the task creation time and the distributed state. Here, checksum refers to an algorithm that calculates an abstract of a piece of data (e.g., the total information of the delivery task) and uses it for comparison.
When the user does not specify the robot, the cloud server comprehensively decides and pre-allocates at least one alternative robot to execute the distribution task according to the health state, task execution condition, position and other information of the robot in the site. At this time, the cloud server calculates real-time checksum data of the delivery tasks according to information such as the id of the delivery tasks, the task creation time, the pre-distribution state and the like.
And then executing step 2, the robot sends a ping/pong request to the cloud server at a preset frequency to acquire real-time checksum data allocated to the robot, and when the real-time checksum data is changed with the checksum data acquired last time, the robot needs to synchronize new waybill information from the cloud end, namely, needs to acquire a task list from the cloud server, wherein the task list comprises a distribution task corresponding to the real-time checksum data and the current allocation state of the distribution task. Here, the ping/pong request refers to a mechanism for the robot to synchronize the latest state with the cloud server at a fixed time interval, for example, every two seconds, and obtain a cloud response.
And then executing step 3, the cloud server interacts with the robot according to a preset flow, receives a decision result fed back by the robot in an event form, and continuously modifies the current distribution state of the distribution tasks in the task list according to the decision result until the current distribution state of the distribution tasks is changed into the process.
When the user designates the robot, the robot determines whether to accept the delivery task according to the current situation after receiving the task list comprising the delivery task, generates a decision event and uploads the decision event to the cloud.
When the user does not designate a robot, at least one alternative robot receives a task list comprising the delivery tasks, the current distribution state of the delivery tasks is a pre-distribution state, and the interaction process of the alternative robot and the cloud server is as follows:
s301, after receiving the task list, the alternative robot generates a corresponding first event according to a first decision result and sends the first event to the cloud server, wherein the first event comprises a pre-distribution waybill refusing event or a pre-distribution waybill accepting event;
s302, the cloud server receives first events sent by all the alternative robots, selects a target robot from the alternative robots which are pre-distributed, modifies the current distribution state of the distribution tasks in the task list into a distributed state, and generates corresponding real-time checksum data;
s303, the target robot acquires real-time checksum data distributed to the target robot through a ping/pong request, acquires the modified task list from the cloud server when the real-time checksum data is changed from the last acquired checksum data (namely the state of a distribution task is changed from pre-distribution to distributed), generates a corresponding second event according to a second decision result and sends the second event to the cloud server, wherein the second event comprises an event of refusing to distribute the waybill or an event of accepting to distribute the waybill;
s304, the cloud server receives a second event sent by the target robot, if the second event is an event of accepting and distributing waybill, the current state of the distribution task is modified to be in progress, if the second event is an event of refusing to distribute waybill, the operation returns to S302 to reselect the target robot, and the steps S303 and S304 are executed until one target robot accepts the distribution task or the overtime of the distribution task is reached.
And step 4, when the robot executes the distribution task, the current execution state of the distribution task is continuously sent to the cloud server in an event form, and the event comprises all waybill information and the state corresponding to the distribution task when the event occurs. Specifically, the robot feeds back a decision result and various states to the cloud server in an event form, and the method specifically comprises the following steps:
s401, generating an incremental and unique new event id for the new event of the distribution task according to the current time, the robot identity identification uid, the site identity identification uid and the current event id recorded in the database. The new event comprises a state change event of the delivery task or a decision event of the delivery task, wherein the state of the delivery task comprises an waybill creating state, a waybill pre-distribution state, a waybill distributed state, a waybill received state, a waybill rejected state, a waybill in-process state, a waybill completed state and a waybill cancelled state.
S402, uploading a new event comprising the new event id to the cloud server, and when uploading fails due to a network transmission problem, recording the new event as an unsent successful event.
And S403, retransmitting the unsent successful events according to the sequence of the new event ids from small to large according to the cycle of the ping/pong request and the network signal strength.
And after receiving the new event, the cloud server verifies whether the new event id is larger than the recorded maximum event id and whether the state of the distribution task contained in the new event is returned, so that uncontrollable accidents such as event loss and the like are eliminated. The cloud server generates a corresponding waybill state jump relation table according to specific service logic/flow, and an event conforming to the jump relation table is considered to pass state rollback verification. And if the event id backspacing check and the state backspacing check both pass, modifying the state of the delivery task in the task list according to the information of the new event, and if the event id backspacing check and the state backspacing check do not pass, indicating that the event is a historical event and is not the latest task execution situation of the robot, so that the cloud server only enters the new event, but does not modify the state of the delivery task in the task list.
In a preferred embodiment, the waybill state synchronization method further includes a waybill canceling step, and the waybill canceling step specifically includes:
s601, when a user cancels the executing delivery task to a cloud server, the cloud server modifies the current execution state of the delivery task in a task list into a user application cancellation state and generates corresponding real-time checksum data;
s602, the target robot acquires real-time checksum data distributed to the target robot through a ping/pong request, acquires a modified task list from the cloud server when the real-time checksum data is changed with the checksum data acquired last time, generates a corresponding third event according to a third decision result, and sends the third event to the cloud server, wherein the third event comprises an event of refusing to cancel the waybill or an event of accepting to cancel the waybill;
s603, the cloud server receives a third event sent by the target robot, and modifies the current execution state of the distribution task according to the third event, so that a user can conveniently inquire a cancellation result through the cloud server.
The method for synchronizing the waybill states of the robot and the cloud end is provided, the robot can conveniently and stably pull the delivery tasks from the cloud end in time through the CHECKSUM alignment mode, the task loss situation is avoided, meanwhile, the robot synchronizes decision results and the execution state of the delivery tasks to the cloud end in an event mode, a user can conveniently know the state of the robot in time, the working efficiency and the working accuracy of the robot are improved, and the robot can provide services with richer and more accurate contents for clients.
It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present invention.
Fig. 2 is a schematic structural diagram of an waybill status synchronization system of a robot and a cloud according to embodiment 2, including the robot 100 and a cloud server 200, where the cloud server 200 includes a waybill allocation module 201, a first interaction module 202, and a status receiving module 203,
the waybill allocation module 201 is configured to enter a delivery task created by a user, generate a corresponding waybill, and calculate real-time checksum data of the delivery task according to waybill information and a current allocation state of the delivery task;
the first interaction module 202 is configured to interact with the robot according to a preset flow, receive a decision result fed back by the robot in an event form, and continuously modify the current distribution state of the distribution tasks in the task list according to the decision result until the current distribution state of the distribution tasks is consistent with any target robot and the current distribution state of the distribution tasks is changed to be in progress;
the state receiving module 203 is configured to receive a current execution state of the delivery task sent by the robot in the form of an event;
the robot 100 comprises a request module 101, a second interaction module 102 and a status transmission module 103,
the request module 101 is configured to initiate a ping/pong request to the cloud server by a robot at a preset frequency, acquire real-time checksum data allocated to the robot, and acquire a task list from the cloud server when the real-time checksum data changes from the checksum data acquired last time, where the task list includes a delivery task corresponding to the real-time checksum data and a current allocation state of the delivery task;
the second interaction module 102 is configured to feed back a decision result for the delivery task to a cloud server in the form of an event;
the state sending module 103 is configured to continuously send the current execution state of the delivery task to the cloud server in an event form when the delivery task is executed.
In a preferred embodiment, the second interaction module 102 specifically includes a first decision unit 1021 and a second decision unit 1022, where the first decision unit 1021 is disposed at the candidate robot, the second decision unit 1022 is disposed at the target robot,
the first decision unit 1021 is configured to generate a corresponding first event according to a first decision result and send the corresponding first event to the cloud server after receiving the task list, where the first event includes a rejection of a pre-allocation waybill event or an acceptance of the pre-allocation waybill event;
the second decision unit 1022 is configured to acquire real-time checksum data allocated to the second decision unit by using a ping/pong request, acquire the modified task list from the cloud server when the real-time checksum data changes from the checksum data acquired last time, generate a corresponding second event according to a second decision result, and send the second event to the cloud server, where the second event includes an event of rejecting allocation of a waybill or an event of accepting allocation of a waybill;
the first interactive module 202 comprises in particular a first distribution unit 2021 and a second distribution unit 2022,
the first allocation unit 2021 is configured to receive first events sent by all the candidate robots, select a target robot from the candidate robots that have received pre-allocation, modify a current allocation state of the distribution tasks in the task list to an allocated state, and generate corresponding real-time checksum data;
the second allocating unit 2022 is configured to receive a second event sent by the target robot, modify the current allocation status of the distribution task to be in progress if the second event is an event of accepting to allocate waybills, and drive the first allocating unit to reselect the target robot if the second event is an event of rejecting to allocate waybills until there is a timeout when one target robot accepts the distribution task or reaches the distribution task.
In a preferred embodiment, the cloud server further comprises a waybill cancellation module 204, the target robot further comprises a third decision unit 1023,
the waybill canceling module 204 is configured to modify a current execution state of the delivery task in the task list to be cancelled by a user application when the user cancels the delivery task being executed from the cloud server, and generate corresponding real-time checksum data; the system comprises a target robot, a cloud server and a server, wherein the target robot is used for receiving a first event sent by the target robot and sending a distribution task to the cloud server;
the third decision unit 1023 is configured to acquire real-time checksum data allocated to the third decision unit 1023 by using a ping/pong request, and when the real-time checksum data changes from the checksum data acquired last time, acquire a modified task list from the cloud server, and generate a corresponding third event according to a third decision result, where the third event includes an event of rejecting to cancel a waybill or an event of accepting to cancel a waybill, and send the third event to the cloud server.
In a preferred embodiment, the status sending module 103 specifically includes:
a generating unit 1031, configured to generate an incremental and unique new event id for the new event of the distribution task according to the time, the robot identity certificate, the site identity certificate, and the current event id recorded in the database;
an upload unit 1032, configured to upload a new event including the new event id to the cloud server, and when upload fails due to a network transmission problem, enter the new event as an unsent successful event;
the retransmission unit 1033 retransmits the unsent successful events in an order of the new event ids from small to large according to the cycle of the ping/pong request and the network signal strength.
In a preferred embodiment, the state receiving module 203 is specifically configured to, after receiving the new event, check whether a new event id is greater than a maximum event id entered and whether a state of a delivery task included in the new event is backed off, modify, if the check is passed, a state of the delivery task in a task list according to information of the new event, otherwise, only enter the new event, but not modify, the state of the delivery task in the task list.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
In the above embodiments, the descriptions of the respective embodiments have respective emphasis, and reference may be made to the related descriptions of other embodiments for parts that are not described or illustrated in a certain embodiment.
Those of ordinary skill in the art will appreciate that the various illustrative elements and method steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
In the embodiments provided in the present invention, it should be understood that the disclosed apparatus/terminal device and method may be implemented in other ways. For example, the above-described embodiments of the apparatus/terminal device are merely illustrative, and for example, the division of the modules or units is only one logical division, and there may be other divisions when actually implemented, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.
The units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of the embodiment.
In addition, functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, and can also be realized in a form of a software functional unit.
The invention is not limited solely to that described in the specification and embodiments, and additional advantages and modifications will readily occur to those skilled in the art, so that the invention is not limited to the specific details, representative apparatus, and illustrative examples shown and described herein, without departing from the spirit and scope of the general concept as defined by the appended claims and their equivalents.
Claims (10)
1. A method for synchronizing waybill states of a robot and a cloud is characterized by comprising the following steps:
step 1, a cloud server inputs a delivery task created by a user, generates a corresponding waybill, and calculates real-time checksum data of the delivery task according to waybill information and the current distribution state of the delivery task;
step 2, the robot initiates a ping/pong request to the cloud server at a preset frequency to acquire real-time checksum data allocated to the robot, and when the real-time checksum data is changed with the checksum data acquired last time, a task list is acquired from the cloud server, wherein the task list comprises a delivery task corresponding to the real-time checksum data and a current allocation state of the delivery task;
step 3, the cloud server interacts with the robot according to a preset flow, receives a decision result fed back by the robot in an event form, and continuously modifies the current distribution state of the distribution tasks in the task list according to the decision result until the current distribution state of the distribution tasks is changed into the process;
and 4, when the robot executes the distribution task, continuously sending the current execution state of the distribution task to the cloud server in an event form.
2. The method for synchronizing waybill states of the robot and the cloud according to claim 1, wherein the robot is divided into a candidate robot and a target robot, the cloud server interacts with the robot according to a preset flow, receives a decision result fed back by the robot in an event form, and continuously modifies a current distribution state of a distribution task in a task list according to the decision result, and the method specifically comprises the following steps:
s301, after receiving the task list, the alternative robot generates a corresponding first event according to a first decision result and sends the first event to the cloud server, wherein the first event comprises a pre-distribution waybill refusing event or a pre-distribution waybill accepting event;
s302, the cloud server receives first events sent by all the alternative robots, selects a target robot from the alternative robots which are pre-distributed, modifies the current distribution state of the distribution tasks in the task list into a distributed state, and generates corresponding real-time checksum data;
s303, the target robot acquires real-time checksum data distributed to the target robot through a ping/pong request, acquires the modified task list from the cloud server when the real-time checksum data is changed with the checksum data acquired last time, generates a corresponding second event according to a second decision result, and sends the second event to the cloud server, wherein the second event comprises an event of refusing to distribute waybills or an event of accepting to distribute waybills;
s304, the cloud server receives a second event sent by the target robot, if the second event is an event of accepting and distributing waybill, the current distribution state of the distribution task is modified to be in progress, if the second event is an event of refusing to distribute waybill, the operation returns to S302 to reselect the target robot, and the steps S303 and S304 are executed until one target robot accepts the distribution task or the overtime of the distribution task is reached.
3. The method for synchronizing waybill states of the robot and the cloud according to claim 1 or 2, further comprising a waybill canceling step, wherein the waybill canceling step specifically comprises:
when a user cancels the executing delivery task from a cloud server, the cloud server modifies the current execution state of the delivery task in a task list into a user application cancellation state and generates corresponding real-time checksum data;
the target robot acquires real-time checksum data distributed to the target robot through a ping/pong request, acquires a modified task list from the cloud server when the real-time checksum data is changed with the checksum data acquired last time, generates a corresponding third event according to a third decision result, and sends the third event to the cloud server, wherein the third event comprises an event of refusing to cancel the waybill or an event of accepting to cancel the waybill;
and the cloud server receives a third event sent by the target robot, and modifies the current execution state of the distribution task according to the third event, so that a user can conveniently inquire a cancellation result through the cloud server.
4. The method for synchronizing waybill states of the robot and the cloud according to claim 3, wherein the robot feeds back each decision result and the execution state of the distribution task to the cloud server in an event form, and the method specifically comprises the following steps:
s401, generating an increasing and unique new event id for the new event of the distribution task according to time, the identity certification of the robot, the identity certification of the station and the current event id recorded in the database;
s402, uploading a new event comprising the new event id to the cloud server, and when uploading fails due to a network transmission problem, recording the new event as an unsent successful event;
and S403, retransmitting the unsent successful events according to the sequence of the new event ids from small to large according to the cycle of the ping/pong request and the network signal strength.
5. The method according to claim 4, wherein after receiving the new event, the cloud server checks whether a new event id is larger than a maximum event id entered and whether a status of a delivery task included in the new event is returned, and if the check is passed, modifies the status of the delivery task in a task list according to information of the new event, otherwise, only the new event is entered, but the status of the delivery task in the task list is not modified.
6. A waybill state synchronization system of a robot and a cloud is characterized by comprising the robot and a cloud server, wherein the cloud server comprises a waybill distribution module, a first interaction module and a state receiving module,
the waybill distribution module is used for inputting a distribution task created by a user, generating a corresponding waybill, and calculating real-time checksum data of the distribution task according to waybill information and the current distribution state of the distribution task;
the first interaction module is used for interacting with the robot according to a preset flow, receiving a decision result fed back by the robot in an event form, and continuously modifying the current distribution state of the distribution tasks in the task list according to the decision result until the current distribution state of the distribution tasks is consistent with any target robot and is changed into the process;
the state receiving module is used for receiving the current execution state of the distribution task sent by the robot in an event form;
the robot comprises a request module, a second interaction module and a state sending module,
the request module is used for the robot to send ping/pong requests to the cloud server at a preset frequency, obtain real-time checksum data allocated to the robot, and obtain a task list from the cloud server when the real-time checksum data is changed with the checksum data obtained last time, wherein the task list comprises a delivery task corresponding to the real-time checksum data and a current allocation state of the delivery task;
the second interaction module is used for feeding back a decision result for the distribution task to the cloud server in an event form;
the state sending module is used for continuously sending the current execution state of the distribution task to the cloud server in an event form when the distribution task is executed.
7. The waybill state synchronization system of the robot and the cloud according to claim 6, wherein the second interaction module specifically comprises a first decision unit and a second decision unit, the first decision unit is disposed on the candidate robot, the second decision unit is disposed on the target robot,
the first decision unit is used for generating a corresponding first event according to a first decision result and sending the corresponding first event to the cloud server after receiving the task list, wherein the first event comprises a pre-distribution waybill refusing event or a pre-distribution waybill accepting event;
the second decision unit is used for acquiring real-time checksum data allocated to the second decision unit through a ping/pong request, acquiring the modified task list from the cloud server when the real-time checksum data is changed with the checksum data acquired last time, generating a corresponding second event according to a second decision result, and sending the second event to the cloud server, wherein the second event comprises an event of refusing to allocate the waybill or an event of accepting to allocate the waybill;
the first interactive module specifically includes a first allocation unit and a second allocation unit,
the first distribution unit is used for receiving first events sent by all the alternative robots, selecting a target robot from the alternative robots which are subjected to pre-distribution, modifying the current distribution state of the distribution tasks in the task list into a distributed state, and generating corresponding real-time checksum data;
and the second distribution unit is used for receiving a second event sent by the target robot, modifying the current distribution state of the distribution task to be in progress if the second event is an order accepting and distributing event, and driving the first distribution unit to reselect the target robot if the second event is an order refusing and distributing event until one target robot receives the distribution task or the overtime time of the distribution task is reached.
8. The waybill state synchronization system of the robot and the cloud end according to claim 6 or 7, wherein the cloud server further comprises a waybill cancellation module, the target robot further comprises a third decision unit,
the waybill canceling module is used for modifying the current execution state of the distribution tasks in the task list into user application canceling when a user cancels the distribution tasks being executed to the cloud server, and generating corresponding real-time checksum data; the system comprises a target robot, a cloud server and a server, wherein the target robot is used for receiving a first event sent by the target robot and sending a distribution task to the cloud server;
the third decision unit is configured to acquire real-time checksum data allocated to the third decision unit through a ping/pong request, acquire a modified task list from the cloud server when the real-time checksum data changes from the checksum data acquired last time, generate a corresponding third event according to a third decision result, and send the third event to the cloud server, where the third event includes a rejection of a waybill cancellation event or an acceptance of a waybill cancellation event.
9. The waybill status synchronization system for robots and the cloud according to claim 8, wherein the status sending module specifically comprises:
the generating unit is used for generating an increasing and unique new event id for the new event of the distribution task according to the time, the identity certification of the robot, the identity certification of the station and the current event id recorded in the database;
the uploading unit is used for uploading a new event comprising the new event id to the cloud server, and when uploading fails due to a network transmission problem, the new event is recorded as an unsent successful event;
and the retransmission unit retransmits the unsent successful events according to the cycle of the ping/pong request and the network signal strength in the order of the new event ids from small to large.
10. The waybill status synchronization system for the robot and the cloud according to claim 9, wherein the status receiving module is specifically configured to check whether a new event id is larger than a maximum event id entered and whether a status of a delivery task included in the new event is returned after receiving the new event, modify the status of the delivery task in a task list according to information of the new event if the check is passed, otherwise only enter the new event, but not modify the status of the delivery task in the task list.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010939087.4A CN112025713B (en) | 2020-09-09 | 2020-09-09 | Method and system for synchronizing waybill states of robot and cloud |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010939087.4A CN112025713B (en) | 2020-09-09 | 2020-09-09 | Method and system for synchronizing waybill states of robot and cloud |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112025713A true CN112025713A (en) | 2020-12-04 |
| CN112025713B CN112025713B (en) | 2022-01-28 |
Family
ID=73585492
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010939087.4A Active CN112025713B (en) | 2020-09-09 | 2020-09-09 | Method and system for synchronizing waybill states of robot and cloud |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112025713B (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112650560A (en) * | 2021-01-18 | 2021-04-13 | 济南浪潮高新科技投资发展有限公司 | Container design-based cloud robot model issuing method |
| CN112671894A (en) * | 2020-12-22 | 2021-04-16 | 上海有个机器人有限公司 | Robot task remote cancelling method, device, terminal and storage medium |
| CN113905075A (en) * | 2021-09-13 | 2022-01-07 | 中国船舶重工集团公司第七一六研究所 | Control system and method for clouding robot in 5G environment |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20110095532A (en) * | 2010-02-19 | 2011-08-25 | 모빌토크(주) | Apparatus method for musical conduct using gesture recognition robot |
| US20160050271A1 (en) * | 2014-08-13 | 2016-02-18 | Kabushiki Kaisha Toshiba | Communication apparatus, content client and content server |
| CN107992321A (en) * | 2017-12-28 | 2018-05-04 | 国机智骏（北京）汽车科技有限公司 | ECU software update method, device, vehicle-mounted T-BOX and vehicle |
| CN110727650A (en) * | 2019-12-18 | 2020-01-24 | 广联达科技股份有限公司 | Cloud document synchronization method and system |
| CN111240320A (en) * | 2019-12-31 | 2020-06-05 | 福建凯米网络科技有限公司 | Robot meal delivery method, device and medium for audio-visual place |
| CN111368279A (en) * | 2020-02-25 | 2020-07-03 | 深圳市腾讯计算机系统有限公司 | Data processing method, data processing device, computer readable storage medium and computer equipment |
-
2020
- 2020-09-09 CN CN202010939087.4A patent/CN112025713B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20110095532A (en) * | 2010-02-19 | 2011-08-25 | 모빌토크(주) | Apparatus method for musical conduct using gesture recognition robot |
| US20160050271A1 (en) * | 2014-08-13 | 2016-02-18 | Kabushiki Kaisha Toshiba | Communication apparatus, content client and content server |
| CN107992321A (en) * | 2017-12-28 | 2018-05-04 | 国机智骏（北京）汽车科技有限公司 | ECU software update method, device, vehicle-mounted T-BOX and vehicle |
| CN110727650A (en) * | 2019-12-18 | 2020-01-24 | 广联达科技股份有限公司 | Cloud document synchronization method and system |
| CN111240320A (en) * | 2019-12-31 | 2020-06-05 | 福建凯米网络科技有限公司 | Robot meal delivery method, device and medium for audio-visual place |
| CN111368279A (en) * | 2020-02-25 | 2020-07-03 | 深圳市腾讯计算机系统有限公司 | Data processing method, data processing device, computer readable storage medium and computer equipment |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112671894A (en) * | 2020-12-22 | 2021-04-16 | 上海有个机器人有限公司 | Robot task remote cancelling method, device, terminal and storage medium |
| CN112650560A (en) * | 2021-01-18 | 2021-04-13 | 济南浪潮高新科技投资发展有限公司 | Container design-based cloud robot model issuing method |
| CN112650560B (en) * | 2021-01-18 | 2022-10-18 | 山东浪潮科学研究院有限公司 | Container design-based cloud robot model issuing method |
| CN113905075A (en) * | 2021-09-13 | 2022-01-07 | 中国船舶重工集团公司第七一六研究所 | Control system and method for clouding robot in 5G environment |
| CN113905075B (en) * | 2021-09-13 | 2023-11-10 | 中国船舶集团有限公司第七一六研究所 | Control system and method for cloud robot in 5G environment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112025713B (en) | 2022-01-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112025713B (en) | Method and system for synchronizing waybill states of robot and cloud | |
| EP3536646B1 (en) | Authorization management of elevator service request | |
| EP3536647A1 (en) | Authorization management and authorization request of elevator service request | |
| CN110544061A (en) | Material distribution method and system | |
| EP3171305A1 (en) | System and method for servicing a damaged vehicle | |
| US11784962B2 (en) | Systems and methods for collaborative chat with non-native chat platforms | |
| US20160337210A1 (en) | Method and system for trouble ticketing | |
| CN108510136A (en) | A kind of scheduler subsystem of steel-making enterprise three-level production planning system | |
| CN104809551A (en) | Cross-system workflow cooperation method based on mobile agent client side | |
| CN108762932A (en) | A kind of cluster task scheduling system and processing method | |
| KR100845707B1 (en) | Multi-planner operation planning system and method of container terminal | |
| CN110175798A (en) | A kind of warehousing system operation method based on mobile application | |
| WO2013097827A1 (en) | Dispatching system and method | |
| JP2017027155A (en) | Progress management system and progress management program | |
| CN102541539B (en) | Method for designing intelligent panel of supply chain based on M2M (Machine to Machine) | |
| CN115102610B (en) | Sharing method and device of Beidou RDSS equipment | |
| US20100312860A1 (en) | Planning And Controlling Of Objects Transportation | |
| CN101082967A (en) | Plan for carrying objects and controlling therefore | |
| JP6120676B2 (en) | Board production management device | |
| CN102594730B (en) | Information interaction method and system | |
| CN111737157B (en) | Concurrency test method and system for user graphical interface | |
| CN220139626U (en) | Cooperative interaction equipment device oriented to aircraft assembly process | |
| TWI701616B (en) | Method of planning sequence of processing missions | |
| WO2021181507A1 (en) | Management system and mobile terminal | |
| CN114511204A (en) | Worker and friend order dispatching method, system and equipment based on personnel positioning |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |