Industrial robot automatic charging and fault grading system

Abstract

The embodiment of the invention discloses an industrial robot automatic charging and fault grading system. A specific embodiment of the method comprises the following steps: a battery detection device is configured to perform fusion processing on a pre-collected multi-source environmental perception data set to generate robot current pose data with a semantic tag, and send the robot current pose data to a fault classification device; the charging device is configured to generate robot charging state data according to the received robot charging fault level, and transmit the robot charging state data to the mobile terminal; the mobile terminal is configured to render the received robot charging state data and cinder ladle temperature data collected in advance so as to generate a temperature change curve. According to the embodiment, the inspection continuity is improved, the fault grading time and the charging period are shortened, and the operation loss is reduced.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and more specifically to an automatic charging and fault classification system for industrial robots. Background Technology

[0002] An automatic charging and fault classification system for industrial robots is a technology for automatically charging and classifying faults in industrial robots. Currently, the common method for automatically charging and classifying faults in industrial robots is to manually check the robot's battery level, charge it, and manually classify the faults.

[0003] However, when using the above methods for automatic charging and fault classification of industrial robots, the following technical problems often arise: When a robot's battery is depleted, it needs to be manually plugged in and unplugged for charging. This is not only inefficient but also interrupts the workflow, leading to increased response time and poor continuity of inspections. Because industrial robots frequently encounter anomalies such as sensor malfunctions, motor overloads, and path obstructions, the time from the occurrence of a fault to human intervention is often long, resulting in increased charging cycles and operational losses. Summary of the Invention

[0004] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0005] Some embodiments of this disclosure propose an automatic charging and fault classification system for industrial robots to address the technical problems mentioned in the background section above.

[0006] In a first aspect, some embodiments of this disclosure provide an automatic charging and fault classification system for industrial robots. The automatic charging and fault emergency handling system includes: a battery detection device configured to: perform fusion processing on a pre-collected multi-source environmental perception dataset to generate robot current pose data with semantic labels, and send the robot current pose data to the fault classification device, wherein the multi-source environmental perception dataset includes: robot point cloud data, radar echo signals, and visual positioning images; and a fault alarm device configured to: perform threshold comparison on a pre-acquired battery raw parameter dataset to generate a power alarm signal, and send the power alarm signal to the fault classification device. The fault classification device is configured to: perform fault matching on received power alarm signals, received robot current pose data, and real-time fault codes to generate a robot charging fault level, and send the robot charging fault level to the charging device; the charging device is configured to: generate robot charging status data based on the received robot charging fault level, and transmit the robot charging status data to a mobile terminal; the mobile terminal is configured to: render the received robot charging status data and pre-collected slag bag temperature data to generate a temperature change curve.

[0007] Secondly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation of the first aspect above.

[0008] Thirdly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0009] The above-described embodiments of this disclosure have the following beneficial effects: The automatic charging and fault classification system for industrial robots, as described in some embodiments of this disclosure, improves the continuity of inspections, shortens the fault classification time and charging cycle, and reduces operational losses. Specifically, the poor continuity of inspections, leading to increased charging cycles and operational losses, is caused by the fact that manual plugging and unplugging of the robot after its battery is depleted is not only inefficient but also interrupts the workflow, resulting in increased response time and poor inspection continuity. Because industrial robots frequently encounter anomalies such as sensor malfunctions, motor overloads, and path obstructions, the time from the occurrence of a fault to manual intervention is often long, leading to increased charging cycles and operational losses. Based on this, the automatic charging and fault classification system for industrial robots, as described in some embodiments of this disclosure, includes: the battery detection device is configured to: perform fusion processing on a pre-collected multi-source environmental perception dataset to generate robot current pose data with semantic tags, and send the robot current pose data to the fault classification device, wherein the multi-source environmental perception dataset includes: robot point cloud data, radar echo signals, and visual positioning images. Therefore, multi-source environmental perception datasets can be used to achieve subsequent unmanned automatic docking and efficient power replenishment in harsh environments. The aforementioned fault alarm device is configured to: perform threshold comparisons on a pre-acquired raw battery parameter dataset to generate a power alarm signal, and send the power alarm signal to the aforementioned fault classification device. The raw battery parameter dataset includes battery pack voltage data and battery pack current data. Thus, fault alarms can be triggered by generating power alarm signals, eliminating the need for human intervention. In cases where industrial robots encounter abnormalities such as sensor malfunction, motor overload, or path obstruction, automatic fault identification can be performed, shortening response time. The aforementioned fault classification device is configured to: perform fault matching on the received power alarm signal, the received robot current pose data, and real-time fault codes to generate a robot charging fault level, and send the robot charging fault level to the aforementioned charging device. Thus, fault classification can shorten the fault handling and charging cycle, reducing operational losses. The aforementioned charging device is configured to: generate robot charging status data based on the received robot charging fault level, and transmit the robot charging status data to a mobile terminal. This can shorten the charging cycle. The aforementioned mobile terminal is configured to render received robot charging status data and pre-collected slag bag temperature data to generate a temperature change curve. This improves the continuity of inspections, shortens fault classification time and charging cycles, and reduces operational losses. Attached Figure Description

