Delay time detection method, controller, robot and storage medium

Abstract

The invention relates to the technical field of robot control, and provides a delay time detection method, a controller, a robot and a storage medium. The method comprises the steps that when a first control instruction is generated and sent to a preset robot, a first timestamp corresponding to the first control instruction in a controller time coordinate system is acquired; acquiring a second timestamp corresponding to the first control instruction in a preset robot time coordinate system; obtaining a first difference value corresponding to the first timestamp and the second timestamp; acquiring a third timestamp corresponding to the second control instruction in a controller time coordinate system; acquiring a fourth timestamp corresponding to the second control instruction in the robot time coordinate system; acquiring a second difference value corresponding to the third timestamp and the fourth timestamp; and delay time corresponding to the second control instruction is obtained according to the first difference value and the second difference value, and whether the robot is controlled to execute the second control instruction or not is determined according to the delay time.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of robot control, and in particular to a delay time detection method, a controller, a robot and a storage medium. BACKGROUND

[0002] In the field of wireless robot control, to avoid the robot executing expired instructions due to instruction transmission delay, the existing solution relies on time synchronization between the controller and the robot, calculates the difference between the sending time and the receiving time of the instructions through the unified time dimension after synchronization, and judges whether the delay is out of limit. For example, the controller (mobile phone APP) and the robot calibrate the system time in advance, the instructions carry the sending timestamp, and the robot calculates the delay through "receiving time - sending time".

[0003] However, in the existing control method, if there is a delay in time synchronization (such as network time delay) or devices cannot be synchronized (such as cross-platform systems, clock deviation of low-power devices), it will cause continuous errors in delay calculation, and even cause the risk of robot out of control. And additional protocols or hardware are needed to support time synchronization, which increases the design cost of the system, and cannot adapt to the minimalist hardware scene (such as embedded robots without real-time clock).

[0004] Therefore, there is an urgent need for a method to solve at least one of the above problems. SUMMARY

[0005] The present application provides a delay time detection method, a controller, a robot and a storage medium, which aims to solve the problem that in the existing control method, if there is a delay in time synchronization (such as network time delay) or devices cannot be synchronized (such as cross-platform systems, clock deviation of low-power devices), it will cause continuous errors in delay calculation, and even cause the risk of robot out of control.

[0006] In a first aspect, the present application provides a delay time detection method applied to a controller, comprising: When a first control instruction is generated and sent to a preset robot, a first timestamp corresponding to the first control instruction in a preset controller time coordinate system is obtained; When the robot receives the first control instruction, a second timestamp corresponding to the robot in a preset robot time coordinate system is obtained; A first difference value corresponding to the first timestamp and the second timestamp is obtained; When a second control instruction is generated and sent to the robot, a third timestamp corresponding to the second control instruction in the controller time coordinate system is obtained; When the robot receives the second control instruction, a fourth timestamp corresponding to the robot in the robot time coordinate system is obtained; acquire a second difference value corresponding to the third timestamp and the fourth timestamp; acquire a delay time corresponding to the second control instruction according to the first difference value and the second difference value, to determine whether to control the robot to execute the second control instruction according to the delay time.

[0007] In a second aspect, the application further provides a delay time detection method applied to a robot, and the method comprises: acquire a first control instruction sent by a controller and a first timestamp corresponding to the first control instruction in a preset controller time coordinate system; acquire a second timestamp in a preset robot time coordinate system when the first control instruction is received; acquire a first difference value corresponding to the first timestamp and the second timestamp; acquire a second control instruction sent by the controller and a third timestamp corresponding to the second control instruction in the preset controller time coordinate system; acquire a fourth timestamp in the preset robot time coordinate system when the second control instruction is received; acquire a second difference value corresponding to the third timestamp and the fourth timestamp; acquire a delay time corresponding to the second control instruction according to the first difference value and the second difference value, to determine whether to execute the second control instruction according to the delay time.

[0008] In a third aspect, the application further provides a controller, comprising: a memory and a processor; the memory is configured to store a computer program; the processor is configured to execute the computer program and implement the steps of the delay time detection method according to the first aspect.

[0009] In a fourth aspect, the application further provides a controller, comprising: a memory and a processor; the memory is configured to store a computer program; the processor is configured to execute the computer program and implement the steps of the delay time detection method according to the second aspect.

[0010] In a fifth aspect, the application further provides a computer readable storage medium, which stores a computer program, and the computer program is configured to make a processor implement the steps of the delay time detection method according to the first aspect or the second aspect when the computer program is executed by the processor.

[0011] The application provides a delay time detection method, which comprises the following steps: a controller (such as a mobile phone APP or a remote controller) records the sending time stamps (a first time stamp and a third time stamp) of two control instructions respectively when sending the control instructions, and obtains the local time stamps (a second time stamp and a fourth time stamp) when a robot receives the two instructions. The difference (a first difference and a second difference) between the two time stamps is calculated, the consistency principle of the double-end time increment is used (that is, the time elapse speed of the controller and the robot is consistent), the system reference time difference is determined based on the theoretical constancy of the two differences, and then the transmission delay of subsequent instructions is calculated to determine whether the instructions are executed.

[0012] The controller and the robot adopt different time measurement methods (such as the controller using system time and the robot using running time), and time synchronization is not required in advance. The reference time difference independent of synchronization is established through the consistency of the time difference of the first two instructions (the first difference and the second difference are theoretically equal), and the reference for subsequent delay calculation is provided. The instruction delay detection and the double-end time synchronization are decoupled, only the consistency of the time increment is relied on, and the influence of synchronization error is avoided.

[0013] The provided method does not require high-precision time synchronization between the controller and the robot, and solves the detection failure problem caused by synchronization failure or synchronization delay in the prior art. At the same time, even if the double-end time coordinate system is independent (such as the controller system time can jump and the robot running time can be reset), the reference is established through the consistency of the two differences, and the reliability of the delay calculation is ensured. The double-end time coordinate system can be freely selected (such as Unix time and running time), and is suitable for different device hardware architectures (such as low-cost robots without real-time clock modules).

[0014] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the application. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the technical solutions of the embodiments of the application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are some embodiments of the application, and other drawings can be obtained by those skilled in the art without creating laborious work.

[0016] Figure 1 is a step schematic flow chart of the first delay time detection method provided by an embodiment of the application; Figure 2 is a principle schematic diagram of a delay time detection method provided by an embodiment of the application; Figure 3 is a step schematic flow chart of the second delay time detection method provided by an embodiment of the application; Figure 4 is a structural schematic diagram of a first delay time detection device provided by an embodiment of the present application; Figure 5 is a structural schematic block diagram of a controller provided by an embodiment of the present application.

[0017] Figure 6 is a structural schematic diagram of a second delay time detection device provided by an embodiment of the present application; Figure 7 is a structural schematic block diagram of a robot provided by an embodiment of the present application.

[0018] It should be understood that the above general description and the following detailed description are only exemplary and explanatory, and cannot limit the present application. DETAILED DESCRIPTION

[0019] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0020] The flowcharts shown in the drawings are only exemplary and are not necessarily required to include all the contents and operations / steps, and are not necessarily executed in the described order. For example, some operations / steps can be decomposed, combined or partially combined, and thus the actual execution order can be changed according to the actual situation.

[0021] It should be understood that, in order to clearly describe the technical solutions of the embodiments of the present application, in the embodiments of the present application, the terms of “first”, “second” and the like are used to distinguish the same items or similar items with basically the same functions and effects. Those skilled in the art can understand that the terms of “first”, “second” and the like do not limit the quantity and execution order, and the terms of “first”, “second” and the like do not necessarily mean different.

[0022] It should be understood that the terms used in the present application specification are only for the purpose of describing specific embodiments and do not intend to limit the present application. As used in the present application specification and the appended claims, unless otherwise clearly indicated by the context, the singular forms “a”, “an” and “the” are intended to include the plural forms.

[0023] It should also be understood that the term “and / or” used in the present application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes these combinations.

[0024] Some embodiments of the present application will be described in detail with reference to the drawings. The following examples and features in the examples can be combined with each other in the case of no conflict.

