Automatic unhooking and docking abnormality debugging method, device, equipment and medium

Abstract

The present disclosure discloses a method, apparatus, device, and medium for debugging abnormalities in automatic uncoupling and docking. The method comprises: obtaining the real-time status of a target object, wherein the target object is a target vehicle or a target hook, during the process of automatic uncoupling between a target vehicle and a target hook; determining a status verification result based on the real-time status and a target status corresponding to the real-time status; and, if the status verification result fails, sending a control instruction to the target object so that the target object updates its real-time status based on the control instruction and controls the target vehicle and the target hook to automatically uncouple. The present disclosure achieves the effect of timely determining abnormalities in the process of automatic uncoupling and docking and executing corresponding decision-making controls, thereby improving the robustness of automatic uncoupling and docking.

Description

Technical Field

[0001] The present disclosure relates to the field of artificial intelligence technology, and in particular to a method, device, equipment and medium for debugging automatic unhooking and docking anomalies. Background Art

[0002] With the development of unmanned tractors in the field of logistics and transportation, related automation technologies have also been increasingly widely used. As one of the main functions of the tractor, the automatic uncoupling device is responsible for the automated transfer of cargo trailers through functions such as automatic uncoupling, traction and hooking.

[0003] However, automatic uncoupling is affected by factors such as the tractor's control accuracy, hardware, and environmental road conditions. This makes precise docking difficult when performed automatically using the uncoupling mechanism. When docking fails, manual intervention is required to complete the docking, resulting in incomplete automation and a waste of labor resources. Summary of the Invention

[0004] In order to solve the above technical problems or at least partially solve the above technical problems, the embodiments of the present disclosure provide a debugging method, device, equipment and medium for automatic uncoupling and docking anomalies, so as to timely determine the abnormal conditions in the automatic uncoupling and docking process and perform corresponding decision control.

[0005] In a first aspect, an embodiment of the present disclosure provides a method for debugging an automatic unhooking docking anomaly, the method comprising:

[0006] During the process of automatically unhooking the target vehicle and the target hook, obtaining a real-time status of a target object, wherein the target object is the target vehicle or the target hook;

[0007] Determining a state verification result based on the real-time state and a target state corresponding to the real-time state;

[0008] When the status check result is a failure, a control instruction is sent to the target object, so that the target object updates the real-time status based on the control instruction, and controls the target vehicle and the target hook to automatically unhook.

[0009] In a second aspect, an embodiment of the present disclosure further provides a debugging device for automatically unhooking and docking abnormality, the device comprising:

[0010] A real-time status acquisition module is used to acquire the real-time status of a target object during the process of automatic uncoupling between the target vehicle and the target hook, wherein the target object is the target vehicle or the target hook;

[0011] a state verification result determination module, configured to determine a state verification result based on the real-time state and a target state corresponding to the real-time state;

[0012] The re-control module is used to send a control instruction to the target object when the status verification result fails, so that the target object updates the real-time status based on the control instruction and controls the target vehicle and the target hook to automatically unhook.

[0013] In a third aspect, an embodiment of the present disclosure further provides an electronic device, comprising: one or more processors; a storage device for storing one or more programs; and when the one or more programs are executed by the one or more processors, the one or more processors implement the automatic unhooking and docking anomaly debugging method as described above.

[0014] In a fourth aspect, an embodiment of the present disclosure further provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-mentioned method for debugging the automatic unhooking docking anomaly.

[0015] The embodiment of the present disclosure provides a debugging method for automatic uncoupling and docking anomalies. The method obtains the real-time status of the target object during the automatic uncoupling of the target vehicle and the target hook, and determines the status verification result based on the real-time status and the target status corresponding to the real-time status to judge whether the current target object correctly performs the automatic uncoupling and docking action. If the status verification result is failure, a control instruction is sent to the target object so that the target object updates the real-time status based on the control instruction, and controls the target vehicle and the target hook to automatically uncouple. This solves the problem of frequent manual intervention required when anomalies occur during the automatic uncoupling process, realizes the effect of timely determining the abnormal situation during the automatic uncoupling and docking process and executing corresponding decision-making control, and improves the robustness of the automatic uncoupling and docking. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The above and other features, advantages, and aspects of the various embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and that the originals and elements are not necessarily drawn to scale.