[0010] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0011] Figure 1 This is a schematic diagram of an application scenario of an industrial robot automatic charging and fault classification system according to some embodiments of this disclosure; Figure 2 This is a flowchart of some embodiments of the industrial robot automatic charging and fault classification system according to the present disclosure; Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0012] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0013] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

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

[0015] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0016] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0017] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0018] Figure 1 This is a schematic diagram of an application scenario of an industrial robot automatic charging and fault classification system according to some embodiments of this disclosure.

[0019] exist Figure 1 In this application scenario, firstly, the multi-source environmental perception dataset is input into the battery detection device to obtain the robot's current pose data with semantic labels. Then, the semantically labeled robot current pose data is input into the fault alarm device to generate a power alarm signal. Next, the power alarm signal is input into the fault classification device to obtain the robot's charging fault level. Then, the robot's charging fault level is sent to the aforementioned charging device for charging, obtaining the robot's charging status data. Finally, the robot's charging status data is sent to the mobile terminal. It should be understood that... Figure 1 The number of multi-source environmental perception datasets and mobile terminals can be arbitrary, depending on the implementation requirements.

[0020] Continue to refer to Figure 2 The diagram illustrates a flow 200 of some embodiments of an automatic charging and fault classification system for industrial robots according to this disclosure. The automatic charging and fault classification system for industrial robots includes: a battery detection device, a fault alarm device, a fault classification device, a charging device, and a mobile terminal, and includes the following steps: Step 201, the battery detection device is configured to: perform fusion processing on the pre-collected multi-source environmental perception dataset to generate robot current pose data with semantic labels, and send the robot current pose data to the fault classification device.

[0021] In some embodiments, the battery detection device is configured to: perform fusion processing on a pre-collected multi-source environmental perception dataset to generate robot current pose data with semantic labels, and send the robot current pose data to the fault classification device, wherein the multi-source environmental perception dataset includes: robot point cloud data, radar echo signals and visual positioning images.

[0022] The aforementioned battery detection equipment is used to process environmental perception data. The battery detection equipment and the fault classification equipment are connected wirelessly. The aforementioned multi-source environmental perception dataset can be a collection of raw data about the robot's environment collected by various sensors. For example, it could be a collection of raw data collected by LiDAR and a vision sensor (binocular camera) in the physical space of the slag cooling field where the robot is located. The slag cooling field physical space can refer to a space with a total area of ​​80,000 square meters, containing 10 rows of slag bags (34 bags per row) and a separate row (19 slag bags) on the north side. The aforementioned robot point cloud data can be the spatial three-dimensional point coordinates obtained by LiDAR scanning the environment. For example, the aforementioned robot point cloud data could be (12.35, -3.21, 0.85). The aforementioned radar echo signal can be the obstacle reflection signal received by millimeter-wave radar. For example, the aforementioned radar echo signal could be {target distance: 8.5 meters, relative speed: +0.25 meters per second, echo intensity: 32.5 dB}. The aforementioned visual positioning image can be an image containing environmental features captured by a camera. For example, the aforementioned visual positioning image can be an image in RGB888 format. The aforementioned semantic labels can be used to assign meaning to data points, such as "This is a charging station," "This is a slag pack A3-12," or "This is an obstacle." The robot's current pose data can be the robot's position (X, Y coordinates) and orientation angle (Yaw) in the world coordinate system.

[0023] As an example, the aforementioned battery detection equipment can align robot point cloud data, radar echo signals, and visual positioning images in time and space. Then, it uses a Kalman filter algorithm to determine the robot's position and orientation, generating semantically labeled current robot pose data. For instance, when the robot stops next to a slag bag, the lidar scans the point cloud outlines of the surrounding slag bags (point cloud data), the millimeter-wave radar detects a worker passing by 5 meters ahead (radar echo signal), and the camera captures a numbered tag on the slag bag (visual positioning image). The battery detection equipment fuses this data to calculate that the robot is currently located "1.5 meters to the left and in front of slag bag number 12 in row A3, with the front of the vehicle facing due north" (semantically labeled current robot pose data).

[0024] Optionally, the pre-collected multi-source environmental perception dataset is fused to generate semantically labeled current robot pose data, including: The first step is to receive robot point cloud data, radar echo signals, and visual positioning images collected by a preset lidar.

[0025] The aforementioned preset lidar can be a lidar sensor pre-installed on the robot.

[0026] As an example, the aforementioned battery detection device can read data packets from the sensor data buffer via hardware interfaces (such as Ethernet, USB, and CAN bus) to receive robot point cloud data, radar echo signals, and visual positioning images collected by a preset LiDAR. For instance, after the robot starts, the battery detection device reads a frame of point cloud data (approximately 300,000 points) from the LiDAR via the UDP protocol, a frame of target list (e.g., containing information on 8 obstacles) from the millimeter-wave radar via the CAN bus, and a 1280×720 RGB image from the camera via USB 3.0. The timestamps of these three sets of data are aligned to the same millisecond level.