[0025] In the field of wireless robot control, to avoid the robot executing expired instructions due to instruction transmission delay, the existing solution relies on time synchronization between the controller and the robot, calculates the difference between the instruction sending time and the receiving time through the unified time dimension after synchronization, and judges whether the delay is out of limit. For example, the controller (mobile phone APP) and the robot calibrate the system time in advance, the instruction carries the sending timestamp, and the robot calculates the delay through "receiving time - sending time".

[0026] However, in the existing control method, if there is a delay in time synchronization (such as network time delay) or devices cannot be synchronized (such as cross-platform systems, clock deviation of low-power devices), it will cause continuous error in delay calculation, and even cause the risk of robot out of control. And additional protocols or hardware are needed to support time synchronization, which increases the design cost of the system, and cannot adapt to the minimalist hardware scene (such as embedded robots without real-time clock).

[0027] Therefore, there is an urgent need for a method to solve at least one of the above problems.

[0028] To solve the above problems, please refer to Figure 1 , Figure 1 is a schematic flowchart of the delay time detection method provided by an embodiment of the present application. The delay time detection method can be implemented by a controller, which can be deployed on a single server or a server cluster. It can also be deployed on handheld terminals, notebook computers, wearable devices, or robots, etc.

[0029] To solve the above problems, please refer to Figure 1 . Specifically, as shown in Figure 1 , the provided delay time detection method includes steps S101 to S107. Details are as follows: Step S101. When generating a first control instruction to send to a preset robot, a first timestamp corresponding to the first control instruction in a preset controller time coordinate system is obtained.

[0030] Specifically, when the controller generates a first control instruction (such as a moving, grabbing, etc. operation instruction) and sends it to the robot, the timestamp of the instruction in the local time coordinate system of the controller is recorded. The "controller time coordinate system" here can be the system clock of the controller itself (such as the system time of the mobile phone APP, the local clock of the server) or a custom counter (such as a self-incrementing timing unit based on processor cycles), which does not need to be time-synchronized with the robot.

[0031] In some embodiments, the controller can obtain the timestamp in the following ways: if the controller is a smart device (such as a mobile phone or a computer), the system API can be directly called to obtain the current time (such as the Unix timestamp or the millisecond-level timestamp); if the controller is a low-power embedded device, an internal timer (such as the tick timer of the MCU) or an incrementing counter (counting up by 1 for each sent instruction, and estimating the time based on the sending interval) can be used. By packaging the first timestamp with the control instruction, for example, by adding a fixed field to store the timestamp in the instruction packet.

[0032] This step only relies on the local time of the controller, avoiding the time calibration problem caused by network delay or cross-platform synchronization error in the traditional scheme. It is suitable for any controller with timing capability, including simple hardware scenarios (such as devices without real-time clocks can be implemented through counters).

[0033] Step S102. Obtain a second timestamp corresponding to the robot time coordinate system at the time when the robot receives the first control instruction.

[0034] Specifically, after receiving the first control instruction, the robot records the timestamp of the instruction in the robot's local time coordinate system. Similar to the controller, the robot's time coordinate system is independent of the controller and can be implemented based on its own system clock or counter, without the need for alignment with the controller.

[0035] In some embodiments, the robot triggers time recording in the instruction reception interrupt or callback function: if the robot has a real-time clock (RTC), it directly reads the current time; if it is a simple embedded device, it can use an on-chip timer (such as the TIM module of STM32) or a reception counter (counting up by 1 for each received instruction, and estimating the time based on the reception interval). The second timestamp is temporarily stored in the local cache or returned to the controller with the response message (if the communication link supports bidirectional transmission).

[0036] The robot does not need to synchronize time with the controller, reducing the dependence on hardware (such as RTC) and protocols (such as NTP), especially suitable for low-power and low-cost devices. Even if there is a frequency deviation (such as crystal drift) between the two clocks, the subsequent steps can eliminate the influence through the relative difference.

[0037] Step S103. Obtain the first difference value corresponding to the first timestamp and the second timestamp.

[0038] Specifically, by calculating the difference between the second timestamp recorded by the robot and the first timestamp sent by the controller, ΔT1 = second timestamp - first timestamp is obtained. Since the two time coordinate systems are independent, the difference value contains the transmission delay and the clock deviation (such as the time difference caused by the unsynchronized clocks of the controller and the robot).

[0039] The difference calculation can directly perform numerical subtraction without calibrating time units (such as using millisecond-level counts or incrementing periods). If a counter is used, the difference is the number of counting periods; if a system time is used, the difference is the absolute time difference (such as milliseconds). Through the time difference of a single transmission, a mixed value containing delay and clock bias is captured, providing basic data for subsequent double measurement to eliminate bias.

[0040] Step S104. When the second control instruction is generated and sent to the robot, a third timestamp corresponding to the second control instruction in the controller time coordinate system is obtained.

[0041] Specifically, when the second control instruction (which can be of the same type or a different type as the first instruction) is sent, a timestamp (third timestamp) in the controller local time coordinate system is recorded again. This step is consistent with S101 logic, ensuring that the timestamps of the two instructions are generated under the controller independent clock.

[0042] The implementation of this step is exactly the same as S101, ensuring the consistency of the timestamp acquisition mechanism (such as the same counter or system clock source). The second instruction needs to form a "pairing" in time with the first instruction for subsequent difference comparison (two transmissions form a symmetric measurement). Through two instruction transmissions, a bidirectional time difference measurement model is constructed, providing necessary data pairs for eliminating clock bias.

[0043] Step S105. Obtain the fourth timestamp corresponding to the second control instruction in the robot time coordinate system when the robot receives it.

[0044] Specifically, when the robot receives the second control instruction, a fourth timestamp in its own time coordinate system is recorded. Consistent with S102 logic, independent of the controller clock, ensuring that both receiving timestamps are generated under the robot local clock. The implementation of this step is exactly the same as S102, ensuring the consistency of the timestamp acquisition mechanism (such as the same counter or real-time clock source). The fourth timestamp needs to form a pair with the third timestamp for subsequent difference calculation. Through two receiving timestamps, a time sequence at the robot end is constructed, corresponding to the two sending timestamps at the controller end, providing conditions for error separation.

[0045] Step S106. Obtain the second difference corresponding to the third timestamp and the fourth timestamp.

[0046] Specifically, by calculating AT2 = fourth timestamp - third timestamp, similar to AT1, the difference contains the transmission delay of the second transmission and the clock bias (assuming that the clock bias is stable in a short time, such as crystal drift can be regarded as a fixed offset). The calculation method of this step is consistent with S103, and direct numerical subtraction is performed without calibrating the time unit. Through the time difference (AT1 and AT2) of two independent transmissions, an equation set containing the same clock bias but symmetric transmission delay is constructed (assuming that the two-way delay is approximately equal), which provides a mathematical basis for subsequent bias elimination.

[0047] Step S107. Obtain a delay time corresponding to the second control instruction according to the first difference value and the second difference value, so as to determine whether to control the robot to execute the second control instruction according to the delay time.

[0048] Assuming that the one-way delay of the two transmissions is the same (in practice, the wireless communication delay can be regarded as symmetric in a short time), and the clock bias of the controller and the robot is constant (such as AT1 = d + θ, AT2 = d - θ, where d is the one-way delay, and θ is the clock bias), the true delay time can be calculated by the following formula: d = (AT1 + AT2) / 2; by eliminating the influence of the clock bias θ, the true transmission delay d of the second instruction is obtained, and then it is judged whether d exceeds the threshold value (such as 50ms), if it exceeds the limit, the instruction is discarded to avoid executing expired operation.

[0049] The step is based on the assumption of symmetric transmission, and the clock bias is offset by the average value of the two difference values (assuming that θ is constant within the two transmission intervals). A preset delay threshold is set, if the calculated d exceeds the threshold, the controller sends an invalid instruction or the robot refuses to execute; if it does not exceed the limit, it is executed normally. Further, without time synchronization, the transmission delay and the clock bias are separated by double measurement, solving the calculation error problem caused by synchronization error in the traditional scheme. It supports minimalist hardware (such as embedded devices without RTC can use counters to implement time stamps), without additional protocols or hardware to support time synchronization, reducing the design cost of the system. By dynamically calculating the real-time delay, it is ensured that the robot only executes "fresh" instructions, avoiding the risk of losing control due to delay misjudgment, especially suitable for scenes with high real-time requirements (such as unmanned aerial vehicle control, industrial robot arm).