[0017] Figure 1 This is a flow chart of automatic uncoupling and docking in the prior art;

[0018] Figure 2 This is a flow chart of a method for debugging an abnormal automatic unhooking docking according to an embodiment of the present disclosure;

[0019] Figure 3This is a flow chart of another method for debugging an abnormal automatic unhooking connection in an embodiment of the present disclosure;

[0020] Figure 4 This is a flow chart of another method for debugging an abnormal automatic unhooking connection in an embodiment of the present disclosure;

[0021] Figure 5 This is a structural diagram of a debugging device for automatically unhooking and docking abnormality according to an embodiment of the present disclosure;

[0022] Figure 6 Schematic diagram of the structure of an electronic device in an embodiment of the present disclosure. DETAILED DESCRIPTION

[0023] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0024] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0025] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0026] Figure 1 This is a flow chart for automatic unhooking and docking in the prior art. Typically, the process begins by selecting a docking station through an interface device, starting the tractor, and heading to the preset docking station. Next, when the tractor arrives at the docking station, it slows down and reverses to dock the hook. If docking is successful, the tractor proceeds to the next station. If docking fails due to a gap in the hook or a stuck hook, manual intervention is performed to complete the docking, and the tractor proceeds to the next station. Therefore, the automatic unhooking and docking process involves significant manual intervention, resulting in a cumbersome process and a waste of manpower.

[0027] In response to the above problems, the embodiments of the present disclosure provide a method for debugging abnormalities in automatic uncoupling and docking, so as to timely determine abnormal situations in the automatic uncoupling and docking process and perform corresponding decision control, thereby reducing manual intervention and improving processing speed.

[0028] Figure 2This is a flow chart of a method for debugging an abnormal automatic unhooking and docking according to an embodiment of the present disclosure. The method can be executed by a device for debugging an abnormal automatic unhooking and docking, which can be implemented in software and / or hardware and can be configured in an electronic device. Figure 2 As shown, the method may specifically include the following steps:

[0029] S110 . During the process of automatically unhooking the target vehicle and the target hook, obtaining a real-time status of the target object.

[0030] The target object may be a control object during the automatic uncoupling process, and the target object may be a target vehicle or a target hook. The target vehicle may be a tractor, and the target hook may be a hook used to connect the tractor to the trailer. The real-time status may be an action status and / or a position status. The action status may include action direction, speed, etc., and the position status may include location information, etc.

[0031] Specifically, during the process of automatic uncoupling of the target vehicle and the target hook, the real-time status of the target object can be actively or passively obtained, such as the position, speed, moving direction, etc. of the target vehicle, or whether the target hook is rising or falling, the current position, etc., so as to facilitate subsequent judgment of whether the target object is operating normally.

[0032] It can be understood that active acquisition can be sending a status acquisition instruction to the target object, and the target object will feedback the real-time status when receiving the status acquisition instruction; passive acquisition can be the target object periodically or regularly feedback the real-time status without the need for instruction acquisition.

[0033] S120: Determine a status verification result based on the real-time status and a target status corresponding to the real-time status.

[0034] The target state can be the state that the target object should be in when executing the current instruction. The state verification result can be used to indicate whether the target object's real-time state matches the target state. The state verification result can be either success or failure. A failure state verification result can occur in a variety of situations, such as a state error, a state timeout, etc.

[0035] Specifically, when a target object performs an action by receiving a control instruction, its real-time state changes based on the control instruction. This control instruction has a corresponding desired state, namely the target state. Therefore, there is a correspondence between the real-time state and the target state. Therefore, a match between the real-time state and the target state can be determined to determine whether the control instruction was successfully executed. If the real-time state matches the target state, the state verification result can be determined to be a success; if the real-time state does not match the target state, the state verification result can be determined to be a failure.

[0036] S130: If the status check result is a failure, a control instruction is sent to the target object, so that the target object updates the real-time status based on the control instruction, and controls the target vehicle and the target hook to automatically unhook.