[0027] The second step is to filter the robot point cloud data to generate filtered robot point cloud data.

[0028] Among them, the filtered robot point cloud data mentioned above can be the valid point cloud data retained after filtering.

[0029] As an example, the aforementioned battery detection device can use a pass-through filtering algorithm to crop the point cloud data based on the coordinate range (X, Y, Z) of the robot point cloud data, retaining only points within a certain range around the robot to generate filtered robot point cloud data. For instance, if the original point cloud contains a small number of isolated noise points caused by dust in the air, and each point has 50 neighboring points, if the average distance between a point and its neighboring points is greater than three times the global average distance, it is identified as noise and removed. After processing, the point cloud data is reduced from 300,000 points to 280,000 points, and the noise is eliminated.

[0030] The third step is to register the filtered robot point cloud data to generate a 3D point cloud map of the environment.

[0031] Among them, the environmental 3D point cloud map can be a set of 3D point clouds representing the static environment of the entire slag cooling field, which is composed of multiple frames of point clouds.

[0032] As an example, the battery detection device described above can use the Iterative Closest Point (ICP) algorithm to find corresponding point pairs between two frames of point cloud data in the filtered robot point cloud data, iteratively optimizing the rotation matrix and translation vector to maximize the overlap between the two frames of point cloud data, thereby generating a 3D point cloud map of the environment. For example, the robot starts from the charging room and scans as it goes. The battery detection device performs ICP registration between the current frame point cloud and the partial map constructed at the previous moment, calculates the robot's displacement in this short period of time (e.g., moving forward 0.5 meters, deviating to the right 0.02 meters), and merges the current frame point cloud into the map, ultimately generating a 3D point cloud map of the environment.

[0033] The fourth step is to perform target detection on the radar echo signals to obtain the location information of dynamic obstacles.

[0034] Among them, the dynamic obstacle position information can be the distance, azimuth angle and speed of the moving object (such as a person or vehicle) relative to the robot obtained through target detection.

[0035] As an example, the aforementioned battery detection device can acquire a frame of data using millimeter-wave radar: "A target is located at a distance of 8.5 meters, an azimuth angle of +2.3°, and a relative speed of +0.25 m / s (moving away from the robot)." The battery detection device correlates and matches this target with the target detected in the previous frame, determines that it is the same person moving away, and updates its world coordinates to (X=12.3, Y=45.6). The battery detection device also detects another newly appearing obstacle at a distance of 5 meters, with a relative speed of -1.0 m / s (approaching), and marks it as a "new obstacle," thus achieving target detection on the aforementioned radar echo signal and obtaining dynamic obstacle location information.

[0036] The fifth step is to extract features from the above visual positioning images to generate visual positioning image features.

[0037] As an example, the aforementioned battery detection device can extract features from the aforementioned visual positioning image using FAST corner detection to generate visual positioning image features. For instance, FAST corner detection traverses the aforementioned visual positioning image, searching for pixels with drastic grayscale changes as candidate keypoints, and then calculates the gradient histogram of the pixel blocks surrounding each keypoint to generate a 256-bit or 512-bit binary feature vector.

[0038] The sixth step is to perform pose calculation on the above visual positioning image features to obtain the robot's visual odometry data.

[0039] The aforementioned visual odometry data can be the relative displacement and attitude changes of the robot obtained through visual calculations.

[0040] As an example, the battery detection device described above can calculate the robot's relative motion between two consecutive frames by matching feature points in the visual positioning image features, thus obtaining the robot's visual odometry data. For instance, in the current frame image, there is a feature point A (u=325, v=478) in the upper left corner. In the previous frame image, the position of this feature point was (u=320, v=480). By matching 200 similar feature point pairs, using epipolar geometry constraints (such as essential matrix factorization), it can be determined that the robot rotated 0.5 degrees to the right and moved 0.1 meters forward in this short period of time; this displacement is the visual odometry data.

[0041] The seventh step involves fusing the aforementioned 3D point cloud map of the environment, the aforementioned dynamic obstacle location information, and the aforementioned visual odometry data to generate the robot's current pose data with semantic labels.

[0042] As an example, the aforementioned battery detection device can use an extended Kalman filter (EKF) to input the aforementioned 3D point cloud map of the environment and the aforementioned visual odometry data as observations, and use the aforementioned dynamic obstacle position information as constraints to calculate the most likely robot pose. For example, laser registration shows the robot at (15.2, 88.7), and visual odometry estimates the robot at (15.3, 88.5). Considering that the radar detects no obstruction in front, the final output is the optimal estimated pose (15.25, 88.65, heading angle 92.3°). Then, this coordinate is compared with the semantic map, and it is found that the robot is located "2.5 meters directly in front of the charging room", generating pose data with semantic labels: "Current position of the robot: 2.5 meters directly in front of the charging room, coordinates (15.25, 88.65), heading angle 92.3°".