[0050] Steps S101-S107 construct a delay calculation model by double symmetric measurement, convert "time synchronization dependence" into "relative time difference analysis", eliminate the influence of clock bias between devices by mathematical average, and realize delay detection without global time synchronization. Compared with the traditional scheme, its core advantage lies in low dependence on hardware and protocol, high compatibility and robustness, which fundamentally solves the time synchronization problem in cross-platform and low-power consumption scenarios.

[0051] In some embodiments, before obtaining the delay time corresponding to the second control instruction according to the first difference value and the second difference value, the method further comprises: obtaining a third difference value corresponding to the first timestamp and the third timestamp; obtaining a fourth difference value corresponding to the second timestamp and the fourth timestamp; obtaining a fifth difference value corresponding to the third difference value and the fourth difference value; if the fifth difference value is greater than a preset threshold, determining that the robot time coordinate system is abnormal, and re-generating the first control instruction and sending it to the robot.

[0052] Before calculating the delay time of the second control instruction, the time stamp change difference between the controller and the robot is compared to detect whether the robot local clock is abnormal (such as clock jump, counter reset, etc.). The specific steps include: calculating the time difference (third difference value, ΔT3 = third timestamp-first timestamp) of the controller sending the instruction twice, reflecting the natural elapse of the controller local clock; calculating the time difference (fourth difference value, ΔT4 = fourth timestamp-second timestamp) of the robot receiving the instruction twice, reflecting the natural elapse of the robot local clock; calculating the fifth difference value (ΔT5 = |ΔT3-ΔT4|), if ΔT5 exceeds the preset threshold, it means that the clock change difference between the two is too large (such as abnormal jump or stagnation of the robot clock), and it is determined that the robot time coordinate system is abnormal, triggering the instruction retransmission mechanism.

[0053] The time difference calculation records the third difference value ΔT3 (based on the controller local counter or system time) through the controller when sending the first and second instructions; records the fourth difference value ΔT4 (based on the robot local counter or system time) through the robot when receiving the first and second instructions; the controller obtains ΔT4 of the robot through the communication link (such as the robot carrying the two receiving time stamps in the response), and calculates ΔT5 = |ΔT3-ΔT4|.

[0054] The abnormality determination and processing set the preset threshold according to the device clock stability (such as the maximum period error allowed by the embedded device counter); if ΔT5 is out of limit, the controller discards the current second instruction and re-sends the first control instruction (re-establishes the time difference measurement reference).

[0055] By comparing the "time elapse consistency" of the clocks of the two parties, it is detected whether the robot clock is abnormal due to hardware failure (such as timer reset) or software exception (such as system restart), so as to avoid calculating the delay based on the wrong time stamp; when abnormal, the first instruction is actively retransmitted to re-establish the measurement reference, ensuring the reliability of subsequent delay calculation, which is especially suitable for low-power devices (which may cause clock reset due to sleep / wakeup).

[0056] In some embodiments, the delay time corresponding to the second control instruction is obtained according to the first difference value and the second difference value, comprising: obtaining a third difference value corresponding to the first time stamp and the third time stamp; obtaining a fourth difference value corresponding to the second time stamp and the fourth time stamp; obtaining a clock frequency difference compensation factor of the controller and the robot according to the third difference value and the fourth difference value; and obtaining the delay time corresponding to the second control instruction according to the clock frequency difference compensation factor, the first difference value and the second difference value.

[0057] Considering that the clock frequencies of the controller and the robot can be different (for example, the timing periods are inconsistent due to different crystal oscillator precisions), the clock frequency compensation factor of the controller and the robot is calculated through the third difference value (the time difference ΔT3 between two sending times of the controller) and the fourth difference value (the time difference ΔT4 between two receiving times of the robot), and the delay calculation result is corrected. The specific steps are as follows: a frequency compensation factor k = ΔT4 / ΔT3 (reflecting the frequency ratio of the clock of the robot to the clock of the controller, if the frequencies are consistent, k = 1) is calculated; the first difference value and the second difference value are corrected by using the compensation factor, so as to eliminate the influence of the frequency deviation on the delay calculation; and finally, the delay formula is adjusted as follows: d = (ΔT1*k + ΔT2) / 2 (assuming that the frequency difference between the sending time of the controller and the receiving time of the robot is compensated by k).

[0058] The frequency compensation factor is calculated by the time interval ΔT3 (for example, 10 ms, based on the local timer of the controller) between two sending times of the controller; and the time interval ΔT4 (for example, 10.5 ms actually elapsed, based on the local timer of the robot) between two receiving times of the robot; and k = ΔT4 / ΔT3 = 1.05 is calculated, indicating that the clock of the robot is 5% slower than the clock of the controller.

[0059] The delay correction is performed by multiplying k to convert the first difference value ΔT1 (the receiving time of the robot minus the sending time of the controller) into the difference value in the time dimension of the controller, and calculating the second difference value ΔT2 directly in the time dimension of the controller, and finally obtaining the real delay by averaging.

[0060] The clock frequency deviation problem caused by the precision difference of the device crystal oscillator in the traditional scheme (for example, the controller uses a high-frequency clock, and the robot uses a low-cost low-frequency clock) is solved, the cumulative error of the delay calculation caused by the inconsistent frequencies is avoided, and the unified delay calculation standard is realized by dynamic compensation, which supports the controller and the robot to use different precision clock sources (for example, a high-precision clock of a mobile phone and a low-precision counter of an embedded device).

[0061] In some embodiments, whether the robot executes the second control instruction is determined according to the delay time, comprising: if the delay time is less than a preset target time length, the robot executes the second control instruction.

[0062] By setting a preset target duration (such as 50 ms) as the delay threshold, if the calculated second control instruction delay time is less than the threshold, the instruction is determined to be "valid" and the robot is controlled to execute; otherwise, the instruction is determined to be "expired" and discarded.

[0063] The threshold is preset according to the application scenario requirements (such as setting 20 ms for low delay in industrial control and 100 ms for consumer robots), and a fixed target duration Ttarget is preset on the controller or robot side; the decision logic includes d < Ttarget → execute the instruction; d ≥ Ttarget → ignore the instruction (or send a retransmission request). By simple and clear threshold judgment, it prevents the robot from executing outdated instructions due to high delay (such as path planning errors caused by high delay of movement instructions); it is suitable for delay-sensitive scenarios (such as remote surgery robots), and through fixed threshold rapid decision, it avoids the additional computational overhead caused by complex logic.

[0064] For example, if the delay time is less than the preset target duration, before controlling the robot to execute the second control instruction, the method further includes: obtaining the instruction type corresponding to the second control instruction; determining the urgency of the second control instruction according to the instruction type; and determining the target duration corresponding to the second control instruction according to the urgency.

[0065] According to the type of the second control instruction (such as emergency stop, normal movement, and state query), the urgency of the second control instruction is determined, and different target durations correspond to different urgencies. For example: emergency instruction (such as stop) → target duration set to minimum value (10 ms), low delay required; normal instruction (such as uniform movement) → target duration set to medium value (50 ms); non-real-time instruction (such as log query) → target duration set to large value (200 ms).

[0066] The instruction classification and mapping establish a mapping table (such as a dictionary structure) of urgency and target duration by defining an instruction type enumeration (such as EMERGENCY, NORMAL, ASYNC); the controller sends the instruction with the instruction type field, and the robot or controller queries the corresponding Ttarget according to the field.

[0067] Dynamic threshold decision includes, for example, when an emergency stop instruction is received, the target duration is set to 10 ms, and only when the delay is < 10 ms, the execution is ensured to be fast; when a normal movement instruction is received, the target duration is relaxed to 50 ms, allowing a certain delay.

[0068] The threshold is dynamically adjusted according to the real-time requirements of different instructions, avoiding resource waste or insufficient response caused by "one-size-fits-all"; by ensuring the execution efficiency of high-urgency instructions (such as strictly controlling the delay of safety-related instructions), while allowing low-priority instructions to tolerate a certain delay, the overall robustness of the system is improved.