[0037] Among them, the control instruction can be an instruction to control the target object to perform a corresponding action. Optionally, the control instruction can be an instruction to repeat the current action, that is, the corresponding instruction when you want to reach the target state. The control instruction can also be an instruction to return to the initial state in the process of executing automatic uncoupling, that is, the instruction corresponding to the state when the automatic uncoupling process is started.

[0038] Specifically, when the status check result is a failure, it indicates that there is a problem with the current action or position of the target object, which does not match the target state. Therefore, it is necessary to send a control instruction to the target object so that the target object can act according to the control instruction when receiving the control instruction, that is, update the real-time status, and control the target vehicle and the target hook to continue to automatically unhook.

[0039] If the control command instructs the target object to repeat its current action, the target object can re-execute the current action upon receiving the control command to determine whether the problem still exists. If the control command instructs the target object to return to the initial state during the automatic uncoupling process, the target vehicle and target hook will return to the state before the automatic uncoupling, i.e., the initial state, upon receiving the control command, to execute the automatic uncoupling process from the beginning.

[0040] It should be noted that, when the status verification result is successful, the target vehicle and the target hook can be controlled to perform subsequent unhooking operations, and new status verification results can be continuously determined to debug automatic unhooking and docking anomalies.

[0041] Based on the above example, if the status check result fails, including the target status timeout, then the following method can be used to determine whether the target status timeout exists:

[0042] During the automatic uncoupling process between the target vehicle and the target hook, the preset running time and the actual running time to reach the target state are obtained; when the actual running time exceeds the preset running time, it is determined that the target state has timed out.

[0043] The preset runtime can be the maximum time to reach the target state, as set in advance. The actual runtime can be the actual time to reach the target state, as measured by timing. A target state timeout is a failure in the state check, indicating that the target object took too long to reach the target state.

[0044] Specifically, as the target object moves toward the target state, a timer can be used to determine the actual runtime required to reach the target state. The actual runtime can then be compared with a preset runtime required to reach the target state. If the actual runtime exceeds the preset runtime, it can be determined that the target state has timed out, i.e., the state verification result has failed. Subsequently, a control instruction can be sent to the target object, causing the target object to update its real-time state based on the control instruction, thereby controlling the target vehicle and target hook to automatically unhook. If the actual runtime does not exceed the preset runtime, it can be determined that the target state has not timed out, i.e., the state verification result is normal. Subsequently, the target vehicle and target hook can be controlled to perform a subsequent unhook operation.

[0045] It is understandable that the duration of the current target object's movement toward the target state can be determined by timing. When the duration reaches the preset running time, if the target object still has not reached the target state, it can also be determined that the target state has timed out.

[0046] Based on the above example, if the target state cannot be reached within the preset running time after repeated attempts, an exception report can be made. Specifically, it can be:

[0047] Determine the number of timeouts for the target state; if the number of timeouts is not less than the preset number, issue a stop command to the target hook and the target vehicle; generate a timeout message, and send the timeout message to the cloud server.

[0048] The timeout count is the number of target state timeouts, i.e., the number of times the target state timeout has occurred. The preset count may be a maximum preset timeout count. The stop command may be a command for stopping the target vehicle and the target hook. The timeout information may indicate that a timeout has occurred after the preset number of repetitions. The cloud server may be a remote server used to monitor the automatic unhooking process.

[0049] Specifically, if it is determined that the target state has timed out, the number of timeouts for the target state is further determined, and the timeout number is compared with a preset number. If the timeout number is less than the preset number, the step of sending a control instruction to the target object can be continued, so that the target object updates its real-time state based on the control instruction, and the target vehicle and the target hook are controlled to automatically unhook. If the timeout number is not less than the preset number, it indicates that the timeout number is too high and it is difficult to resolve by repeatedly executing the control instruction. Therefore, a stop command is issued to the target hook and the target vehicle to stop the target hook and the target vehicle to avoid danger, and a timeout message is generated and sent to the cloud server so that the staff on the cloud server side can process and intervene when the timeout message is received.

[0050] Based on the above example, if the real-time status includes a status check failure, then the control instruction can be sent to the target object in the following manner:

[0051] Send a control instruction to the target object corresponding to the state when the status check result is failure.