[0043] Step 202, the above-mentioned fault alarm device is configured to: perform threshold comparison on the pre-acquired battery raw parameter dataset to generate a power alarm signal, and send the power alarm signal to the above-mentioned fault classification device.

[0044] In some embodiments, the fault alarm device is configured to: perform threshold comparison on a pre-acquired battery raw parameter dataset to generate a power alarm signal, and send the power alarm signal to the fault classification device, wherein the battery raw parameter dataset includes: battery pack voltage data and battery pack current data.

[0045] The aforementioned fault alarm device is used to monitor battery parameters. It is connected to the aforementioned fault classification device via wireless communication. The battery pack voltage data can be the total battery pack voltage and the voltage value of each individual cell connected in series (e.g., 3.2V). The battery pack current data can be the charging and discharging current value of the battery pack (positive for discharging, negative for charging). The low battery alarm signal indicates a low battery level and may include information such as device ID, alarm type, and timestamp.

[0046] As an example, the aforementioned fault alarm device can calculate the remaining battery percentage using the ampere-hour integration method on voltage and current data, and then compare this percentage with the threshold of 20%. For instance, if the fault alarm device reads a battery voltage of 48V and a discharge current of 10A, it calculates the current remaining battery level to be 18%. It compares 18% with a preset 20% threshold, finds that 18% < 20%, and thus generates a battery alarm signal with the message "Robot R002, low battery, current battery level 18%".

[0047] Optionally, a threshold comparison is performed on a pre-acquired dataset of raw battery parameters to generate a battery level alarm signal, including: The first step is to receive the pre-acquired battery pack voltage and current data.

[0048] As an example, the aforementioned fault alarm device can communicate with the BMS hardware via the CAN bus, periodically (e.g., every 100ms) read the raw register values ​​such as voltage, current, and temperature collected by the BMS, and perform unit conversion (e.g., converting ADC code values ​​to volts and amperes) to obtain battery pack voltage data and battery pack current data.

[0049] The second step is to integrate the battery pack voltage data and the battery pack current data to generate the battery state of charge value.

[0050] The battery state of charge value can be the percentage of remaining charge, where 0% indicates empty and 100% indicates full.

[0051] As an example, the aforementioned fault alarm device can integrate the battery pack voltage and current data using the ampere-hour integration method to generate a battery state-of-charge (SOC) value. For instance, the previously recorded SOC value was 95%, with a rated capacity of 100 Ah. If the current remained at 15.3 A for the past second, the integrated charge would be 15.3 A × 1 s = 0.00425 Ah. The new SOC value would then be 95% - (0.00425 / 100) × 100% = 94.99575%. The system continues to integrate, and when the cumulative discharge reaches 80 Ah, the battery SOC value will display as 15%.

[0052] The third step is to compare the battery state of charge value with the preset low charge threshold to obtain the threshold comparison result.

[0053] The aforementioned preset low battery threshold can be a pre-defined minimum battery level threshold. For example, the preset low battery threshold can be 20%. The threshold comparison result can be a Boolean value: True indicates that the battery state of charge (SOC) is less than or equal to the preset low battery threshold, and False indicates that the battery SOC is greater than or equal to the preset low battery threshold.

[0054] As an example, the aforementioned fault alarm device can compare the battery state-of-charge value with a preset low-charge threshold using conditional judgment to obtain a threshold comparison result. For example, if the current battery state-of-charge value is 18% and the preset low-charge threshold is 20%, the comparison is performed: 18 <= 20, the condition is met, and the threshold comparison result is True.

[0055] Fourth, in response to the determination that the above threshold comparison result indicates that the battery state of charge value is less than or equal to a preset low power threshold, a power alarm signal is triggered.

[0056] As an example, when the threshold comparison result is True, the above-mentioned fault alarm device can call the alarm sending function to construct an alarm message structure, fill in the relevant fields, and then send the message to the fault classification device through a communication interface (such as serial port or CAN).

[0057] Step 203, the fault classification device is configured to: perform fault matching on the received power alarm signal, the received robot current pose data and real-time fault code to generate a robot charging fault level, and send the robot charging fault level to the charging device.

[0058] In some embodiments, the fault classification device is configured to: perform fault matching on the received power alarm signal, the received robot current pose data and the real-time fault code to generate a robot charging fault level, and send the robot charging fault level to the charging device.

[0059] The aforementioned fault classification device can be a central processing unit used to receive information, determine the fault level, and generate instructions. The aforementioned charging device is connected to the aforementioned fault classification device via wireless communication. The aforementioned real-time fault codes can be abnormal codes reported by the self-checks of various robot components (motors, sensors, etc.), for example, E001 (left drive motor overload). The aforementioned robot charging fault levels can be levels classified according to the severity of the fault. For example, the aforementioned robot charging fault levels can include: Level A (fatal fault), Level B (serious fault), Level C (general fault), and Level D (indicative fault).