[0069] Exemplarily, before the robot is controlled to execute the second control instruction if the delay time is less than the preset target duration, the method further comprises: acquiring current network intensity information corresponding to the second control instruction; and adjusting the target duration according to the current network intensity information.

[0070] The target duration is dynamically adjusted by combining the current network intensity (such as Wi-Fi signal intensity, Bluetooth RSSI value). When the network intensity is low (such as weak signal), the preset target duration is appropriately relaxed (allowing greater delay) to avoid misjudgment of instruction expiration due to accidental signal fluctuation; when the network intensity is high, the target duration is tightened to pursue more stringent real-time performance.

[0071] The network intensity is acquired by the controller through the communication module API to acquire the current network intensity (such as the getRssi() interface of the mobile phone Wi-Fi, the signal intensity register value of the embedded device); the intensity level (such as strong, medium, and weak) is defined, and different target duration adjustment strategies (such as increasing the target duration by 50% when the signal is weak) are correspondingly defined.

[0072] A preset basic target duration Tbase is calculated according to the network intensity in real time, and Ttarget=Tbase×adjustment coefficient (such as a weak signal adjustment coefficient of 1.5 and a strong signal adjustment coefficient of 0.8).

[0073] Misjudgment caused by network transient fluctuation (such as signal shielding) is avoided, and instruction validity is more reasonably judged in a complex wireless environment; greater delay is allowed when the signal is weak to reduce bandwidth waste caused by frequent retransmission; and delay is strictly controlled when the signal is strong to fully utilize the high-quality network condition.

[0074] It should be noted that in some embodiments, adjusting the target duration according to the current network intensity information comprises: acquiring a plurality of historical instruction delay information corresponding to the controller and the robot; the historical instruction delay information comprises historical instruction transmission delay duration and corresponding historical network intensity information; matching the current network intensity information with the plurality of historical network intensity information to acquire the historical instruction transmission delay duration corresponding to the current network intensity information; and adjusting the target duration according to the historical instruction transmission delay duration.

[0075] By establishing a historical instruction delay database, the average transmission delay corresponding to each historical network intensity is stored, and by matching the current network intensity, the corresponding historical average delay is acquired as the basis for adjusting the target duration. For example, historical data shows that when the Wi-Fi signal intensity is -70 dBm, the average delay is 40 ms, and therefore when the current signal intensity is -70 dBm, the target duration is set to 40 ms + safety margin (such as 10 ms).

[0076] The historical data collection and storage continuously records the transmission delay di of each instruction and the network intensity Si at the corresponding time through the controller, and stores it as a data set {(S1, d1), (S2, d2),..., (Sn, dn)}; the delay data of the same or similar network intensity is averaged (such as grouping according to the signal intensity interval, and calculating the average delay of each group).

[0077] The current network intensity Scurr is obtained, and the average delay d corresponding to the closest signal interval in the historical data is searched - ; the target time length Ttarget = d - + δ (δ is a preset safety margin to prevent accidental peak delay).

[0078] The threshold value is dynamically adjusted based on the historical performance of the actual network environment, which is more accurate than the fixed strategy or simple intensity classification, and reduces the probability of misjudgment; through historical average filtering of accidental abnormal values, the non-stable network environment (such as signal intensity in a mobile scene) is adapted, and it is ensured that the threshold setting conforms to the actual network capability.

[0079] In some embodiments, the controller is in communication connection with a plurality of robots; the delay time corresponding to the second control instruction is obtained according to the first difference and the second difference, so as to determine whether to control the robot to execute the second control instruction according to the delay time, including: obtaining the delay time of the second control instruction corresponding to each robot according to the first difference and the second difference corresponding to each robot; determining whether to control each robot to execute the second control instruction according to the delay time corresponding to each robot; and / or, determining whether to control the plurality of robots to execute the second control instruction according to the delay time corresponding to the plurality of robots.

[0080] When the controller is in communication with a plurality of robots at the same time, the delay detection process is independently executed for each robot: an independent time stamp pair (first / second time stamp, third / fourth time stamp) is maintained for each robot; the delay time di of each robot is calculated respectively, and whether to execute the instruction is determined according to di of each robot; This embodiment supports two decision-making modes: independent decision-making: whether the instruction of each robot is executed is only determined by the delay of the robot itself; cooperative decision-making: when a plurality of robots need to be executed synchronously (such as formation task), the robot with the maximum delay is taken as the reference, and the overall execution time is adjusted (or the instruction of the robot with the delay exceeding the limit is discarded, to avoid coordination disorder).

[0081] Multi-device management allocates a unique identifier (such as a device ID) for each robot through the controller, and maintains an independent state table (stores the historical time stamp, frequency compensation factor, etc. of the robot); when sending an instruction, the target robot ID is carried in the data packet, so that the time stamp and the device are one-to-one corresponding.

[0082] The decision logic includes an independent mode and a collaborative mode. Independent mode: For robot A, execute if dA < Ttarget; for robot B, execute if dB < Ttarget, without mutual influence. Collaborative mode: Calculate the latency of all robots. If the latency of any robot exceeds the limit, cancel the current collaborative instruction as a whole (or only execute the robots with qualified latency).

[0083] This embodiment is suitable for multi-device control scenarios such as industrial automation and robot formation, avoiding cross-interference of clock differences and communication delays of multiple devices; it supports both independent latency control of a single robot and global decision-making for multi-robot collaborative tasks, meeting the requirements of complex systems and improving the overall control accuracy and reliability.

[0084] In some embodiments, as Figure 2 shown, the controller and the robot respectively adopt different time coordinate systems. The controller (such as a mobile phone APP) adopts the unix time of the mobile phone system, and the robot adopts the uptime (the duration of running after startup). When the controller sends a control instruction, it carries its sending timestamp A_t1 in the control instruction. After the robot receives it, it records its current running duration B_t1. After a time interval of △T, when the controller sends another control instruction, it carries the sending timestamp A_t2 in the control instruction. After the robot receives it, it records its current running duration B_t2. Since A_t2 is increased by △T based on A_t1, and B_t2 is also increased by △T based on B_t1, the D1 obtained by A_t1 - B_t1 is equal to the D2 obtained by A_t2 - B_t2. This difference (D1, D2) is the difference between the two time coordinate systems, and this value is a theoretically constant value, recorded as D. If the second instruction is delayed, as shown by the delayed instruction of the dotted line in the figure, it will surely arrive at the robot end later than the theoretical expectation, and the delay time is Figure 2 the dT shown. So when the robot end receives the second instruction, subtract its own local current running time B_t3 from the timestamp A_t2 of the corresponding mobile phone APP of the controller carried in the control message to get Dd, and then subtract Dd from the theoretical difference time D to calculate the latency dT of this instruction. As long as the latency (dT) of the message is obtained, it can be judged whether this instruction belongs to an intolerable delay according to the system design index. Then corresponding processing is done according to the judgment result. The controller can be a mobile phone remote control APP or a dedicated remote controller, and the controlled end can be a robot, a lawn mower, a remote control car, a remote control plane and other controlled devices; at the same time, the time axes of the controller and the robot can be exchanged, or both can be uptime or both can be unix time or others.

[0085] Please refer to Figure 3 , Figure 3is a schematic flowchart of another delay time detection method provided by an embodiment of the present application. The delay time detection method can be implemented by a robot. It can also be implemented by devices such as a lawn mower, a remote control car, a remote control airplane, and the like.

[0086] To solve the above problems, please refer to Figure 1 . Specifically, as shown in Figure 1 , the provided delay time detection method includes steps S201 to S207. Details are as follows: Step S201. Obtain the first control instruction sent by the controller and the first timestamp corresponding to the first control instruction in the preset controller time coordinate system.

[0087] Specifically, the robot receives the first control instruction (such as a start, steering, or the like operation instruction) sent by the controller, and parses the first timestamp generated by the controller in its local time coordinate system from the instruction data packet. The time coordinate system of the controller can be a system clock (such as a system time of a mobile phone or an industrial computer) or a custom counter (such as a self-incrementing timing unit based on processor cycles), and the robot does not need to be time-synchronized with the controller, and only needs to extract the timestamp for subsequent calculation.