[0052] Specifically, in order to enable the target object to repeat the failed action, a control instruction corresponding to the state when the state check result is failure may be sent to the target object to control the target object to try again.

[0053] The debugging method for automatic uncoupling and docking anomalies provided by this embodiment obtains the real-time status of the target object during the process of automatic uncoupling between the target vehicle and the target hook, and determines the status verification result based on the real-time status and the target status corresponding to the real-time status to judge whether the current target object correctly performs the automatic uncoupling and docking action. If the status verification result is failure, a control instruction is sent to the target object so that the target object updates the real-time status based on the control instruction, and controls the target vehicle and the target hook to automatically uncouple. This solves the problem of frequent manual intervention required when anomalies occur during the automatic uncoupling process, realizes the effect of timely determining the abnormal situation during the automatic uncoupling and docking process and executing corresponding decision-making control, and improves the robustness of the automatic uncoupling and docking.

[0054] Figure 3 This is a flowchart of another method for debugging abnormal automatic uncoupling in the embodiment of the present disclosure. On the basis of the above embodiment, when the real-time state includes the initial state, a new scheme is added to determine whether the total time of automatic uncoupling has timed out, and to perform processing control in the case of timeout. For specific implementation methods, please refer to the detailed description of this technical solution. Among them, the explanation of the terms that are the same or corresponding to the above embodiments will not be repeated here. Figure 3 As shown, the method may specifically include the following steps:

[0055] S210: Acquire the real-time status of the target object during the process of the target vehicle and the target hook being automatically unhooked.

[0056] S220: Determine a status verification result based on the real-time status and the target status corresponding to the real-time status.

[0057] S230: If the status check result is a failure, a control instruction is sent to the target object, so that the target object updates the real-time status based on the control instruction, and controls the target vehicle and the target hook to automatically unhook.

[0058] S240: Obtain the total time duration for the target vehicle and the target hook to be automatically unhooked.

[0059] The total duration may be the duration from the start of automatic decoupling to the current moment.

[0060] Specifically, the timing starts when the target vehicle and the target hook start to automatically unhook, and the time up to the current moment is determined as the total time.

[0061] S250: If the total duration is greater than the preset total duration, a stop command is issued to the target hook and the target vehicle.

[0062] The preset total duration may be a pre-set maximum duration of the entire automatic decoupling process.

[0063] Specifically, if the total duration is greater than the preset total duration, it indicates that the current operation time of the automatic towing hook is too long, indicating that there are certain problems in the operation process. Therefore, a stop command can be issued to the target hook and the target vehicle to stop the target hook and the target vehicle from moving, so as to facilitate subsequent adjustment operations.

[0064] S260: Send a control instruction corresponding to the initial state to the target object, so that the target object updates the real-time state based on the control instruction, and controls the target vehicle and the target hook to automatically unhook.

[0065] The initial state may be a state planned for the target hook and the target vehicle when the automatic unhooking is initiated.

[0066] Specifically, a control instruction corresponding to the initial state can be sent to the target object to control the target vehicle and the target hook to return to the initial state when the automatic uncoupling planning was first performed. Then, after receiving the control instruction, the target vehicle and the target hook move and update the real-time state to control the target vehicle and the target hook to automatically uncouple again.

[0067] Optionally, during the automatic uncoupling process, each piece of hardware may be monitored and corresponding processing may be performed when a failure occurs, specifically including the following steps:

[0068] Step 1: During the process of automatic unhooking between the target vehicle and the target hook, data parameters of each hardware in the automatic unhooking device are obtained.

[0069] The automatic unhooking device is used to control the automatic unhooking of the target vehicle and the target hook. The hardware components of the automatic unhooking device can be components that constitute the automatic unhooking device, all of which can be key components, and are not specifically limited here. Data parameters can be parameters used to monitor hardware status, such as voltage, current, and temperature. The specific data parameters can be determined based on the specific hardware being monitored and can be obtained based on external sensors or sensors built into the hardware.

[0070] Specifically, during the automatic uncoupling process between the target vehicle and the target hook, data parameters of each hardware in the automatic uncoupling device are collected in real time based on sensors, so as to analyze and process whether there is any abnormality in the hardware and what kind of abnormality exists based on the data parameters.

