Mobile charging robot system error code reporting method and system

Abstract

The invention relates to the technical field of robot control and fault diagnosis, in particular to a mobile charging robot system error code reporting method and system, and the system comprises an error code classification module, a timestamp management module, a timeout detection module, a reporting control module and a message publishing module. Error codes are classified to various key specific hardware and various software function modules in the ROS through an error code classification module, a two-dimensional subdivision system of'hardware + software 'is formed, and the problem can be positioned more quickly and accurately through the detailed classification mode; the reporting frequency is controlled through the timestamp management module, the overtime detection module and the reporting control module are combined, excessive reporting of error information can be effectively avoided, and meanwhile it is ensured that important error information can be found and processed in time. The method is of great significance in improving the stability and reliability of the system.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of robot control and fault diagnosis, and in particular to a mobile charging robot system error code reporting method and system. BACKGROUND

[0002] In a robot system, the abnormal state monitoring and reporting of various sensors, actuators and algorithm modules is the key to ensure reliable operation of the system. The traditional error reporting mechanism usually relies on simple log recording or local state feedback, lacks unified error classification, frequency control and remote reporting capability, resulting in problems such as delayed fault response, repeated reporting and information redundancy.

[0003] In the prior art, although there are some error monitoring nodes based on ROS, they often lack control of error reporting frequency, refinement of error classification and integration capability with other systems (such as MQTT message queues), making it difficult to meet the real-time, reliability and maintainability requirements of industrial robot systems for error management. SUMMARY

[0004] The technical problem to be solved by the present application is that the core of accurate fault source positioning in the prior art lies in building the mapping relationship between error codes and multi-source data, rather than simply relying on the granularity of error codes. It is still necessary to cooperate with coarse-grained error codes through log depth analysis, hardware state verification, model reasoning and other means.

[0005] To this end, the present application provides a mobile charging robot system error code reporting method and system, which realizes the structuring of data collection through module subdivision and timed reporting, significantly reduces the cross-system data collaboration cost, directly binds the error code subdivision with physical hardware modules and software function modules, solves the pain point of "hardware failure needs to be inferred indirectly through multi-source data" in the prior art, and further improves the system reliability by controlling the reporting frequency.

[0006] The technical solution adopted by the present application to solve the technical problem is: A mobile charging robot system error code reporting system, comprising, An error code classification module, which sets a corresponding error code preset range for each key hardware module and software function module on a mobile charging robot device; each different error code in the error code range corresponds to a different error; A timestamp management module, which maintains a recent reporting timestamp for each error code for controlling the reporting frequency; A timeout detection module for monitoring the data update time of each sensor in the hardware module or each software function module to determine whether it is overdue; The reporting control module determines whether to report according to the error type to which the error code belongs and the latest reporting timestamp; The message publishing module encapsulates the error code and the time information and publishes to a remote server.

[0007] By adopting the above technical solution, the error codes are classified into specific hardware modules and ROS-specific software function modules, forming a two-dimensional subdivision system of "hardware + software". This detailed classification method can more accurately locate the problem. Through the timestamp management module to control the reporting frequency, combined with the timeout detection module and the reporting control module, it can effectively avoid the over-reporting of error information, while ensuring that important error information can be discovered and processed in time. The unified management, frequency control and remote reporting of multi-source errors help to improve the fault diagnosis and processing efficiency of the robot system.

[0008] A reporting method, comprising the following steps: The error code classification module subscribes to sensor data, state topics and error code topics in the system; The timeout detection module detects whether the data update time is overdue. If it is overdue and meets the reporting frequency (i.e. reporting interval time) of the reporting control module, the corresponding error code is reported; The reporting control module accepts error codes published by nodes in other software function modules, classifies them according to error code ranges, and judges whether they meet the reporting frequency condition; The message publishing module encapsulates the error code and the time information and reports to a remote server.

[0009] By adopting the above technical solution, the error codes classified in detail can more accurately locate the problem. By controlling the reporting frequency, combined with timeout detection and reporting frequency control, it can effectively avoid the over-reporting of error information, while ensuring that important error information can be discovered and processed in time.