[0060] As an example, the aforementioned fault classification device can combine received power alarm signals, received robot current pose data, and real-time fault codes to determine the appropriate level of emergency charging response using a pre-defined rule engine (such as a fault tree). For instance, the fault classification device might simultaneously receive "Power 18%" (power alarm signal), "Robot in row 5 of zone B" (robot current pose data), and "Left motor overload" (real-time fault code). It then performs a matching: the power is low and charging is needed, but the left motor malfunction prevents long-distance movement. The system determines this is not a normal low-power charging situation, but rather an emergency charging under a Level A (fatal) fault. Therefore, it generates a "Level A Charging Fault" rating.

[0061] Optionally, the received battery alarm signal, the received robot current pose data, and the real-time fault code are matched to generate a robot charging fault level, including: The first step is to perform weighted analysis on the received power alarm signal, the received robot current pose data, and the real-time fault code to generate robot weight data.

[0062] As an example, the fault classification device described above can assume a weight of 0.3 for power alarm, 0.2 for pose deviation from charging station, and 0.5 for motor fault. The three weights are then weighted and summed to generate robot weight data. This weight analysis can be performed by assigning weights to the received power alarm signal, the received current robot pose data, and the real-time fault code according to a preset weight table. The preset weight table can be a pre-defined set of three weights that sum to 1.

[0063] The second step is to perform fault tree matching on the above robot weight data to generate robot charging fault instructions.

[0064] As an example, the fault classification device described above can compare robot weight data with a pre-built fault tree, searching downwards along the branches of the tree until a specific fault type and level instruction is matched. The fault tree described above is a logical tree structure, with the root node being "system fault," child nodes divided according to fault type (such as "power fault," "motion fault," "sensor fault"), and leaf nodes corresponding to specific fault levels and handling strategies.

[0065] The third step is to perform task priority preemption processing on the above-mentioned power alarm signals and to mark the priority of the above-mentioned power alarm signals to obtain the priority power alarm signals.

[0066] As an example, the fault classification device described above can switch the use of CPU and system resources to the power alarm signal, and assign priority to the power alarm signal to obtain a priority power alarm signal. For example, when the robot is performing a temperature measurement task on the slag bag in area B (priority 5), and the power alarm signal arrives (priority 0, the highest), resources such as CPU and memory are allocated to the power alarm signal.

[0067] The fourth step involves binding the robot's current pose data with the preset charging room coordinates based on the aforementioned priority power alarm signal and robot charging fault command, thereby generating a robot charging fault level that includes a sequence of path points.