[0088] The robot receives the instruction data packet through a communication module (such as Wi-Fi, Bluetooth, or a serial port), parses a fixed field (such as a timestamp1 field defined in the protocol) to obtain the first timestamp; supports multiple timestamp formats, such as Unix millisecond timestamp, and self-incrementing counter value (such as “100th instruction”). Whether the controller uses a system clock or a counter, the robot only needs to extract the corresponding field according to the protocol, and does not need to care about the specific generation mechanism of the timestamp.

[0089] Step does not need to preset the time synchronization protocol of the controller, directly extracts the timestamp from the instruction, and adapts to various controllers (from high-performance devices to minimalist embedded controllers); does not need a complex time synchronization module, reduces the hardware and software overhead of the robot side, and is especially suitable for low-computing-power and low-power-consumption devices (such as a lawn mower and a remote control toy).

[0090] Step S202. In the preset robot time coordinate system, obtain the second timestamp when the first control instruction is received.

[0091] Specifically, the robot records the second timestamp in its local time coordinate system at the moment when the first control instruction is received. The time coordinate system of the robot is independent of the controller, and can be implemented based on a system clock (such as an embedded system with an RTC) or a custom counter (such as a timer count value of an MCU or a cumulative count of received instructions), and does not need to be aligned with the controller.

[0092] Local time collection If the robot has a real-time clock (RTC), directly read the current time (e.g. millisecond-level timestamp); if it is a low-cost device (e.g. single-chip microcomputer without RTC), use the on-chip timer (e.g. TIM module count value of STM32) or receive counter (count up by 1 for each received instruction, estimate the time by combining the fixed receiving period).

[0093] The trigger mechanism includes triggering the timestamp collection in the communication receiving interrupt function or callback function, ensuring strict alignment with the instruction receiving time.

[0094] The robot only relies on local timing, avoiding time synchronization errors caused by network delay, especially suitable for unstable wireless communication scenarios (such as signal fluctuation environment of remote control aircraft); supports from high-end robots (with high-precision RTC) to minimalist devices (only using counter timing), reducing dependence on hardware.

[0095] Step S203. Obtain the first difference value corresponding to the first timestamp and the second timestamp.

[0096] Specifically, the first timestamp (controller time) obtained in step S201 is subtracted from the second timestamp (robot time) recorded in step S202 to obtain ΔT1 = second timestamp - first timestamp. The difference value includes two parts: the transmission delay of the instruction from the controller to the robot (the time of the signal in the channel); the clock deviation between the controller and the robot (such as the fixed time difference caused by the unsynchronized clocks of the two, or the cumulative deviation caused by the frequency difference of the crystal oscillator).

[0097] The difference calculation logic directly performs numerical subtraction without the need for unified time units (such as controller using counter value, robot using timer count value, difference being the count value difference of the two); if the timestamp is absolute time (such as millisecond-level timestamp), the difference is absolute time difference (such as 50ms); if it is relative count (such as the controller sends the 10th instruction, and the robot receives it when the counter is 20), the difference is relative count value (such as 10 count periods).

[0098] Data storage stores ΔT1 in the local cache of the robot, which is used for subsequent comparison with the second difference value. Through the time difference of a single transmission, the mixed error including delay and deviation is quantified, providing basic data for subsequent double measurement to separate errors; allows the controller and the robot to use different timing units (such as the controller using milliseconds and the robot using microseconds), and the difference calculation only relies on numerical logic, simplifying cross-platform calculation.

[0099] Step S204. Obtain the second control instruction sent by the controller and the third timestamp corresponding to the second control instruction in the preset controller time coordinate system.

[0100] Specifically, the robot receives the second control instruction sent by the controller (which can be of the same type or a different type as the first instruction), and parses the third timestamp generated by the controller in its local time coordinate system from the instruction. This step is consistent with S201 logic, ensuring that the timestamps of the two instructions are generated in the controller's independent clock, forming a time pair for symmetric measurement.

[0101] The implementation of instruction and timestamp extraction is exactly the same as S201, including packet parsing, fixed field extraction (such as timestamp2 field); the second instruction needs to form a "pair" in time with the first instruction to ensure the continuity of the two sending timestamps at the controller end (such as not sending at the same time, with a certain time interval). Anti-interference design: if a data packet error occurs during reception, discard the instruction and wait for retransmission to ensure the validity of the third timestamp.

[0102] By obtaining the timestamps of the two instructions, a two-way measurement model of "controller sending time-robot receiving time" is constructed to provide necessary data pairs for separating delay and bias; filtering of error packets ensures that subsequent calculations are based on valid timestamps, avoiding error calculation errors caused by abnormal data.

[0103] Step S205. In a predetermined robot time coordinate system, obtain a fourth timestamp when the second control instruction is received.

[0104] Specifically, the robot records the fourth timestamp in its local time coordinate system at the moment it receives the second control instruction. This step is consistent with S202 logic, ensuring that the two receiving timestamps are generated in the robot's local clock, forming a time sequence at the robot end corresponding to the two sending timestamps at the controller end.

[0105] The implementation of the timestamp collection mechanism is exactly the same as S202 (such as the same counter or real-time clock source), ensuring consistency in the two collection mechanisms; the collection is triggered in the interrupt or callback function when the second instruction is received, ensuring that the timestamp is strictly aligned with the receiving time.

[0106] Data association is achieved by binding the fourth timestamp with the third timestamp (the time the controller sent the second instruction), forming a second pair of "sending-receiving" time groups.

[0107] By recording the two receiving timestamps, a time axis is constructed at the robot end, corresponding to the two sending time axes at the controller end, providing symmetric time samples for subsequent error separation; by triggering collection through interrupts, the real-time nature of timestamp recording is ensured, avoiding collection delays caused by software task scheduling and improving measurement accuracy.

[0108] Step S206. Obtain a second difference value corresponding to the third timestamp and the fourth timestamp.

[0109] Specifically, the third timestamp (controller second sending time) obtained in step S204 is subtracted from the fourth timestamp (robot second receiving time) recorded in step S205 to obtain ΔT2 = fourth timestamp - third timestamp. Similar to ΔT1, ΔT2 contains the transmission delay of the second transmission and the clock bias (assuming that the clock bias is stable in a short time, such as crystal oscillator drift, which can be regarded as a fixed offset).

[0110] The implementation of the difference calculation logic is exactly the same as S203, and direct numerical subtraction is performed to support absolute time difference or relative count value difference; the numerical difference between ΔT1 and ΔT2 provides bidirectional data for subsequent delay calculation.

[0111] The error characteristic assumption assumes that the one-way delay of the two transmissions is the same (the delay can be regarded as symmetric in a short time in wireless communication), and the clock bias is constant (ΔT1 = d + θ, ΔT2 = d - θ, where d is the one-way delay, and θ is the clock bias).

[0112] The time difference between the two independent transmissions is used to construct an equation set containing the same clock bias but symmetric transmission delay, which provides conditions for mathematical elimination of bias; by comparing ΔT1 and ΔT2, the change of transmission delay is monitored in real time (for example, ΔT1 = 50 ms, ΔT2 = 45 ms, indicating that the delay is slightly reduced), which provides data for delay trend analysis.

[0113] Step S207. Obtain the delay time corresponding to the second control instruction according to the first difference value and the second difference value, to determine whether to execute the second control instruction according to the delay time.

[0114] Specifically, based on the assumptions of "symmetric two-way transmission delay" and "constant clock bias", the real transmission delay of the second control instruction is calculated by the following formula: d = (ΔT1 + ΔT2) / 2; wherein the average of ΔT1 and ΔT2 can offset the clock bias θ (ΔT1 + ΔT2 = 2d), to obtain d containing only the transmission delay. The robot determines whether to execute the second instruction according to whether d exceeds a preset threshold (such as d less than 50 ms, then execute, otherwise discard as expired instruction).

[0115] The average value is calculated by directly substituting the formula, without the need for complex clock synchronization algorithm; supports integer operation (such as average of count value difference), adapts to low computing power devices. The preset delay threshold (such as set according to the motion characteristics of the device, the lawn mower allows a slightly larger delay, and the remote control airplane requires a low delay); if d < threshold → execute the instruction; if d ≥ threshold → discard the instruction (a retransmission mechanism can be triggered).