[0071] Step 2: Determine the existence of abnormalities in each hardware based on the data parameters.

[0072] The abnormality existence situation may include abnormality and no abnormality.

[0073] Specifically, for each hardware item, the hardware item can be analyzed based on the corresponding data parameters of the hardware item and a predetermined analysis method, such as trend analysis, threshold analysis, etc., to determine whether the hardware item has an abnormality, i.e., the abnormality status. Based on this, the abnormality status of each hardware item can be obtained.

[0074] Step 3: If at least one abnormality exists, determine the hardware fault type based on the data parameters corresponding to the abnormal hardware.

[0075] Among them, the hardware failure type is unable to be repaired independently or can be repaired independently.

[0076] Specifically, if at least one abnormality exists, an analysis is performed based on the type of hardware and the data parameters corresponding to the hardware currently obtained to determine whether the fault can be repaired autonomously after waiting for a certain period of time without human intervention. If so, the hardware fault type is determined to be autonomously repairable; otherwise, the hardware fault type is determined to be non-autonomously repairable.

[0077] Step 4: If at least one hardware fault type is unrepairable, the hardware that cannot be repaired is powered off, hardware abnormality information is generated, and the hardware abnormality information is sent to the cloud server.

[0078] The hardware abnormality information may be used to indicate which hardware has an abnormality, and may also include data parameters corresponding to the abnormal hardware.

[0079] Specifically, if at least one hardware fault type is unable to be repaired autonomously, it indicates that this situation requires manual intervention. Therefore, in order to prevent the abnormal hardware from continuing to operate abnormally, the hardware that cannot be repaired autonomously can be powered off. Furthermore, hardware abnormality information can be generated based on the hardware that cannot be repaired autonomously, and the hardware abnormality information can be sent to the cloud server, so that the staff of the cloud server can analyze the hardware abnormality information when they receive it, and manually intervene to perform corresponding fault processing.

[0080] Optionally, after determining the type of hardware failure based on the data parameters corresponding to the abnormal hardware, you can also:

[0081] If the hardware fault types are all self-repairable, the fault repair results are determined and the hardware fault type and fault repair results are sent to the cloud server; if the fault repair result is successful, after the hardware fault, the target vehicle and the target hook are controlled to automatically unhook.

[0082] The fault repair result may include repair success or repair failure.

[0083] Specifically, if the hardware fault types are all self-repairable, you can wait for a preset time period to allow the hardware to repair itself, and after the preset time period, analyze the hardware again to determine whether the repair is successful, that is, determine the fault repair result, and then send the hardware fault type and fault repair result to the cloud server for recording and archiving. If the fault repair result is a successful repair, it means that the subsequent automatic uncoupling operation can be performed, that is, after the hardware failure, the target vehicle and the target hook are controlled to automatically uncouple. If the fault repair result is a repair failure, then after sending the hardware fault type and fault repair result to the cloud server, the staff on the cloud server side can manually intervene to repair the fault.

[0084] The debugging method for automatic uncoupling and docking anomaly provided in this embodiment obtains the total time of automatic uncoupling of the target vehicle and the target hook, and when the total time is greater than the preset total time, sends a stop command to the target hook and the target vehicle to avoid the danger caused by the docking anomaly. Then, a control instruction corresponding to the initial state is sent to the target object, so that the target object updates the real-time state based on the control instruction, and controls the target vehicle and the target hook to automatically uncouple. This solves the problem of time waste when repeated attempts still cannot solve the docking anomaly problem, realizes timely detection of anomaly problems, and performs debugging by re-planning the automatic uncoupling, thereby improving the hierarchy of debugging and the robustness of the automatic uncoupling process.

[0085] Figure 4 The present invention is a flowchart of another method for debugging an abnormal automatic unhooking connection in an embodiment of the present invention.

[0086] like Figure 4 As shown, the process of automatic unhooking includes: selecting a docking station to start the trip, the target vehicle reverses into the docking stop, and judging whether the target hook is successfully positioned. If successful, the docking is completed and the next trip is started.

[0087] The above-mentioned automatic uncoupling process is detected and controlled using an automatic uncoupling docking abnormality debugging system, which mainly includes three modules: an abnormality detection module, an abnormality decision control module, and an abnormality reporting module.