[0068] As an example, the aforementioned fault classification device can invoke a path planning algorithm (such as Dijkstra's algorithm) to calculate a smooth path that avoids obstacles, starting from the location of the priority power alarm signal, ending at the preset charging room coordinates, and constrained by the environmental 3D point cloud map. The path consists of a series of intermediate points (path points). This path array is then packaged with the aforementioned robot charging fault instruction to generate a robot charging fault level containing a sequence of path points.

[0069] Step 204: The charging device is configured to generate robot charging status data based on the received robot charging fault level, and to transmit the robot charging status data to the mobile terminal.

[0070] In some embodiments, the charging device is configured to: generate robot charging status data based on the received robot charging fault level, and transmit the robot charging status data to a mobile terminal.

[0071] The charging device can be a mechanical or electrical device that performs the physical charging action. The charging device is connected to the mobile terminal wirelessly. The robot's charging status data can be a data packet containing information such as whether charging was successful, the current battery percentage, charging current / voltage, and estimated charging time.

[0072] As an example, the aforementioned charging device can continuously collect the electrical parameters and mechanical connection status of the charging circuit and package this information into data in a standard format. For instance, upon receiving a "Level A charging fault" command, the charging device initiates an emergency charging procedure. It first attempts to connect, and upon successful connection, begins charging and generates a data packet in real time: "Charging status: In progress, current battery level: 18% to 45%, current: 50A, connection status: normal," and sends this data packet to the mobile terminal.

[0073] Optionally, based on the received robot charging fault level, robot charging status data is generated, including: The first step is to analyze the received robot charging fault level to generate a charging mode selection instruction, which includes wireless charging mode or robotic arm-assisted docking mode.

[0074] Among them, the wireless charging mode is suitable for scenarios where precise docking is not possible, while the robotic arm-assisted docking mode is suitable for scenarios where precise positioning is possible.

[0075] As an example, the charging device described above can read the robot's charging fault level value and match it with a preset mode mapping table. For example, the mode mapping table specifies: Level A fault → wireless charging mode, Level B / C / D fault → robotic arm assisted docking mode. For example, if the charging device receives a fault level of "Level A" (system paralysis), the parsing module queries the mapping table, finds that Level A corresponds to the wireless charging mode, and then generates the instruction: {"mode": "wireless"}.

[0076] The second step involves powering on the wireless charging mode selected by the above-mentioned charging mode selection instruction, controlling the wireless transmitting coil on the charging room floor, and simultaneously sending a chassis lowering instruction to the robot to drive the wireless receiving coil on the robot chassis to descend to a preset close-range coupling position with the ground for wireless charging energy transmission, thereby generating robot charging status data.

[0077] The aforementioned wireless transmitting coil can be a copper coil buried beneath the floor of the charging room, generating an alternating magnetic field when energized. The aforementioned wireless receiving coil can be a coil mounted on the lifting mechanism of the robot chassis, used to receive the magnetic field and convert it into electrical energy. The aforementioned chassis lowering command can be a digital command controlling the robot chassis lifting mechanism to perform a lowering action. The aforementioned close-range coupling position can be the optimal charging distance between the receiving coil and the transmitting coil, typically 5-20mm, to ensure efficient energy transfer. The aforementioned wireless charging energy transfer can be achieved through the principle of electromagnetic induction, transferring electrical energy non-contactly from the transmitting coil to the receiving coil. The aforementioned robot charging status data can be a data packet containing parameters such as charging power, current voltage, current current, coil temperature, and estimated charging time.

[0078] As an example, the aforementioned charging device can close the power supply circuit of the transmitting coil via a relay or solid-state switch to power on the wireless transmitting coil on the charging room floor. A descent command is then sent to the robot controller via a wireless communication module (such as Wi-Fi or UWB), triggering the lifting motor. The transmitting coil then generates an alternating magnetic field, inducing a current in the receiving coil. This current is rectified and regulated to charge the battery. Finally, real-time data from voltage and current sensors is collected to calculate the charging power and the amount of electricity already charged. These data are then packaged into a data frame to obtain the robot's charging status data.

[0079] For example, when the charging device selects wireless charging mode, the charging device closes the relay, energizing the transmitting coil. Simultaneously, it sends a command to the robot to "lower the chassis by 10mm". Upon receiving the command, the robot drives the lifting motor to lower the receiving coil to 10mm above the ground. Charging begins. The controller monitors a voltage of 48V, a current of 20A, and a power of 960W, generating a status data packet, i.e., the robot's charging status data: {"mode": "wireless", "power": 960", "voltage": 48", "current": 20", "temp": 35}.

[0080] The third step involves responding to the charging mode selection instruction of the above-mentioned robotic arm assisted docking mode by performing inverse kinematics calculation on the robot's current pose data to generate the target angle sequence of each joint of the six-axis robotic arm.

[0081] Among them, the robotic arm-assisted docking mode can be a high-power charging method that uses a multi-axis robotic arm to automatically plug and unplug the charging gun. The robot's current pose data can be the robot's position (X, Y) and orientation (Yaw) in the world coordinate system, such as (15.2, 88.7, 92.3°).

[0082] As an example, the charging device described above can input the spatial coordinates of the charging port into an inverse kinematics solver. The solver, based on the DH parameter model of the robotic arm, generates a sequence of target angles for each joint of the six-axis robotic arm using an iterative algorithm (such as the Jacobian matrix method). The spatial coordinates of the charging port can be obtained by adding a fixed relative offset to the robot's pose.

[0083] Fourth, according to the above target angle sequence, control the end effector of the robotic arm to move the charging gun to the robot's charging interface, so as to drive the corresponding robot to the charging coarse positioning area.

[0084] As an example, the aforementioned charging device can convert the target angle sequence into angle commands for the servo motors of each joint, and send them to the driver via a bus (such as EtherCAT) to drive the coordinated movement of the robotic arm's joints, causing the charging gun held at the end effector to move near the charging interface (e.g., within 5cm). Simultaneously, the robot navigates into the coarse positioning area of ​​the charging chamber according to navigation commands.

[0085] The fifth step involves correcting the deviation of the robot in response to the determination that the robot has traveled to the charging coarse positioning area, so as to generate the corrected charging positioning position of the robot.

[0086] As an example, the charging device described above can calculate the robot's actual pose (X', Y', Yaw') using an image recognition algorithm. It then compares this pose with the ideal pose (X0, Y0, Yaw0) to calculate the deviation (ΔX, ΔY, ΔYaw). Finally, it sends fine-tuning movement commands to the robot, driving it forward / backward / turning until the deviation is less than a preset threshold (e.g., ±5mm, ±1°), thus generating a corrected charging positioning position for the robot.

[0087] Step 6: Based on the above-mentioned calibration of the robot's charging positioning position, connect the robot's charging plug to the charging socket of the charging device to obtain the current connection result.

[0088] The current docking result can be a Boolean value, indicating whether the docking was successful (True / False), which can be determined by detecting the docking switch signal or whether the charging circuit is conducting.