[0116] The transmission delay and clock deviation are separated by double measurement, solving the delay misjudgment problem caused by the unsynchronized clocks between devices in the traditional scheme, especially suitable for low-cost devices without RTC; the validity of the instruction is dynamically judged based on the real delay, avoiding the robot performing outdated operations (such as the remote control car receiving expired steering instructions, which may cause a collision); only basic addition, subtraction and average calculation are required, without complex protocols or hardware support, perfectly adapting to scenarios such as lawn mowers and remote control toys that are sensitive to cost and power consumption.

[0117] Steps S201-S207 passively receive two instructions and record local time stamps, use the two sending time stamps at the controller end to build a symmetric measurement model, eliminate the clock deviation by mathematical averaging without actively synchronizing the time, and separate the real transmission delay. Only time stamp recording and simple calculation are required, without the need to maintain a complex time synchronization module; complex scenarios such as wireless communication delay fluctuations and device clock accuracy differences are supported, and random errors are naturally suppressed by double measurement; high-precision delay detection is achieved on low-cost hardware (such as a lawn mower controlled by a single-chip microcomputer), providing key technical support for real-time control.

[0118] In some embodiments, before obtaining the delay time corresponding to the second control instruction according to the first difference value and the second difference value, the method further comprises: obtaining a third difference value corresponding to the first time stamp and a third time stamp; obtaining a fourth difference value corresponding to the second time stamp and a fourth time stamp; obtaining a fifth difference value corresponding to the third difference value and the fourth difference value; if the fifth difference value is greater than a preset threshold, determining that the controller time coordinate system is abnormal, and re-obtaining the first control instruction sent by the controller.

[0119] Before calculating the delay time of the second control instruction, the time stamps sent by the controller are verified for abnormalities (such as time rollback or jump) through three difference value calculations (third difference value, fourth difference value, fifth difference value), to avoid delay calculation errors caused by controller clock abnormalities (such as time stamp resetting after system crash). The specific logic is as follows: the third difference value is the interval between the two sending time stamps of the controller (third time stamp - first time stamp, reflecting the time elapsed at the controller end); the fourth difference value is the interval between the two receiving time stamps of the robot (fourth time stamp - second time stamp, reflecting the time elapsed at the robot end); the fifth difference value is the absolute difference between the third difference value and the fourth difference value, used to judge whether the time elapsed of the two is as expected (under normal circumstances, the difference between the two should be close to zero, as the delay difference between the two transmissions is small). If the fifth difference value exceeds a preset threshold (such as a large difference between the controller and the robot time elapsed), it is determined that the controller time coordinate system is abnormal (such as time stamp disorder), and the first control instruction is forcibly re-obtained to reset the measurement reference.

[0120] The difference calculation step includes: a third difference AT_ctrl = third timestamp - first timestamp (the time interval of two sending instructions at the controller end, which should be positive, if it is negative, it means time rollback, and it is directly determined as an exception); a fourth difference AT_robot = fourth timestamp - second timestamp (the time interval of two receiving instructions at the robot end, which must be positive, because the receiving sequence is fixed); and a fifth difference AT_diff = |AT_ctrl - AT_robot| (taking the absolute value to eliminate the sign influence).

[0121] The exception determination logic includes: a preset threshold T_thd (such as being set according to the communication frequency and the device performance, for example, 100 ms or 100 counting periods); if AT_diff > T_thd, an exception processing is triggered: the current two instructions are discarded, and a request is sent to let the controller re-send the first instruction (or wait for the next valid instruction as the new first instruction). The controller timestamp needs to be monotonically increasing (such as an incremental counter or a system clock, and a time source that can be rolled back is prohibited); the robot end stores the latest two received controller timestamps and local timestamps, which are used for real-time calculation of the difference.

[0122] The delay calculation error caused by the abnormality of the controller timestamp (such as the time stamp being reset to zero due to software reset) is avoided, for example, if the time stamp of the second instruction sent by the controller is less than that of the first instruction, the traditional method will miscount the negative delay, and the embodiment directly identifies the exception through the symbol detection of AT_ctrl; by re-acquiring the first instruction to reset the measurement reference, it is ensured that the subsequent delay calculation is based on a valid time pair, which is especially suitable for long-time running scenarios (such as a mower working for several hours to prevent the error caused by the accumulation of controller clock drift); the “soft exception” of the controller timestamp (such as short-time jump caused by unsynchronized system clock) is compatible, the threshold is used to filter unexpected data, and the system reliability is improved.

[0123] In some embodiments, the delay time corresponding to the second control instruction is obtained according to the first difference and the second difference, including: obtaining a third difference corresponding to the first timestamp and the third timestamp; obtaining a fourth difference corresponding to the second timestamp and the fourth timestamp; obtaining a clock frequency difference compensation factor corresponding to the controller and the robot according to the third difference and the fourth difference; and obtaining the delay time corresponding to the second control instruction according to the clock frequency difference compensation factor, the first difference and the second difference.

[0124] For the scenario that the controller and the robot have different clock frequencies (e.g., the precision of the crystal oscillator of the controller is different from that of the robot, resulting in different growth rates of the time stamps), by calculating the ratio of the time elapsed at the controller (the third difference value) and the time elapsed at the robot (the fourth difference value), a clock frequency difference compensation factor is obtained, the assumption that the clock bias is constant in the traditional method is corrected, and the delay calculation accuracy is improved. The third difference value ΔT_ctrl = third time stamp - first time stamp (the time interval between two sending times of the controller, in units of controller clock cycles); the fourth difference value ΔT_robot = fourth time stamp - second time stamp (the time interval between two receiving times of the robot, in units of robot clock cycles); the compensation factor k = ΔT_robot / ΔT_ctrl (reflecting the ratio of the clock frequencies of the two, if the controller clock is faster, k < 1; if the robot clock is faster, k > 1); the traditional formula assumes that ΔT1 = d + θ and ΔT2 = d - θ, but actually due to the frequency difference, θ (the clock bias) may change over time, and the controller time stamp needs to be converted into an equivalent robot time through k before calculating the delay.

[0125] The compensation factor calculation is performed by directly calculating the time difference (after unit conversion, such as conversion to milliseconds) if the controller and robot time stamps are absolute time (such as millisecond-level time stamps); if they are relative counters (such as the controller using instruction counting and the robot using timer counting values), the counter difference needs to be converted into equivalent time (such as the controller counting +1 for each instruction sent, and the robot timer frequency being 1 kHz, so that the counting value difference corresponds to milliseconds).

[0126] The compensation factor formula is k = ΔT_robot / ΔT_ctrl; the delay correction calculation is performed by converting the first time stamp into an equivalent robot time: t1' = t1 x k (assuming that the conversion relationship between the controller time unit and the robot time unit is represented by k); the first difference after correction: ΔT1' = T2 - t1' (T2 is the time stamp of the robot receiving the first instruction); similarly, the second difference after correction: ΔT2' = T4 - t3' (t3 is the third time stamp of the controller, t3' = t3 x k); the final delay: d = 2ΔT1' + ΔT2'. If k is close to 1 (such as high-precision crystal oscillator, the frequency difference can be ignored), it can be simplified to the traditional average calculation; the value of k is updated in real time (recomputed each time new two instructions are obtained), which adapts to dynamic frequency changes (such as crystal oscillator frequency drift caused by changes in robot battery voltage).

[0127] The embodiment solves the problem that the "clock frequency consistency" assumption in the traditional method does not hold, for example, when the controller uses a 1kHz clock and the robot uses a 2kHz clock, the delay calculation deviation is avoided by k=2 compensation; the controller and the robot use completely different timing systems (such as the controller uses a software counter and the robot uses a hardware timer), and the time measurement is unified through a compensation factor; it is especially suitable for long-running equipment (such as industrial robots working for several days), dynamically compensating for clock frequency differences, and avoiding accumulated errors caused by temperature changes.