[0010] Further, the message publishing module encapsulates the error code and the time information into JSON format and reports to a remote server through MQTT protocol.

[0011] Further, after the timestamp management module receives an error information (including at least error code and time information), it checks the difference between the timestamp of this error information and the timestamp of the last reported error code of this type. If the difference exceeds the set interval time, it is transferred to the reporting control module.

[0012] Further, the error types are divided into two levels of emergency and non-emergency. When emergency level and non-emergency level error codes occur at the same time, the message publishing module gives priority to publishing emergency level error codes. Meanwhile, the error code of the emergency level is not limited by the reporting frequency.

[0013] Further, the node includes a sensor data subscription node, a task state subscription node, an error code subscription node, a motion state subscription node, an MQ message publishing node, and the like.

[0014] The present application has the following advantages: 1. Clear error classification: different hardware and software function modules are distinguished according to error code ranges, which facilitates quick problem positioning and avoids the load problem caused by the cooperation of multiple source data for coarse-grained error codes; 2. Controllable reporting frequency: by controlling the reporting time interval, repeated reporting is avoided, and network load is reduced; 3. Integrated MQTT remote reporting: cloud monitoring and remote diagnosis are supported; 4. Support for active and passive error detection: both sensor timeout detection and error codes published by other nodes are supported; 5. Good scalability: new error code types and sensor detection logic can be flexibly added. BRIEF DESCRIPTION OF DRAWINGS

[0015] The present application will be further described below in conjunction with the drawings and examples.

[0016] Figure 1 is a structural schematic diagram of the reporting system in the present application.

[0017] Figure 2 is a flowchart of the reporting method in the present application.

[0018] Figure 3 is a sensor error code subscription processing process diagram in the embodiment of the present application. DETAILED DESCRIPTION

[0019] The present application will now be further described in conjunction with the drawings. These drawings are all simplified schematic diagrams, and only illustrate the basic structure of the present application in a schematic manner, and therefore only show the configurations related to the present application.

[0020] In the description of the present application, it needs to be understood that the orientation or positional relationship indicated by the terms "center", "longitudinal", "transverse", "length", "width", "thickness", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", "clockwise", "counterclockwise", "axial", "radial", "circumferential" and the like is based on the orientation or positional relationship shown in the drawings, and is only for the convenience of describing the present application and simplifying the description, and does not indicate or imply that the device or element referred to must have a particular orientation, be constructed and operated in a particular orientation, and therefore cannot be understood as a limitation on the present application. In addition, the features defined as "first" and "second" can be explicitly or implicitly included one or more of the features. In the description of the present application, unless otherwise stated, the meaning of "a plurality of" is two or more.

[0021] In the description of the present application, it needs to be understood that unless otherwise explicitly specified and limited, the terms "mounting", "connection", "connection" should be understood broadly, for example, it can be fixedly connected, or it can be detachably connected, or integrally connected; it can be mechanically connected, or it can be electrically connected; it can be directly connected, or it can be indirectly connected through an intermediate medium, or it can be the communication inside two elements. For those skilled in the art, the specific meaning of the above terms in the present application can be understood according to the specific circumstances.

[0022] Referring to Figure 1 A mobile charging robot system error code reporting system, comprising an error code classification module, a timestamp management module, a timeout detection module, a reporting control module and a message publishing module.

[0023] Among them, the error code classification module is used to set a corresponding error code preset range for each key hardware module and software function module on the mobile charging robot device and ROS, such as CPU (1000-1999), laser radar (2000-2999), IMU (3000-3999), camera (4000-4999), chassis (5000-5999), safety touch edge (6000-6999), emergency stop device (7000-7999), straight fixed distance (8000-8999), rotation fixed angle (9000-9999), motion control (10000-10999), precise docking (11000-11999), navigation (12000-12999), positioning (13000-13999) and the like. Each specific error code in the error code range corresponds to different errors, and the difference from the existing error code classification is that it is more detailed, and the related problems can be directly viewed and quickly located.