[0088] The anomaly detection module's primary inputs are the target vehicle status, target hook status, docking status, and other real-time statuses captured by the real-time control system (RCS). The entire automatic unhooking process is divided into the target hook raising phase, the target vehicle stopping phase, and the target hook lowering phase. Each phase is verified against the target object's real-time status and the target status, outputting the verification results (status verification results). The anomaly detection module also verifies hardware status (hardware fault type) and timeout status (target state timeout) in real time, integrating the output detection results and the corresponding fault codes.

[0089] It can be understood that the anomaly detection module mainly consists of three parts: (1) the verification part, which transmits the real-time status of the target object through RCS in real time, compares the target status, and performs verification to determine whether the real-time status and the target status are consistent or consistent. (2) the timeout part, which sets the start and end time of each state respectively to monitor whether the detection and scheduling timeout is caused by communication or heartbeat abnormalities. (3) the hardware status detection part, which detects the data parameters such as the moving distance, voltage, current, etc. of the hardware to determine whether there are hardware abnormalities such as unstable motor operation and jamming (the existence of abnormalities in each hardware).

[0090] The input of the abnormal decision control module is the detection result of the abnormal detection module and the fault code corresponding to the detection result. The behavior of each target object is determined based on the above information and fed back to the cloud (cloud server). It mainly includes three parts: (1) For the verification part, determine the source of the abnormality and try to recover. If the recovery fails, try to restore the previous state until entering the timeout logic. (2) For timeout processing, if the state times out (target state timeout), the state of all hardware and target objects can be reset, the movement of the target vehicle and target hook can be stopped, and the vehicle station can be planned to the vehicle docking point, and try again. (3) For hardware status detection, determine the type of hardware fault (unable to repair or self-repairable). If the fault is unrecoverable (unable to repair), control the hardware to power off and report manual intervention maintenance work. If the fault is recoverable (can be repaired self-repaired), try to repair it. After the repair is successful, continue the process. If the repair fails, report the type of hardware fault.

[0091] The exception reporting module mainly completes communication with the cloud, provides communication interfaces and data links, and reports exceptions through the web or other services.

[0092] The debugging method for automatic uncoupling and docking anomalies provided in this embodiment can support various automatic uncoupling and docking processes, improve the success rate of automatic uncoupling and docking, and reduce manual intervention, making the automatic uncoupling process more robust and supporting a wider range of flexible automatic uncoupling scenarios.

[0093] Figure 5 This is a structural diagram of a debugging device for automatically disconnecting a hook and docking abnormality in an embodiment of the present disclosure. Figure 5 As shown, the device includes: a real-time status acquisition module 510, a status verification result determination module 520 and a re-control module 530.

[0094] Among them, the real-time status acquisition module 510 is used to obtain the real-time status of the target object during the process of automatic uncoupling of the target vehicle and the target hook, wherein the target object is the target vehicle or the target hook; the status verification result determination module 520 is used to determine the status verification result based on the real-time status and the target status corresponding to the real-time status; the re-control module 530 is used to send a control instruction to the target object when the status verification result is a failure, so that the target object updates the real-time status based on the control instruction, and controls the target vehicle and the target hook to automatically uncouple.

[0095] Based on the above example, the situation where the status verification result fails includes the target state timeout, and the device also includes: a timeout detection module, which is used to obtain the preset running time and the actual running time to reach the target state during the process of automatic uncoupling of the target vehicle and the target hook; when the actual running time exceeds the preset running time, it is determined that the target state has timed out.

[0096] Based on the above example, the device also includes: a timeout counting module, which is used to determine the number of timeouts of the target state; if the number of timeouts is not less than the preset number, a stop command is issued to the target hook and the target vehicle; a timeout information is generated, and the timeout information is sent to the cloud server.

[0097] Based on the above example, the real-time state includes an initial state, and the device also includes: a total time monitoring module, used to obtain the total time for the target vehicle and the target hook to automatically unhook; if the total time is greater than the preset total time, a stop command is issued to the target hook and the target vehicle; a control instruction corresponding to the initial state is sent to the target object, so that the target object updates the real-time state based on the control instruction, and controls the target vehicle and the target hook to automatically unhook.