[0089] As an example, the aforementioned charging device allows the robotic arm to fine-tune its end effector posture based on the corrected robot position, and slowly insert the charging gun into the robot socket. Once inserted, the mechanical locking mechanism inside the socket activates, and simultaneously, the auxiliary contacts in the charging circuit close. The controller detects this signal, confirms successful docking, and obtains the current docking result.

[0090] Step 7: In response to the determination that the above current docking result represents a successful current docking, real-time status monitoring of the battery pack's voltage and current data is performed within a preset time period to generate the battery pack's charging status and current charge level.

[0091] The preset time period can be the entire time period from the start of charging to the end of charging, or a specific monitoring cycle (such as every 100ms).

[0092] As an example, the aforementioned charging device can close the main power relay to start charging. Simultaneously, it continuously reads the voltage and current data reported by the BMS, calculates and monitors the charging stage in real time using the ampere-hour integration method (e.g., the constant current stage when the voltage has not reached full charge voltage), to generate the battery pack charging status and current charge level.

[0093] Step 8: Package the above-mentioned battery pack charging status, current power level, and robot charging fault level into data to generate robot charging status data.

[0094] As an example, the charging device described above can call a data encapsulation function to fill each data item into JSON, add a verification code, and then send it to the mobile terminal via a wireless network.

[0095] The content in steps one through eight above constitutes an inventive point of this disclosure, solving the technical problem of "inability to adapt to different fault levels, resulting in insufficient robot docking accuracy and insertion failure." Factors leading to this inability to adapt to different fault levels and insufficient robot docking accuracy often include: faults occurring during charging; a single charging mode failing to respond promptly and adapting to different fault levels, posing safety hazards; and the inability to remotely perceive charging status information, resulting in insufficient robot docking accuracy and insertion failure. Solving these factors allows for adaptation to different fault levels and improves robot docking accuracy. To achieve this, firstly, wireless charging or robotic arm charging is dynamically selected based on the fault level, solving the problem of a single charging mode being unable to adapt to different fault levels, improving charging success rate, and enhancing emergency power replenishment capabilities in fault conditions. Coarse positioning, visual correction, and finally robotic arm fine-tuning improve docking accuracy from ±5cm to ±2mm, achieving an insertion success rate >99%, thereby improving robot docking accuracy and preventing insertion failure. Furthermore, real-time monitoring of voltage, current, and temperature ensures a safe and controllable charging process, extends battery life, and reduces the possibility of safety hazards. Finally, by packaging the battery pack charging status, current battery level, and robot charging fault level into a data set to generate robot charging status data, maintenance personnel can remotely monitor the robot, reducing the frequency of on-site inspections. This allows the system to adapt to different fault levels and improves robot docking accuracy.

[0096] Step 205: The mobile terminal is configured to render the received robot charging status data and the pre-collected slag bag temperature data to generate a temperature change curve.

[0097] In some embodiments, the mobile terminal is configured to render the received robot charging status data and the pre-collected slag bag temperature data to generate a temperature change curve.

[0098] The aforementioned mobile terminal can be a backend system or handheld device used for data display and human interaction. The slag bag temperature data can be the temperature values ​​of three measuring points for each slag bag collected by a dual-spectrum thermal imager. The temperature change curve can be a graph with time on the horizontal axis and temperature on the vertical axis, displaying the historical trend of slag bag temperature changes.

[0099] As an example, the aforementioned mobile terminal can call a graphics library to plot the received robot charging status data and pre-collected slag bag temperature data on a coordinate axis, connecting them into a smooth curve. For instance, the mobile terminal receives robot charging status data (such as displaying that the robot is charging), while the background database contains temperature records of slag bag "A3-12" for the past 24 hours. The terminal software reads these records and plots a curve on the screen showing the temperature slowly rising from 60℃ to 68.5℃ from yesterday to today. The operator can see both the robot's charging status and the slag bag temperature changes on the same screen.

[0100] Optionally, the received robot charging status data and pre-collected slag bag temperature data are rendered to generate a temperature change curve, including: The first step is to perform coordinate mapping between the received robot charging status data and the pre-collected slag bag temperature data to generate a robot charging temperature dataset.

[0101] Among them, the aforementioned robot charging temperature dataset can be a comprehensive dataset in which the robot charging status data and slag bag temperature data are associated with specific spatial locations after coordinate mapping.

[0102] As an example, the aforementioned mobile terminal can use a pre-calibrated thermal imager-robot coordinate transformation matrix to convert the pixel coordinates (u, v) of the slag bag measuring point on the thermal image into coordinates (X, Y) in the world coordinate system.

[0103] The second step is to perform pseudo-color rendering on the above robot charging temperature dataset to generate temperature change curves, wherein the temperature change curves include the temperature change of each slag bag.

[0104] As an example, the mobile terminal described above can fill the pixels corresponding to the charging temperature data of each robot with color according to its current temperature value and a preset color lookup table (e.g., blue < 60℃, green 60-65℃, yellow 65-68℃, red > 68℃). Then, it can call graphics library functions (such as Qt Charts) to plot these points on a temperature change curve, thus obtaining the temperature change curve.