[0128] In some embodiments, the robot is in communication connection with a plurality of controllers, and the robot stores system time difference corresponding to each controller and controller identification information; determining whether to execute the second control instruction according to the delay time comprises: obtaining the controller identification information corresponding to the delay time; obtaining the system time difference corresponding to the controller according to the controller identification information; obtaining the delay time of the second control instruction corresponding to each controller according to the first difference value and the second difference value corresponding to each controller; and determining whether to execute the second control instruction according to the delay time and the system time difference.

[0129] When the robot is connected to multiple controllers at the same time (such as multi-user remote control, master-slave controller switching), the time coordinate system of each controller is independent and there may be a fixed system time difference (such as different initial times of different controllers). The robot needs to store the system time difference (initial offset of the time of the controller and the robot) and the controller identification information (such as device ID, MAC address) for each controller, and match the corresponding time difference according to the identification when processing the instruction, to realize differentiated delay calculation and execution decision.

[0130] The information storage structure establishes a controller information table, and the fields include: controller identification (ID): such as Bluetooth device MAC address, Wi-Fi device IP+port; system time difference (θ): initial time deviation calculated when first communicating (such as θ = first receiving time of the robot - first sending time of the controller); historical delay record: used for dynamically updating threshold or compensation factor.

[0131] When receiving the instruction: parse the controller ID in the instruction, query the corresponding system time difference θ from the information table; delay calculation: for each controller i, calculate the delay d_i = (ΔT1_i + ΔT2_i) / 2 according to its exclusive ΔT1_i and ΔT2_i; combine the system time difference θ_i and the delay d_i of the controller, judge whether the instruction is newly generated: the effective time of the robot corresponding to the instruction sending time (controller time t_ctrl) is [t_ctrl + θ_i - d_i, t_ctrl + θ_i + d_i]; if the current robot time is within the effective window → execute the instruction; otherwise → discard (considering the bidirectionality of transmission delay). When first receiving the instruction of a certain controller, calculate θ = receiving time - sending time (assuming that the first delay can be ignored, or subsequent optimization through multiple measurements).

[0132] Solve the instruction confusion problem when the robot simultaneously responds to multiple controllers, for example, the lawn mower supports local remote controller and mobile phone APP dual control, both of which are time independent and are distinguished by identification; different controllers can set different delay thresholds (such as low delay for remote controllers and slightly higher delay for APP), and precise decision-making is achieved by combining system time difference; without forcing multiple controllers to synchronize with the robot time, each controller independently maintains the time difference, reducing system complexity, especially suitable for distributed control scenarios (such as each unmanned aerial vehicle connecting different ground stations in a cluster of unmanned aerial vehicles).

[0133] Please refer to Figure 4 , Figure 4 is a structural schematic diagram of a first delay time detection device 300 provided by the embodiments of the present application. The first delay time detection device 300 is used to execute the steps of the delay time detection method shown in each of the above embodiments. The first delay time detection device 300 can be a single server or a server cluster, or the first delay time detection device 300 can be a terminal, which can be a handheld terminal, a notebook computer, a wearable device, or a robot, etc.

[0134] As shown in Figure 4 , the first delay time detection device 300 comprises: A first acquisition unit 301 is configured to, when a first control instruction is generated and sent to a preset robot, acquire a first timestamp corresponding to the first control instruction in a preset controller time coordinate system; A second acquisition unit 302 is configured to acquire a second timestamp corresponding to the first control instruction in a preset robot time coordinate system when the robot receives the first control instruction; A third acquisition unit 303 is configured to acquire a first difference value corresponding to the first timestamp and the second timestamp; The fourth acquisition unit 304 is configured to acquire a third timestamp corresponding to the second control instruction in the controller time coordinate system when the second control instruction is generated and sent to the robot. The fifth acquisition unit 305 is configured to acquire a fourth timestamp corresponding to the robot in the robot time coordinate system when the second control instruction is received. The sixth acquisition unit 306 is configured to acquire a second difference value corresponding to the third timestamp and the fourth timestamp. The first execution unit 307 is configured to acquire a delay time corresponding to the second control instruction according to the first difference value and the second difference value, and determine whether to control the robot to execute the second control instruction according to the delay time.

[0135] It should be noted that, for the convenience and brevity of description, the specific working process of the delay time detection device and each module described above can refer to the corresponding process in the delay time detection method embodiments described above, which will not be described here.

[0136] The delay time detection method described above can be implemented in the form of a computer program, which can run on the device as shown in the figure. Figure 4

[0137] Please refer to Figure 5 , Figure 5 is a structural schematic block diagram of a controller provided by the embodiment of the present application. The controller includes a processor, a memory and a network interface connected through a device bus, wherein the memory can include a storage medium and an internal memory.

[0138] The storage medium can store an operating device and a computer program. The computer program includes program instructions, which, when executed, can cause the processor to execute any kind of delay time detection method.

[0139] The processor is configured to provide computing and control capabilities to support the operation of the entire controller.

[0140] The internal memory provides an environment for the operation of the computer program in the non-volatile storage medium, which, when executed by the processor, can cause the processor to execute any kind of delay time detection method.

[0141] The network interface is configured to perform network communication, such as sending assigned tasks, etc. Those skilled in the art can understand that, Figure 5 ​The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the terminal to which the scheme of the present application is applied. The specific controller can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0142] It should be understood that the processor can be a central processing unit (CPU), and the processor can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0143] In one embodiment, the processor is configured to run a computer program stored in the memory to perform the following steps: When the first control instruction is generated and sent to the preset robot, a first timestamp corresponding to the first control instruction in a preset controller time coordinate system is obtained; A second timestamp corresponding to the robot in a preset robot time coordinate system when the first control instruction is received is obtained; A first difference value corresponding to the first timestamp and the second timestamp is obtained; When the second control instruction is generated and sent to the robot, a third timestamp corresponding to the second control instruction in the controller time coordinate system is obtained; A fourth timestamp corresponding to the robot in the robot time coordinate system when the second control instruction is received is obtained; A second difference value corresponding to the third timestamp and the fourth timestamp is obtained; According to the first difference value and the second difference value, a delay time corresponding to the second control instruction is obtained, so as to determine whether to control the robot to execute the second control instruction according to the delay time.

[0144] Please refer to Figure 6 as shown, Figure 6FIG. 4 is a structural schematic diagram of a second delay time detection device 400 provided by an embodiment of the present application. The second delay time detection device 400 is used to execute the steps of the delay time detection method shown in each of the above embodiments. The second delay time detection device 400 can be a single server or a server cluster, or the second delay time detection device 400 can be a terminal, which can be a handheld terminal, a notebook computer, a wearable device, a robot, or the like.

[0145] As shown in Figure 6 , the second delay time detection device 400 includes: a seventh acquisition unit 401 configured to acquire a first control instruction sent by a controller and a first timestamp corresponding to the first control instruction in a preset controller time coordinate system; an eighth acquisition unit 402 configured to acquire a second timestamp in a preset robot time coordinate system when the first control instruction is received; a difference acquisition unit 403 configured to acquire a first difference corresponding to the first timestamp and the second timestamp; a time acquisition unit 404 configured to acquire a second control instruction sent by the controller and a third timestamp corresponding to the second control instruction in the preset controller time coordinate system; a ninth acquisition unit 405 configured to acquire a fourth timestamp in the preset robot time coordinate system when the second control instruction is received; a tenth acquisition unit 406 configured to acquire a second difference corresponding to the third timestamp and the fourth timestamp; a second execution unit 407 configured to acquire a delay time corresponding to the second control instruction according to the first difference and the second difference, so as to determine whether to execute the second control instruction according to the delay time.

[0146] It should be noted that, for the convenience and brevity of description, the specific working processes of the delay time detection device and each module described above can refer to the corresponding processes in the delay time detection method embodiments described above, and will not be described here.

[0147] The delay time detection method described above can be implemented in the form of a computer program, which can run on the device as shown in Figure 6 .

[0148] Please refer to Figure 7 , Figure 7 is a structural schematic block diagram of a robot provided by an embodiment of the present application. The robot includes a processor, a memory and a network interface connected through a device bus, wherein the memory can include a storage medium and an internal memory.

[0149] The storage medium can store an operating device and a computer program. The computer program includes program instructions which, when executed, can cause the processor to perform any one of the delay time detection methods.