[0024] The timestamp management module is used to maintain the latest reporting timestamp for each error code, which is used to control the reporting frequency. After receiving an error message (including error code and time information, etc.), the difference between the timestamp of the error message and the timestamp of the last reported error code of the same type is checked. If the difference exceeds the set time, such as 10 minutes, the reporting control module is transferred.

[0025] The timeout detection module is used to monitor the data update time of each sensor in the hardware module or each software function module, and to determine whether it is timeout. For example, if the timeout time of a sensor is set to 3 seconds, if the corresponding sensor data is not received within 3 seconds, it is determined that the sensor data is timeout.

[0026] The reporting control module is used to determine whether to report according to the error type to which the error code belongs and the latest reporting timestamp. When a module has a problem, it may continuously issue error codes. In order to reduce network bandwidth occupation and relieve the pressure on the cloud server, the time difference between the new error message received and the last reporting time is calculated. If the time difference exceeds 10 minutes, the error code is reported. Error types are divided into two levels: urgent and non-urgent. The error type of safety touch edge and emergency stop device with high collision risk is the urgent level, and other error types are the non-urgent level. When error codes of the urgent level and the non-urgent level occur at the same time, the error code of the urgent level is given priority.

[0027] The message publishing module is used to encapsulate the error code, time information, device ID information (in the case of multiple devices), real-time position information of the robot, etc. into JSON format and report it to the remote server through MQTT protocol.

[0028] Referring to Figure 2 A mobile charging robot system error code reporting method, comprising the following steps: The timestamp management module initializes the latest reporting timestamp of each error code; The error code classification module subscribes to sensor data, state topics and error code topics in the system; The timeout detection module detects whether the sensor data is timeout. If it is timeout and meets the reporting interval condition of the reporting control module, the corresponding error code is reported; The reporting control module accepts the error code published by the node in the other software function module, classifies it according to the error code range and judges whether it meets the reporting frequency condition; The message publishing module encapsulates the error information into JSON format and publishes it through MQTT.

[0029] Referring to Figure 3 Example 1: Laser radar data timeout reporting Scenario description: During the execution of the navigation task, the laser radar (Lidar) of the mobile charging robot is interrupted due to network fluctuation.

[0030] Process description 1. System detection: The timeout detection module continuously monitors the update frequency of the ROS system / back_scan topic; if no lidar data is received for more than 3 seconds, a timeout error (error code range: 2000-2999) is triggered.

[0031] 2. Report decision: The system checks the last reported timestamp of error code 2007 in this type of error code (2000-2999) after radar timeout, and if it has been more than 10 minutes since the last report, it is allowed to report; otherwise, it is ignored.

[0032] 3. Message packaging and reporting: Error code 2007, current timestamp, device ID, etc. information is packaged into JSON format and published to the remote server through MQTT protocol.

[0033] 4. Response: After receiving the alarm from the remote server, the operation and maintenance personnel remotely check the connection state of the lidar and perform on-site maintenance.

[0034] Example 2: Emergency stop device triggers reporting Scenario description: A mobile charging robot is performing a charging task in an underground parking lot when it is accidentally collided with by an outsider and triggers its physical emergency stop button.

[0035] Process description 1. Error code publishing: The system detects that the physical signal of the emergency stop button of the emergency stop device is triggered, and immediately publishes an emergency error code by the corresponding node. This error code belongs to the "emergency stop device" category (7000-7999, for example, 7001).

[0036] 2. Reporting decision: The error code classification module of the present invention subscribes and receives this error code, and the reporting control module immediately identifies that this error code belongs to a safety error of the emergency level.

[0037] For the highest priority error such as emergency stop, the system has special rules: not subject to the 10-minute reporting frequency limit, once it occurs, it must be reported immediately to ensure that safety risks can be perceived in the first time. Therefore, the reporting control module skips the check logic and directly allows reporting.