[0105] The following is for reference. Figure 3 It shows a schematic diagram of the structure of an electronic device 300 (e.g., a computing device) suitable for implementing some embodiments of the present disclosure. Figure 3 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0106] like Figure 3As shown, the electronic device 300 may include a processing unit 301 (e.g., a central processing unit, a graphics processor, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) or a program loaded from a storage device 308 into a random access memory (RAM). The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0107] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0108] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

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

[0110] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0111] The aforementioned computer-readable medium may be included within the aforementioned electronic device; or it may exist independently and not assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to: configure the aforementioned battery detection device to: perform fusion processing on a pre-acquired multi-source environmental perception dataset to generate robot current pose data with semantic labels, and send the robot current pose data to the aforementioned fault classification device, wherein the aforementioned multi-source environmental perception dataset includes: robot point cloud data, radar echo signals, and visual positioning images; and configure the aforementioned fault alarm device to: perform threshold comparison on a pre-acquired raw battery parameter dataset to generate a power alarm signal, and send the power alarm signal to the aforementioned fault classification device. The device includes a battery raw parameter dataset comprising battery pack voltage data and battery pack current data. The fault classification device is configured to: perform fault matching on received power alarm signals, received robot current pose data, and real-time fault codes to generate a robot charging fault level, and send the robot charging fault level to the charging device. The charging device is configured to: generate robot charging status data based on the received robot charging fault level, and transmit the robot charging status data to a mobile terminal. The mobile terminal is configured to: render the received robot charging status data and pre-collected slag bag temperature data to generate a temperature change curve.

[0112] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0113] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0114] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0115] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. An automatic charging and fault classification system for industrial robots, characterized in that, The automatic charging and fault emergency handling system includes: battery detection equipment, fault alarm equipment, fault classification equipment, charging device, and mobile terminal, wherein: The battery detection device is configured to: perform fusion processing on a pre-collected multi-source environmental perception dataset to generate robot current pose data with semantic labels, and send the robot current pose data to the fault classification device, wherein the multi-source environmental perception dataset includes: robot point cloud data, radar echo signals and visual positioning images. The fault alarm device is configured to: perform threshold comparison on a pre-acquired battery raw parameter dataset to generate a power alarm signal, and send the power alarm signal to the fault classification device, wherein the battery raw parameter dataset includes: battery pack voltage data and battery pack current data; The fault classification device is configured to: perform fault matching on the received power alarm signal, the received robot current pose data and real-time fault code to generate a robot charging fault level, and send the robot charging fault level to the charging device. The charging device is configured to: generate robot charging status data based on the received robot charging fault level, and transmit the robot charging status data to a mobile terminal. The mobile terminal is configured to render the received robot charging status data and pre-collected slag bag temperature data to generate a temperature change curve.

2. The method according to claim 1, characterized in that, The battery testing device is further configured to: Receive robot point cloud data, radar echo signals, and visual positioning images collected by a preset lidar; The robot point cloud data is filtered to generate filtered robot point cloud data; The filtered robot point cloud data is registered to generate a 3D point cloud map of the environment; Target detection is performed on the radar echo signal to obtain dynamic obstacle location information; Feature extraction is performed on the visual positioning image to generate visual positioning image features; The visual positioning image features are processed to calculate the pose, and the visual odometry data of the robot is obtained. The environmental 3D point cloud map, the dynamic obstacle location information, and the visual odometry data are fused together to generate robot current pose data with semantic tags.

3. The method according to claim 1, characterized in that, The fault alarm device is further configured to: Receive pre-acquired battery pack voltage and battery pack current data; The battery pack voltage data and the battery pack current data are integrated to generate the battery state of charge value; The battery state of charge value is compared with a preset low charge threshold to obtain a threshold comparison result; In response to determining that the threshold comparison result indicates that the battery state of charge value is less than or equal to a preset low battery threshold, a battery alarm signal is triggered.

4. The method according to claim 1, characterized in that, The fault classification device is further configured to: The received power alarm signal, the received robot current pose data, and the real-time fault code are weighted and analyzed to generate robot weight data. Fault tree matching is performed on the robot weight data to generate a robot charging fault instruction; The power alarm signal is processed by task priority preemption and priority marking is performed on the power alarm signal to obtain the priority power alarm signal; Based on the priority power alarm signal and the robot charging fault command, the robot's current pose data is path-bound with the preset charging room coordinates to generate a robot charging fault level containing a sequence of path points.

5. The method according to claim 1, characterized in that, The mobile terminal is further configured to: The received robot charging status data and the pre-collected slag bag temperature data are mapped to coordinates to generate a robot charging temperature dataset. The robot charging temperature dataset is rendered using pseudo-color rendering to generate temperature change curves, wherein the temperature change curves include the temperature change of each slag bag.

Images