[0150] The processor is configured to provide computing and control capabilities to support the operation of the entire robot.

[0151] The internal memory provides an environment for the computer program in the non-volatile storage medium to run, which, when executed by the processor, can cause the processor to perform any one of the delay time detection methods.

[0152] The network interface is configured to perform network communication, such as sending assigned tasks, etc. Those skilled in the art can understand that, Figure 7 The structure shown in the figure is only a block diagram of part of the structure related to the scheme of the present application, and does not constitute a limitation on the terminal to which the scheme of the present application is applied. The specific robot can include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0153] It should be understood that the processor can be a central processing unit (CPU), and the processor can also be other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor.

[0154] In one embodiment, the processor is configured to run a computer program stored in the memory to perform the following steps: obtain a first control instruction sent by a controller and a first timestamp corresponding to the first control instruction in a preset controller time coordinate system; obtain a second timestamp in a preset robot time coordinate system when the first control instruction is received; obtain a first difference value corresponding to the first timestamp and the second timestamp; obtain a second control instruction sent by a controller and a third timestamp corresponding to the second control instruction in a preset controller time coordinate system; obtain a fourth timestamp in a preset robot time coordinate system when the second control instruction is received; obtaining a second difference value corresponding to the third timestamp and the fourth timestamp; obtaining a delay time corresponding to the second control instruction according to the first difference value and the second difference value, to determine whether to execute the second control instruction according to the delay time.

[0155] The application further provides a computer readable storage medium, which stores a computer program. When the computer program is executed by a processor, the processor implements the steps of the delay time detection method provided by any of the embodiments of the application.

[0156] The computer readable storage medium can be an internal storage unit of the controller, such as a hard disk or a memory of the controller. The computer readable storage medium can also be an external storage device of the controller, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc.

[0157] The above merely provides a specific implementation of the application, but the protection scope of the application is not limited to this. Any person skilled in the art can easily think of various equivalent modifications or replacements within the technical scope disclosed by the application, and these modifications or replacements should be covered by the protection scope of the application. Therefore, the protection scope of the application should be subject to the protection scope of the claims.

Claims

1. A delay time detection method, characterized in that, Applied to a controller; the method includes: When the first control command is generated and sent to the preset robot, the first timestamp corresponding to the first control command in the preset controller time coordinate system is obtained; Obtain the second timestamp corresponding to the robot in the preset robot time coordinate system when the robot receives the first control command; Obtain the first difference between the first timestamp and the second timestamp; When generating a second control command and sending it to the robot, the third timestamp corresponding to the second control command in the controller's time coordinate system is obtained; Obtain the fourth timestamp in the robot's time coordinate system corresponding to the robot receiving the second control command; Obtain the second difference between the third timestamp and the fourth timestamp; The delay time corresponding to the second control command is obtained based on the first difference and the second difference, so as to determine whether to control the robot to execute the second control command based on the delay time.

2. The method according to claim 1, characterized in that, Before obtaining the delay time corresponding to the second control command based on the first difference and the second difference, the method further includes: Obtain the third difference between the first timestamp and the third timestamp; Obtain the fourth difference between the second timestamp and the fourth timestamp; Obtain the fifth difference corresponding to the third difference and the fourth difference; If the fifth difference is greater than a preset threshold, it is determined that the robot's time coordinate system is abnormal, and the first control command is regenerated and sent to the robot.

3. The method according to claim 1, characterized in that, The step of obtaining the delay time corresponding to the second control command based on the first difference and the second difference includes: Obtain the third difference between the first timestamp and the third timestamp; Obtain the fourth difference between the second timestamp and the fourth timestamp; The clock frequency difference compensation factor between the controller and the robot is based on the third and fourth differences; The delay time corresponding to the second control command is obtained based on the clock frequency difference compensation factor, the first difference, and the second difference.

4. The method according to claim 1, characterized in that, The step of determining whether to control the robot to execute the second control command based on the delay time includes: If the delay time is less than the preset target duration, the robot is controlled to execute the second control command.

5. The method according to claim 4, characterized in that, Before controlling the robot to execute the second control command if the delay time is less than a preset target duration, the method further includes: Obtain the instruction type corresponding to the second control instruction; The urgency level of the second control instruction is determined based on the instruction type; The target duration corresponding to the second control command is determined based on the level of urgency.

6. The method according to claim 4, characterized in that, Before controlling the robot to execute the second control command if the delay time is less than a preset target duration, the method further includes: Obtain the current network strength information corresponding to the time the second control command was sent; The target duration is adjusted based on the current network strength information.

7. The method according to claim 6, characterized in that, The step of adjusting the target duration based on the current network strength information includes: Acquire multiple historical command delay information corresponding to the controller and the robot; the historical command delay information includes the historical command transmission delay duration and the corresponding historical network strength information; The current network strength information is matched with multiple historical network strength information to obtain the historical instruction transmission delay duration corresponding to the current network strength information; The target duration is adjusted based on the historical instruction transmission delay duration.

8. The method according to claim 1, characterized in that, The controller is communicatively connected to multiple robots; the step of obtaining the delay time corresponding to the second control command based on the first difference and the second difference, and determining whether to control the robot to execute the second control command based on the delay time, includes: Based on the first difference and the second difference corresponding to each robot, the delay time of the second control command corresponding to each robot is obtained; Determine whether to control each robot to execute the second control instruction based on the delay time corresponding to each robot; and / or determine whether to control multiple robots to execute the second control instruction based on the delay time corresponding to multiple robots.

9. A method for detecting delay time, characterized in that, Applied to robots; the method includes: Obtain the first control command sent by the controller and the first timestamp corresponding to the first control command in the preset controller time coordinate system; In the preset robot time coordinate system, obtain the second timestamp when the first control command is received; Obtain the first difference between the first timestamp and the second timestamp; Obtain the second control command sent by the controller and the third timestamp corresponding to the second control command in the preset controller time coordinate system; In the preset robot time coordinate system, obtain the fourth timestamp when the second control command is received; Obtain the second difference between the third timestamp and the fourth timestamp; The delay time corresponding to the second control instruction is obtained based on the first difference and the second difference, so as to determine whether to execute the second control instruction based on the delay time.

10. The method according to claim 9, characterized in that, Before obtaining the delay time corresponding to the second control command based on the first difference and the second difference, the method further includes: Obtain the third difference between the first timestamp and the third timestamp; Obtain the fourth difference between the second timestamp and the fourth timestamp; Obtain the fifth difference corresponding to the third difference and the fourth difference; If the fifth difference is greater than a preset threshold, it is determined that the controller's time coordinate system is abnormal, and the first control command sent by the controller is re-acquired.

11. The method according to claim 9, characterized in that, The step of obtaining the delay time corresponding to the second control command based on the first difference and the second difference includes: Obtain the third difference between the first timestamp and the third timestamp; Obtain the fourth difference between the second timestamp and the fourth timestamp; The clock frequency difference compensation factor between the controller and the robot is based on the third and fourth differences; The delay time corresponding to the second control command is obtained based on the clock frequency difference compensation factor, the first difference, and the second difference.

12. The method according to claim 9, characterized in that, The robot is communicatively connected to multiple controllers, and the robot stores the system time difference and controller identification information corresponding to each controller; determining whether to execute the second control command based on the delay time includes: Obtain the controller identification information corresponding to the delay time; The system time difference corresponding to the controller is obtained based on the controller identification information; Based on the first difference and the second difference corresponding to each controller, the delay time of the second control command corresponding to each controller is obtained; Whether to execute the second control command is determined based on the delay time and the system time difference.

13. A controller, characterized in that, The method includes a memory and a processor, wherein the memory stores computer-readable instructions that, when executed by the processor, cause the processor to perform the steps of the method as described in any one of claims 1 to 8.

14. A robot, characterized in that, The method includes a memory and a processor, wherein the memory stores computer-readable instructions that, when executed by the processor, cause the processor to perform the steps of the method as described in any one of claims 9 to 12.

15. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer-readable instructions of which, when executed by the processor, cause one or more processors to perform the steps of the method as claimed in any one of claims 1 to 8, or to perform the steps of the method as claimed in any one of claims 9 to 12.

Images