[0038] 3. Message packaging and reporting: The message publishing module packages error code 7001, device ID, precise trigger timestamp, real-time location information of the robot into a JSON format emergency message, and publishes it to the remote server through MQTT protocol.

[0039] 4Response: After receiving the emergency alarm, the remote server immediately notifies the operation and maintenance personnel. The operation and maintenance personnel can immediately check the on-site situation through video monitoring to confirm whether it is a false trigger or a real danger. After confirming the safety, the remote server sends a command to reset the emergency stop state and resume the robot task.

[0040] Reference Figure 3 , Embodiment 3: Failure report of accurate docking Scene description: When the mobile charging robot tries to dock with the docking device on the charging parking space, the docking fails due to the removal of the docking device on the parking space. The accurate docking corresponding node publishes an error code (such as 11003).

[0041] Process description 1. Error code publishing: After the docking fails, the accurate docking module publishes the error code 11003 to the error code topic.

[0042] 2. Report decision: The error code classification module identifies it as an "accurate docking" category (11000-11999), and the control module checks the reporting frequency of the error code in this category. If the same type of error has been reported within 10 minutes, this time will not be reported.

[0043] 4. Response: After receiving the notification from the remote server, check the on-site situation through video monitoring to confirm whether the docking device exists. If the docking device exists, remotely control the robot to adjust the position and re-dock or remotely control the robot to return to the original route.

[0044] Based on the above ideal embodiments according to the present application, through the above description, relevant personnel can make various changes and modifications without deviating from the scope of the present application. The technical scope of the present application is not limited to the contents of the specification, and must be determined by the scope of the claims.

Claims

1. A mobile charging robot system error code reporting system, characterized in that, include, The error code classification module sets corresponding preset error code ranges for each key hardware module on the mobile charging robot device, as well as ROS-specific software function modules. The timestamp management module maintains the most recent reported timestamp for each error code to control the reporting frequency; The timeout detection module is used to monitor the data update time of each sensor or software function module in the hardware module and determine whether a timeout has occurred. The reporting control module determines whether to report based on the error code's corresponding error type and the most recent reporting timestamp. The message publishing module encapsulates error codes and time information and publishes them to a remote server.

2. The reporting system according to claim 1, characterized in that, The error types are divided into two levels: urgent and non-urgent.

3. The reporting system according to claim 1, characterized in that, The error information received by the timestamp management module includes error codes and time information.

4. The reporting system according to claim 3, characterized in that, The error message may also include one or two of the following: device ID information and the robot's real-time location information.

5. The reporting system according to claim 1, characterized in that, The message publishing module encapsulates the error code and time information into JSON format and reports it to the remote server via the MQTT protocol.

6. The reporting system according to claim 1, characterized in that, Within the range of error codes, each different error code corresponds to a different error.

7. The reporting system according to claim 1, characterized in that, The reporting frequency is adjustable.

8. A reporting method based on the error code reporting system of a mobile charging robot system as described in any one of claims 1-7, characterized in that, Includes the following steps: S1, The timestamp management module initializes the most recently reported timestamps for each error code; S2, the error code classification module subscribes to sensor data, status topics, and error code topics in the system; S3, the timeout detection module detects whether the data update time has exceeded the limit. If it exceeds the limit and meets the reporting interval condition of the reporting control module, it reports the corresponding error code. S4, The reporting control module receives error codes published by nodes in other software function modules, classifies them according to the error code range, and determines whether the reporting frequency and error type conditions are met; S5, the message publishing module encapsulates the error code and time information and reports it to the remote server.

9. The reporting method according to claim 8, characterized in that, The nodes include sensor data subscription nodes, task status subscription nodes, error code subscription nodes, motion status subscription nodes, and MQ message publishing nodes.

10. The reporting method according to claim 8, characterized in that, In step S5, when both emergency and non-emergency error codes occur simultaneously, the message publishing module prioritizes publishing the emergency error code. Meanwhile, the error codes for the aforementioned emergency levels are not subject to reporting frequency limitations.

Images