[0098] Based on the above example, the real-time status includes the status when the status check result is failed, and the re-control module 530 is further used to send a control instruction corresponding to the status when the status check result is failed to the target object.

[0099] Based on the above example, the device also includes: a hardware monitoring module, which is used to obtain data parameters of each hardware in the automatic uncoupling device during the process of automatic uncoupling of the target vehicle and the target hook; wherein, the automatic uncoupling device is used to control the target vehicle and the target hook to automatically uncouple; according to each of the data parameters, the existence of abnormalities in each of the hardware is determined; if at least one of the abnormalities is abnormal, the type of hardware failure is determined according to the data parameters corresponding to the abnormal hardware; wherein, the type of hardware failure is unable to be repaired autonomously or can be repaired autonomously; if at least one of the hardware failure types is unable to be repaired autonomously, the hardware that cannot be repaired autonomously is controlled to be powered off, hardware abnormality information is generated, and the hardware abnormality information is sent to the cloud server.

[0100] Based on the above example, after determining the hardware fault type according to the data parameters corresponding to the abnormal hardware, the device also includes: a repair reporting module, which is used to determine the fault repair result if the hardware fault types are all self-repairable, and send the hardware fault type and the fault repair result to the cloud server; if the fault repair result is a successful repair, then after the hardware failure, the target vehicle and the target hook are controlled to automatically unhook.

[0101] The automatic unhooking and docking abnormality debugging device provided in the embodiment of the present disclosure can execute the steps of the automatic unhooking and docking abnormality debugging method provided in the method embodiment of the present disclosure, and the execution steps and beneficial effects are not repeated here.

[0102] Figure 6 This is a schematic diagram of the structure of an electronic device in the embodiment of the present disclosure. Figure 6 , which shows a structural diagram of an electronic device 600 suitable for implementing the embodiments of the present disclosure. Figure 6 The electronic device shown is only an example and should not limit the functions and scope of use of the embodiments of the present disclosure.

[0103] like Figure 6As shown, the electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 601, which can perform various appropriate actions and processes to implement the method of the embodiment described in the present disclosure according to the program stored in the read-only memory (ROM) 602 or the program loaded from the storage device 608 into the random access memory (RAM) 603. Various programs and data required for the operation of the electronic device 600 are also stored in the RAM 603. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0104] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains program code for executing the method shown in the flowchart, thereby implementing the debugging method for automatic unhooking docking anomaly as described above. In such an embodiment, the computer program can be downloaded and installed from the network via the communication device 609, or installed from the storage device 608, or installed from the ROM 602. When the computer program is executed by the processing device 601, the above-mentioned functions defined in the method of the embodiment of the present disclosure are performed.

[0105] It should be noted that the computer-readable medium mentioned above in the present disclosure may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or component, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present disclosure, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, device, or component. In the present disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, which carries computer-readable program code. Such a propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. A computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium may be transmitted using any suitable medium, including but not limited to wires, optical cables, RF (radio frequency), etc., or any suitable combination thereof.

[0106] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device. The computer-readable medium carries one or more programs, and when the one or more programs are executed by the electronic device, the electronic device:

[0107] During the process of automatically unhooking the target vehicle and the target hook, obtaining a real-time status of a target object, wherein the target object is the target vehicle or the target hook;

[0108] Determining a state verification result based on the real-time state and a target state corresponding to the real-time state;

[0109] When the status check result is a failure, a control instruction is sent to the target object, so that the target object updates the real-time status based on the control instruction, and controls the target vehicle and the target hook to automatically unhook.

[0110] Optionally, when the above one or more programs are executed by the electronic device, the electronic device may also execute other steps described in the above embodiments.

[0111] In the context of the present disclosure, a machine-readable medium can be a tangible medium that can contain or store a program for use by or in conjunction with an instruction execution system, device or equipment. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or equipment, or any suitable combination of the foregoing. A more specific example of a machine-readable storage medium can include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0112] The above description is merely a preferred embodiment of the present disclosure and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by the specific combination of the above-mentioned technical features, but also includes other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the above-mentioned disclosed concepts. For example, a technical solution formed by replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in this disclosure.

Claims

1. A method for debugging abnormal docking by automatically unhooking, characterized in that: The method comprises: During the process of automatically unhooking the target vehicle and the target hook, obtaining a real-time status of a target object, wherein the target object is the target vehicle or the target hook; Determining a state verification result based on the real-time state and a target state corresponding to the real-time state; If the status check result fails, a control instruction is sent to the target object, so that the target object updates the real-time status based on the control instruction, and controls the target vehicle and the target hook to automatically unhook. The status check result fails, including a target status timeout. The real-time state includes an initial state, and the method further includes: Obtaining the total time duration for the target vehicle and the target hook to be automatically unhooked; If the total time is greater than a preset total time, a stop command is issued to the target hook and the target vehicle; A control instruction corresponding to the initial state is sent to the target object, so that the target object updates the real-time state based on the control instruction, and controls the target vehicle and the target hook to automatically unhook.

2. The debugging method for automatic unhooking and docking abnormality according to claim 1, characterized in that: The method further comprises: During the process of the target vehicle and the target hook being automatically unhooked, obtaining a preset running time and an actual running time to reach the target state; When the actual running time exceeds the preset running time, it is determined that the target state has timed out.

3. The debugging method for automatic unhooking and docking abnormality according to claim 2, characterized in that: Also includes: Determine the number of timeouts for the target state; If the timeout number is not less than a preset number, a stop command is issued to the target hook and the target vehicle; Generate timeout information and send the timeout information to the cloud server.

4. The debugging method for automatic unhooking and docking abnormality according to claim 1, characterized in that: The real-time status includes a status when the status check result is a failure, and the sending of a control instruction to the target object includes: A control instruction corresponding to a state when the state check result is failure is sent to the target object.

5. The debugging method for automatic unhooking and docking abnormality according to claim 1, characterized in that: Also includes: During the process of automatic uncoupling between the target vehicle and the target hook, data parameters of various hardware in the automatic uncoupling device are obtained; wherein the automatic uncoupling device is used to control the automatic uncoupling between the target vehicle and the target hook; Determining, based on the data parameters, whether an abnormality exists in each of the hardware; If at least one of the abnormalities is abnormal, determining the type of hardware failure based on the data parameters corresponding to the abnormal hardware; wherein the type of hardware failure is either unable to be repaired autonomously or can be repaired autonomously; If at least one hardware fault type is unable to be repaired autonomously, the hardware that cannot be repaired autonomously is controlled to be powered off, hardware abnormality information is generated, and the hardware abnormality information is sent to the cloud server.

6. The debugging method for automatic unhooking and docking abnormality according to claim 5, characterized in that: After determining the type of hardware failure according to the data parameters corresponding to the abnormal hardware, the method further includes: If the hardware fault types are all self-repairable, determining the fault repair result, and sending the hardware fault type and the fault repair result to the cloud server; If the fault repair result is successful, then after the hardware failure, the target vehicle and the target hook are controlled to automatically unhook.

7. A debugging device for automatically unhooking and docking abnormality, characterized in that: include: A real-time status acquisition module is used to acquire the real-time status of a target object during the process of automatic uncoupling between the target vehicle and the target hook, wherein the target object is the target vehicle or the target hook; a state verification result determination module, configured to determine a state verification result based on the real-time state and a target state corresponding to the real-time state; a re-control module, configured to, if the state check result fails, send a control instruction to the target object, so that the target object updates its real-time state based on the control instruction, and controls the target vehicle and the target hook to automatically unhook; the state check result failing includes a target state timeout; The real-time state includes an initial state, and the re-control module is further configured to: Obtaining the total duration of automatic uncoupling of the target vehicle and the target hook; if the total duration is greater than a preset total duration, issuing a stop command to the target hook and the target vehicle; and sending a control command corresponding to the initial state to the target object, so that the target object updates the real-time state based on the control command, and controls the target vehicle and the target hook to automatically uncouple.

8. An electronic device, characterized in that: The electronic device comprises: one or more processors; a storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the debugging method for automatic unhooking and docking anomaly according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method for debugging an automatic unhooking and docking anomaly according to any one of claims 1 to 6 is implemented.

Images