Repositioning method and device based on pile position perception and storage medium

Abstract

The invention discloses a repositioning method and device based on pile position perception and a storage medium, and relates to the technical field of repositioning, the method comprises the following steps: according to current data between a robot and a charging pile, Hall sensor data and pile code identification data, determining a first pile-on confidence coefficient of the robot; comparing the first on-pile confidence coefficient with a preset on-pile confidence coefficient threshold value; when the first on-pile confidence coefficient is smaller than the on-pile confidence coefficient threshold value, it is determined that the on-pile state of the robot is incredible, and a first relocation request is generated according to a relocation request identifier, a timestamp and an effective token; the first repositioning request is sent to the robot, the first repositioning request is used for controlling the robot to execute a preset repositioning algorithm, and a positioning result is obtained according to the repositioning algorithm. According to the invention, the accuracy of on-pile judgment and repositioning of the robot can be improved.

Description

Technical Field

[0001] This application relates to the field of relocation technology, and in particular to a relocation method, device and storage medium based on pile position sensing. Background Technology

[0002] Currently, in scenarios where automated equipment such as robots needs to perform repositioning, the determination of whether the equipment is stably docked at the pile and whether the initial pose can be directly reused to initiate the repositioning process typically adopts a "manual click trigger" operation mode. Maintenance personnel visually observe the physical position of the equipment and the docking status of the pile to determine whether the equipment is on the pile, and then manually click the positioning button on the control system to trigger the repositioning or initial pose issuance process. This method, relying on manual decision-making, is prone to false on-pile misjudgments. For example, if the equipment only slightly touches the pile without stable docking or the contact point is only partially made, it may be judged as being on the pile. Issuing the initial pose after a misjudgment will lead to a deviation in the positioning reference.

[0003] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0004] The main objective of this application is to provide a relocation method, device, and storage medium based on pile location perception, aiming to solve the technical problem of how to improve the accuracy of robot pile identification and relocation.

[0005] To address the aforementioned problems, this application provides a relocation method based on pile location sensing, which includes: The robot's first confidence level at the charging pile is determined based on the current data, Hall sensor data, and pile code identification data between the robot and the charging pile. The first confidence level at the stake is compared with the preset confidence threshold at the stake. When the first confidence level of being on the dock is less than the confidence level threshold of being on the dock, the docking status of the robot is determined to be untrusted, and a first relocation request is generated based on the relocation request identifier, timestamp, and valid token. The first relocation request is sent to the robot. The first relocation request is used to control the robot to execute a preset relocation algorithm and obtain a positioning result according to the relocation algorithm.

[0006] In one embodiment, after the step of comparing the first on-pile confidence level with a preset on-pile confidence threshold, the relocation method based on pile location awareness further includes: If the first confidence level of being on the ground is greater than or equal to the confidence level threshold of being on the ground, then the robot's on-the-ground status is determined to be reliable. Once the on-the-stake state is determined to be reliable, the preset initial pose is determined as the robot's current pose, and the current pose is sent to the robot.

[0007] In one embodiment, the step of determining a preset initial pose as the robot's current pose and sending the current pose to the robot when the on-stake state is determined to be reliable includes: Once the on-stake state is determined to be reliable, the firmware version, mobility data, feature coverage data, and posture covariance of the robot are obtained. If the firmware version is within the preset supported version list, the accessibility data is greater than or equal to the preset accessibility threshold, the feature coverage data is greater than or equal to the preset feature coverage threshold, and the attitude covariance is less than or equal to the preset attitude covariance threshold, then the verification is confirmed to be successful. The initial pose is determined as the current pose of the robot, and the current pose is sent to the robot.

[0008] In one embodiment, prior to the step of generating a first relocation request based on the relocation request identifier, timestamp, and valid token, the relocation based on stake location awareness further includes: The feature string is obtained by concatenating the map version number, the on-pile confidence level, the charging status indicator, the IMU data, the signal strength of the wireless model, and the light level. The feature string is hashed based on a preset hash algorithm, and the resulting hash value is determined as the current state fingerprint. The current state fingerprint is compared with the historical state fingerprint. If the difference between the current state fingerprint and the historical state fingerprint is greater than or equal to a preset state fingerprint difference threshold, or if the current time is not within a preset cooling window, then the relocation request identifier is generated according to a preset incrementing rule.

[0009] In one embodiment, after the step of generating a first relocation request based on the relocation request identifier, timestamp, and valid token, the relocation method based on stake location awareness further includes: When a relocation receipt from the robot is received within a preset period, the relocation receipt is parsed to obtain the valid token and the relocation request identifier. The valid token is parsed based on a preset key to obtain the token generation time and token validity period; Based on the token generation time and the token validity period, determine whether the current time is within the token validity period, and determine whether the relocation receipt is the latest receipt based on the relocation request identifier; If the token is valid and the receipt is the latest one, then the relocation receipt is confirmed to be valid, and the robot is controlled to update the relocation result on the user interface.

[0010] In one embodiment, after the steps of receiving a relocation receipt from the robot within a preset period, parsing the relocation receipt to obtain the valid token and the relocation request identifier, the relocation method based on pile location awareness further includes: If the relocation receipt is not received within the specified period, or if the relocation receipt is invalid, the relocation request identifier and the valid token are updated. Based on the updated valid token and relocation request identifier, a second relocation request is generated and sent to the robot.

[0011] In one embodiment, after the step of generating a first relocation request based on the relocation request identifier, timestamp, and valid token, the relocation method based on stake location awareness further includes: When the number of relocation failures reaches the preset maximum number of failures, a failure fingerprint is generated based on the environment snapshot information; The failure fingerprint is matched with a preset recovery parameter strategy library to determine the corresponding recovery parameters; Based on the recovery parameters and preset information gain actions, an environmental data acquisition command is generated and sent to the robot to trigger the robot to acquire environmental data and perform relocation based on the obtained environmental data.

[0012] In one embodiment, after the steps of generating an environmental data acquisition command based on the recovery parameters and a preset information gain action, and sending the environmental data acquisition command to the robot, the relocation method based on pile location perception further includes: If relocation based on the environmental data fails, a return path is generated based on the UWB anchor point coordinates, RFID tag location, or visual landmark features. The return path is sent to the robot to trigger the robot to travel to the charging pile location based on the return path; Once it is determined that the robot has returned to the charging station location, a second confidence level of the robot's presence at the charging station is determined; If the second confidence level of being on the stake is greater than or equal to the confidence level threshold of being on the stake, then the preset initial pose is determined as the current pose of the robot; If the second confidence level of being on the stake is less than the confidence level threshold of being on the stake, then the point of interest is determined based on the preset whitelist, and the initial positioning reference is determined based on the point of interest.

[0013] In addition, to achieve the above objectives, this application also proposes a repositioning device based on pile position sensing, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the repositioning method based on pile position sensing as described above.

[0014] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the pile position sensing relocation method as described above.

[0015] This application provides a relocation method based on pile location sensing. It integrates current, Hall sensor, and pile code identification data to calculate the first confidence level of being on the pile, replacing traditional qualitative judgment with quantitative values ​​to improve the accuracy of determining the on-the-pile status and avoid the random errors of a single data dimension. By comparing the confidence level with a preset threshold, it achieves state layering and triggers relocation for untrusted states with insufficient confidence. The generated first relocation request is configured with a globally unique identifier, a precise timestamp, and an encrypted valid token to ensure the traceability and legitimacy of the request. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 A schematic diagram of the first process for the relocation method of pile location sensing in this application; Figure 2 A second flowchart illustrating the relocation method for pile location sensing in this application; Figure 3 This is a schematic diagram of the hardware operating environment involved in the relocation method for pile location sensing in the embodiments of this application.

[0019] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0021] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0022] To achieve the above objectives, this application proposes a relocation method based on charging pile location perception. The method includes: determining a first on-pile confidence level for the robot based on current data, Hall sensor data, and charging pile code identification data between the robot and the charging pile; comparing the first on-pile confidence level with a preset on-pile confidence threshold; determining the robot's on-pile status as untrusted when the first on-pile confidence level is less than the on-pile confidence threshold; generating a first relocation request based on a relocation request identifier, timestamp, and valid token; and sending the first relocation request to the robot, wherein the first relocation request is used to control the robot to execute a preset relocation algorithm and obtain a positioning result based on the relocation algorithm.

[0023] Currently, in scenarios where automated equipment such as robots needs to perform repositioning, the determination of whether the equipment is stably docked at the pile and whether the initial pose can be directly reused to initiate the repositioning process typically adopts a "manual click trigger" operation mode. Maintenance personnel visually observe the physical position of the equipment and the docking status of the pile to determine whether the equipment is on the pile, and then manually click the positioning button on the control system to trigger the repositioning or initial pose issuance process. This method, relying on manual decision-making, is prone to false on-pile misjudgments. For example, if the equipment only slightly touches the pile without stable docking or the contact point is only partially made, it may be judged as being on the pile. Issuing the initial pose after a misjudgment will lead to a deviation in the positioning reference.

[0024] This application provides a relocation method based on pile location sensing. It integrates current, Hall sensor, and pile code identification data to calculate the first confidence level of being on the pile, replacing traditional qualitative judgment with quantitative values ​​to improve the accuracy of determining the on-the-pile status and avoid the random errors of a single data dimension. By comparing the confidence level with a preset threshold, it achieves state layering and triggers relocation for untrusted states with insufficient confidence. The generated first relocation request is configured with a globally unique identifier, a precise timestamp, and an encrypted valid token to ensure the traceability and legitimacy of the request.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with network communication and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or apparatus capable of performing the above functions. The following description uses a pile position sensing repositioning device as an example to illustrate this embodiment and the subsequent embodiments.

[0026] Based on this, the embodiments of this application provide a relocation method based on pile location sensing, referring to... Figure 1 , Figure 1This is a flowchart illustrating the first embodiment of the relocation method for pile location sensing in this application.

[0027] In this embodiment, the relocation method for pile location sensing includes steps S10 to S40: Step S10: Determine the robot's first on-pile confidence level based on the current data, Hall sensor data, and pile code identification data between the robot and the charging pile.

[0028] It should be noted that current data refers to the real-time current value detected in the docking circuit between the robot and the charging pile, reflecting the electrical connection status between the two. Hall sensor data refers to the switch / level signals collected by Hall sensors, reflecting the mechanical alignment status between the equipment and the charging pile. This is used to determine whether the mechanical structure of the equipment and the charging pile is properly docked, avoiding false docking issues caused by normal electrical connection but mechanical misalignment. Charging pile code identification data refers to the unique identification data of the charging pile identified by the equipment through vision, RFID, etc., used to verify whether the charging pile docked to the equipment is a preset legitimate pile, avoiding positioning deviations or charging failures caused by docking the equipment with the wrong pile.

[0029] In this embodiment, the confidence level of the device at the pile is calculated by fusing current data, Hall sensor data, and pile code identification data to determine the device's status at the pile. When the status at the pile is unreliable, the device is repositioned through a repositioning request mechanism to ensure the accuracy of the positioning reference.

[0030] After the robot is powered on and attempts to connect to the charging station, the control module of the charging station or device automatically starts current acquisition. If the sensor output is an analog signal, it is converted into a digital current value through an AD converter. The raw digital current value is filtered to remove spike noise caused by electromagnetic interference, such as instantaneous current pulses, to obtain stable current data.

[0031] Hall effect proximity sensors are installed at the mechanical contact points of the charging pile or at the stopping limit points of the equipment. The sensors are connected to the robot's MCU for communication. When the equipment completes mechanical alignment with the charging pile, the sensing surface of the Hall effect sensor detects the metal trigger and outputs a high level (1). When not aligned, it outputs a low level (0). The level status of the Hall effect sensor is monitored, and the collected level status is converted into a 0 / 1 digital identifier. The data is then synchronously uploaded to the host computer through the same communication link as the current data. The host computer associates the Hall effect status data with the current data at the same timestamp and binds the device ID and the charging pile ID.

[0032] The device is equipped with a vision camera, RFID reader, or laser scanner; a uniquely identified charging pile code is pre-installed on the charging pile itself; when the distance between the robot and the charging pile is less than a preset threshold, a data acquisition command is triggered; the camera captures an image of the charging pile code, and the code string is extracted based on image preprocessing and decoding algorithms; the RFID reader transmits radio frequency signals to read the ID number of the charging pile tag and converts it into a charging pile code identifier. The decoded charging pile code is verified to be in a valid format; invalid codes are discarded. The charging pile code string and its recognition confidence level are uploaded to the host computer, which reads a preset charging pile code whitelist database to complete the identity matching verification; the successful / failed matching status of the charging pile code is associated with and stored with the original charging pile code string.

[0033] The current data is mapped to a confidence score of 0-1 according to a preset range. For example, 30-300mA is the valid range, corresponding to a score of 0.8-1.0; <30mA or >300mA is the abnormal range, corresponding to a score of 0-0.3. Hall sensor data is scored according to a state mapping. Mechanical in place = 1.0, not in place = 0. For pile code data, it is checked whether the pile code is in a preset whitelist. If the match is successful, the score is 1.0; if the match is not successful, the score is 0. A weighted sum is performed according to preset weights. For example, the preset weights are current 0.4, Hall 0.3, and pile code 0.3 to obtain the first on-pile confidence value.

[0034] Step S20: Compare the first confidence level at the pile with the preset confidence level at the pile.

[0035] In this embodiment, the credibility standard of the staking state is quantified by a preset threshold. The preset threshold is read from the configuration library, and the first staking confidence is compared with the threshold. If the confidence is greater than or equal to the threshold, the staking state is determined to be credible, and the process of directly reusing the initial pose is triggered. If the confidence is less than the threshold, the staking state is determined to be untrustworthy, and an untrustworthy staking identifier is generated.

[0036] Step S30: When the first on-the-dot confidence level is less than the on-the-dot confidence level threshold, the on-the-dot state of the robot is determined to be untrustworthy, and a first relocation request is generated based on the relocation request identifier, timestamp, and valid token.

[0037] In this embodiment, the relocation request identifier (reloc_req_id) is generated by a counter, which is initially set to 0 and automatically increments by 1 with each request. The timestamp (lamport_ts) is generated based on a logical clock mechanism. The valid token (reloc_token) uses an encryption algorithm and is issued with the system's private key. The token contains the relocation request identifier, the request initiation timestamp, a configurable validity period, and a unique device ID. After generation, it exists as an encrypted string and is used for request identity verification and timeliness control to prevent tampering and forgery. The relocation request identifier, timestamp, valid token, and preset relocation algorithm parameters, such as matching thresholds and sensor acquisition frequencies, are structurally encapsulated to generate a standardized first relocation request data packet. By constructing a unique, time-controllable, and secure verifiable credentialed request, interference from illegal, duplicate, and expired requests to the positioning process is avoided at the source. Specifically, the globally unique request identifier enables request deduplication and end-to-end traceability, the logical timestamp ensures request sequence and freshness, and the asymmetric encryption token completes identity verification and anti-tampering, ultimately ensuring that every relocation request is verifiable.

[0038] Step S40: Send the first relocation request to the robot. The first relocation request is used to control the robot to execute a preset relocation algorithm and obtain a positioning result according to the relocation algorithm.

[0039] In this embodiment, the host computer encapsulates the request data packet at the protocol layer according to a preset communication protocol, such as CANopen or TCP / IP, and sends the encapsulated data packet to the target robot. During the transmission process, transmission parameters such as the number of bytes sent and the link type are recorded. After the data packet is sent, the host computer starts a timeout timer. If no acknowledgment information is received from the robot before the preset timeout threshold is exceeded, the first relocation request is resent.

[0040] After receiving a data packet from the host computer, the robot communication module performs a CRC-32 check to verify if the checksum at the end of the packet matches the locally calculated value. If they do not match, the data packet transmission is deemed abnormal, discarded without feedback, and the host computer triggers a retry due to timeout. If the verification passes, the core credentials in the data packet are parsed. A valid token is decrypted using a pre-set system public key, confirming that the token was issued by the host computer's private key. The generation time and validity period of the token are checked to ensure they do not exceed the current time, preventing expired requests. The timestamp is also confirmed to be greater than the historical timestamp corresponding to the request identifier recorded locally, preventing duplicate execution of old requests. If verification fails, an invalid credentials receipt is generated and sent to the host computer. If verification succeeds, the relocation algorithm parameters in the data packet are parsed.

[0041] Based on the analyzed algorithm parameters, the local sensor cluster is standardized and started to ensure that the data acquisition meets the requirements of the positioning algorithm. The LiDAR starts at the preset acquisition frequency in the parameters, outputs point cloud data, and simultaneously performs pass-through filtering to remove ground noise and voxel filtering downsampling to retain effective environmental feature points. The vision sensor adjusts its hardware configuration according to the exposure / gain values ​​in the parameters and acquires RGB images. The IMU sensor synchronously acquires the robot's angular velocity and acceleration data for attitude calibration and to compensate for the dynamic errors of laser / vision positioning. The locally preset site map is loaded, and the preset fusion positioning algorithm, such as ICP point cloud matching and visual feature fusion, is run to register the real-time laser point cloud with the global map and calculate the robot's initial position deviation. The real-time visual feature vector is extracted and matched with feature points in the global map, and the matching results are corrected to reduce the drift error of pure laser positioning. The attitude data acquired by the IMU is fused to calibrate the robot's roll angle (φ), pitch angle (θ), and yaw angle (ψ), and finally, a positioning result containing global coordinates (x / y / z), three-dimensional attitude angles, and positioning accuracy is generated. The receipt data packet is encapsulated in the same format as the request packet and then transmitted back to the host computer via the original communication link.

[0042] After receiving the acknowledgment packet, the host computer first verifies the CRC-32 code to confirm that the data has not been lost or tampered with. Then, it parses the relocation request identifier, associates it with the request record that has been sent and is awaiting acknowledgment, and stops the timeout timer for that request. The location data, credential information, and transmission parameters in the acknowledgment are stored in the real-time database, and the request status corresponding to the relocation request identifier is marked as acknowledged. If no acknowledgment is received after the timeout timer expires, the request is determined to have timed out, the status is updated to "timeout without acknowledgment," and the timeout retry process is triggered.

[0043] In this embodiment, the first on-site confidence level is calculated by integrating current, Hall sensor, and pile code identification data. Quantitative values ​​replace traditional qualitative judgments, improving the accuracy of on-site status determination and avoiding random errors from a single data dimension. Status stratification is achieved by comparing the confidence level with a preset threshold. Relocation is triggered for untrusted states with insufficient confidence. The generated first relocation request is configured with a globally unique identifier, a precise timestamp, and an encrypted valid token, ensuring the traceability and legitimacy of the request.

[0044] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description and will not be repeated hereafter. Furthermore, after step S20, steps S50-S60 may also be included: Step S50: When the first confidence level of being on the ground is greater than or equal to the confidence level threshold of being on the ground, the robot's on-the-ground status is determined to be reliable.

[0045] In this embodiment, the target robot's model and the type of the currently docked pile are read, and the corresponding threshold is matched from the configuration library. If no match is found, the global default threshold is used. The pile ID of this docking is obtained and verified to be consistent with the pile currently physically docked to by the robot. If the pile ID corresponding to the pile code matches the read pile ID, it is determined to be consistent; otherwise, it is determined that the pile ID does not match, the determination is terminated, and a pile docking anomaly alarm is triggered. The confidence value in the pile determination data source is compared with the threshold. If the first on-pile confidence is ≥ the threshold, an on-pile status reliable identifier is generated and associated with the robot's unique ID and determination timestamp, and stored in the local cache.

[0046] Step S60: When it is determined that the on-the-stake state is reliable, the preset initial pose is determined as the current pose of the robot, and the current pose is sent to the robot.

[0047] In this embodiment, the host computer retrieves the corresponding initial pose data from the initial pose library based on the target robot's ID and the current docking position ID. The initial pose data includes: x-coordinate, y-coordinate, attitude angle, pose accuracy level, and data update timestamp in the global coordinate system. The system verifies whether the pose coordinates are within the legal range of the site's global coordinate system to avoid exceeding the site boundaries; and whether the data update timestamp is within a preset period to ensure that the initial pose has not become invalid due to site changes. If both conditions are met, the initial pose is confirmed as valid and marked as the robot's current pose. If either condition is not met, the initial pose is recorded as invalid, triggering a repositioning process.

[0048] The host computer encapsulates the current pose data according to the format supported by the robot, generating a standardized data packet containing the valid current pose. The encapsulated current pose data packet is sent to the target robot via the original communication protocol. After transmission, a transmission timeout timer is started. If a pose reception success acknowledgment is received from the robot within the preset timeout period, the host computer stops the timer, parses the robot confirmation information in the acknowledgment, and updates the robot status to "initial pose directly usable successfully." If a pose parsing failure acknowledgment is received, the data packet is recapsulated and transmitted; if it still fails, an alarm is recorded. If no acknowledgment is received within the timeout period, a timeout retry is triggered. If the retry fails, the transmission timeout is recorded, and the system switches to the relocalization process.

[0049] In one feasible implementation, step S60 may include steps S61 to S63: Step S61: When the on-stake state is determined to be reliable, obtain the robot's firmware version, accessibility data, feature coverage data, and attitude covariance.

[0050] In this embodiment, the robot's firmware version is the version number of the embedded software running at the robot's core. It contains key code such as the robot's core control logic, hardware drivers, and communication protocol adaptation, directly determining the robot's ability to support functions such as initial pose direct use, sensor data parsing, and algorithm execution. The host computer sends a firmware version query command to the robot via a communication protocol. The command includes the robot's unique ID and query timeout threshold. After receiving the command, the robot reads the pre-burned firmware version number from its local flash memory. The robot then encapsulates the version number into a standardized data packet and sends it back to the host computer.

[0051] Accessibility data is an indicator that quantifies the physical access space of the robot in the charging pile area. The value ranges from 0 to 1, with values ​​closer to 1 indicating more sufficient access space. It reflects the degree to which the robot, after docking with the charging pile, has no obstacles around it and its own movement is uninterrupted, preventing abnormal robot movement after direct use of the initial pose due to insufficient access space. The host computer issues an accessibility data collection command, triggering the robot's sensors to scan the surrounding environment of the charging pile. The robot constructs a two-dimensional grid map of the charging pile area based on the scan data, marking the grid status as accessible / inaccessible. The percentage of accessible grids within the maximum space range when moving in the initial pose is calculated; this is the accessibility data. For example, if there are 100 grids and 90 are accessible, the accessibility is 0.9.

[0052] Feature coverage data is an indicator that quantifies the number of feature points in the environment surrounding the pile location. Its value ranges from 0 to 1, with values ​​closer to 1 indicating richer features. Feature points include stable features that can be identified by sensors, such as wall corners, pile edges, and ground markings. It serves as the basis for the robot to fine-tune its posture based on its initial pose and avoid pose drift. The host computer issues a feature coverage acquisition command, triggering the robot's LiDAR / visual sensor to collect data on the environment surrounding the pile location. The robot then extracts features from the collected data, including edge points and planar points in the point cloud data; and corner points, contour points, and QR codes in the image. The ratio of the number of effective feature points within a preset radius centered on the robot's initial pose to the preset full feature point count is determined as the feature coverage data.

[0053] Attitude covariance is an indicator that quantifies the attitude stability of a robot at a stationary position. The smaller the value, the more stable the attitude. It reflects the dispersion of roll, pitch, and yaw angles collected by the robot's IMU (Inertial Measurement Unit), and directly determines the reliability of the initial pose. The host computer issues an attitude covariance acquisition command, triggering the robot's IMU sensors to collect attitude data (roll, pitch, and yaw angles). The variance of each of the three sets of collected angle data is calculated, and the average of the three variances is taken to obtain the attitude covariance.

[0054] In this embodiment, a verification data acquisition command is generated based on the robot ID, acquisition items (firmware version, accessibility, feature coverage, and attitude covariance), acquisition timeout threshold, and command identifier. After the command is generated, the host computer sends it to the target robot through a preset communication protocol and simultaneously starts the acquisition timeout timer. After receiving the command, the robot synchronously acquires firmware version, accessibility, feature coverage, and attitude covariance data, encapsulates and sends it back. After receiving the receipt data packet, the host computer's communication module parses the data packet to obtain the firmware version, accessibility, feature coverage, and attitude covariance.

[0055] Step S62: When the firmware version is in the preset supported version list, the accessibility data is greater than or equal to the preset accessibility threshold, the feature coverage data is greater than or equal to the preset feature coverage threshold, and the attitude covariance is less than or equal to the preset attitude covariance threshold, then the verification is determined to be successful.

[0056] Step S63: Determine the initial pose as the current pose of the robot, and send the current pose to the robot.

[0057] In this implementation, the verification rules matching the target robot model are obtained, including: performing verification on each of the following: a preset supported version list, a passability threshold, a feature coverage threshold, and a posture covariance threshold. The robot firmware version is checked against the supported version list; if a match is found, the verification passes; otherwise, firmware version incompatibility is recorded. If the passability is greater than or equal to the passability threshold, the verification passes; otherwise, insufficient passability is recorded. If the feature coverage is greater than or equal to the feature coverage threshold, the verification passes; otherwise, insufficient feature coverage is recorded. If the posture covariance is less than or equal to the feature coverage threshold, the verification passes; otherwise, posture stability is recorded as substandard. If all four verification results pass, an initial pose direct-use verification pass flag is generated; if any item fails, a verification failure flag is generated, triggering the relocation process.

[0058] In this embodiment, the confidence level of the robot is calculated by multi-dimensional data weighting and a threshold is set to determine the trustworthy state, thus achieving quantitative and accurate identification of the staking state. The trustworthy state is further verified by four checks, including firmware version and environmental accessibility, to ensure the reliability of direct use of the initial pose and reduce unnecessary relocation costs. When direct use verification fails or an anomaly is confirmed, a relocation request with a unique identifier, timestamp, and expiration token is generated and a fallback process is triggered. This improves the efficiency and stability of robot pose calibration and ensures the uniqueness, timeliness, and security of the relocation request through a token-based design, effectively balancing system resource consumption and anomaly handling capabilities.

[0059] Based on the first embodiment of this application, in the third embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 Before step S30, steps A10 to A30 may also be included: Step A10: Concatenate the following strings according to the map version number, the on-pile confidence level, the charging status indicator, the IMU data, the signal strength of the wireless model, and the light level to obtain the feature string.

[0060] In this embodiment, the host computer generates a data acquisition command based on the robot ID and sends it to the robot via the communication link. After receiving the command, the robot synchronously acquires IMU data, wireless signal strength, and light level, and combines them with the charging status identifier transmitted back by the charging pile, encapsulates them into a data packet, and sends it back to the host computer. The host computer retrieves the map version number and on-pile confidence from the local module. It performs validity checks on each type of data. If the validation of a single type of data fails, it triggers re-acquisition. If the re-acquisition fails, it uses the default value of the data item and records the data acquisition anomaly log.

[0061] The validated data is uniformly formatted. The map version number and on-pile confidence level retain their original strings, the charging status identifier is converted from a boolean value to a string, IMU data array elements are concatenated into strings, and the original integers of wireless signal strength and illumination level are converted into strings. All formatted data is concatenated in a preset fixed order using preset delimiters to generate a unique feature string. The length of the feature string is verified to be within the preset character limit, and the number of delimiters is also verified. If they do not meet the requirements, the data is reformatted and concatenated to ensure a unique and non-redundant string structure.

[0062] Step A20: Perform hash calculation on the feature string based on a preset hash algorithm, and determine the resulting hash value as the current state fingerprint.

[0063] Step A30: Compare the current state fingerprint with the historical state fingerprint. If the difference between the current state fingerprint and the historical state fingerprint is greater than or equal to a preset state fingerprint difference threshold, or if the current time is not within a preset cooling window, then generate the relocation request identifier according to a preset incrementing rule.

[0064] In this embodiment, before generating the first relocation request, it is verified whether there are multiple relocation requests to avoid frequent relocation and thus consume robot computing power; and to prevent repeated triggering in a short period of time from causing robot lag, thus ensuring the continuity of robot operation.

[0065] The system repeatedly calls a preset hash algorithm, using the feature string as input, to perform hash calculations. The hash algorithm can be MD5, SHA-256, etc. The resulting hash value is used as the current state fingerprint, which is then associated with the robot ID and a timestamp is generated and stored.

[0066] Retrieve the most recently generated historical state fingerprint from the cache based on the robot ID. Calculate the absolute difference between the current state fingerprint and the historical state fingerprint; the larger the difference, the more significant the change in robot state. Read the preset state fingerprint difference threshold in the configuration library. If the calculated difference is greater than or equal to the threshold, it is determined that the robot state has undergone a substantial change. Read the preset cooling window in the configuration library, which is the minimum interval between two consecutive relocation requests from the robot, and the timestamp of the robot's last generation of a relocation request identifier. Calculate the difference between the current time and this timestamp: if the current time is not within the cooling window (i.e., the interval is greater than or equal to the preset cooling window duration), it is determined that the cooling window has expired, and a relocation request identifier can be generated; if it is still within the cooling window, it is determined that it is within the cooling window, and no relocation request identifier is generated yet. If it is still within the cooling window and the state fingerprint has not undergone a substantial change, the generation of a new relocation request is rejected, and the historical state fingerprint is updated to the current fingerprint; if it is not within the cooling window or the state fingerprint has undergone a substantial change, the relocation request identifier generation process is triggered.

[0067] Based on the first embodiment of this application, in the fourth embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 After step S30, steps A40 to A70 may also be included: Step A40: When a relocation receipt from the robot is received within a preset period, the relocation receipt is parsed to obtain the valid token and the relocation request identifier.

[0068] In this embodiment, a preset receipt reception period is obtained and associated with a relocation request identifier. The host computer detects the relocation receipt data packets transmitted back by the robot. For each received data packet, the relocation request identifier is extracted and matched with the corresponding monitoring period. If the corresponding receipt data packet is detected within the preset period, it is determined that a receipt has been received within the period. Receipt parsing and verification are then performed, and the validity period of the token is verified.

[0069] In one feasible implementation, after step A40, the method may further include: if the relocation receipt is not received within the period, or if the relocation receipt is invalid, updating the relocation request identifier and the valid token; generating a second relocation request based on the updated valid token and the relocation request identifier, and sending the second relocation request to the robot.

[0070] In this implementation, when no receipt is received within the period or the receipt is invalid, the host computer updates the relocation request identifier according to preset rules, calls a counter to perform an atomic increment operation on the request sequence number of the corresponding robot, and generates an updated relocation request identifier. A valid token is reissued using the private key, with the new token's generation time being the current system timestamp. The updated relocation request identifier and the valid token are associated with the robot ID and stored in a cache or database. The original request status is marked as invalid, and the new request status is marked as pending. A standardized second relocation request is generated based on the updated credentials, and the second relocation request data packet is sent to the robot.

[0071] Step A50: Parse the valid token based on the preset key to obtain the token generation time and token validity period.

[0072] Step A60: Based on the token generation time and the token validity period, determine whether the current time is within the token validity period, and determine whether the relocation receipt is the latest receipt based on the relocation request identifier.

[0073] Step A70: If the token is valid and the receipt is the latest one, then confirm that the relocation receipt is valid and control the robot to update the relocation result on the user interface.

[0074] In this embodiment, the valid token and relocation request identifier are parsed according to a preset receipt data packet format. A preset asymmetric encryption public key is retrieved to decrypt and parse the valid token, extracting the token generation time and validity period. Simultaneously, the validity of the token signature is verified; if the signature is invalid, the receipt is deemed unqualified. The current timestamp is obtained, and the token expiration timestamp is calculated as: Token expiration timestamp = Token generation time + Token validity period. It is then determined whether the current time is within the validity period. If the current timestamp is greater than or equal to the token generation time and less than or equal to the token expiration timestamp, the token validity verification passes; otherwise, the token is deemed expired, and the receipt is deemed unqualified.

[0075] Obtain the latest relocation request identifier for the corresponding robot. Perform a string match between the relocation request identifier in the receipt and the latest relocation request identifier. If they match exactly, it is determined to be the latest receipt; otherwise, it is determined to be a non-latest receipt and the receipt is invalid.

[0076] The relocation receipt is considered valid only if the token is valid and the receipt is the latest one. The positioning result data in the receipt is parsed, standardized relocation result information is generated, and the relocation result update command on the robot's user interface is triggered. If the receipt is invalid, the host computer records the reason for the failure, such as expired token, outdated receipt, or incorrect format, and initiates the process of updating the relocation request identifier and valid token.

[0077] In this embodiment, by monitoring the receipt cycle, updating credentials, and generating a second request mechanism, abnormal situations such as lost receipts, timeouts, and invalid receipts are effectively handled, improving the success rate of relocation requests. Based on the token's timestamp and validity period verification, combined with the latestness determination of the request identifier, interference from expired receipts, forged receipts, and historical receipts is effectively prevented, ensuring the authenticity and timeliness of the location results.

[0078] Based on the first embodiment of this application, in the fifth embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 After step S30, steps B10 to B30 may also be included: Step B10: When the number of relocation failures reaches the preset maximum number of failures, a failure fingerprint is generated based on the environment snapshot information.

[0079] In this embodiment, a failure count counter is initialized. After a single relocation request is sent, if a positioning failure receipt is received, no receipt is received within the period, or the receipt verification fails, the counter performs an atomic increment operation and stores it in the cache along with the robot ID and relocation request identifier. The current failure count is compared with a threshold. If the failure count is less than the threshold, the relocation request update and sending process continues; if the failure count is greater than or equal to the threshold, the environmental snapshot information collection and failure fingerprint generation process is triggered, and the counter is reset to 0.

[0080] The host computer sends an environmental snapshot collection command to the robot, triggering the robot to collect multi-dimensional snapshot information of the current environment, including: LiDAR point cloud snapshots, visual sensor image snapshots, IMU attitude data, wireless signal strength, light level, temperature and humidity snapshots, and robot status snapshots such as battery level, sensor operating status, and firmware operation log fragments. The host computer extracts features from the received environmental snapshot information. For LiDAR point cloud features, it calculates statistical features such as the mean, variance, curvature histogram, and number of key feature points (e.g., corner points, planar points). For visual image features, it extracts the number, distribution density, grayscale histogram mean and variance of SIFT / SURF feature points. For environmental and robot status features, it selects key numerical parameters such as IMU attitude covariance, wireless signal strength, light level, and battery level. All extracted feature parameters are arranged into a feature parameter array in a fixed order. Using a preset hash algorithm, the feature parameter array is converted into a string and used as input. A hash value is obtained, which is then used as a failure fingerprint and associated with the robot ID and failure timestamp.

[0081] Step B20: Match the failure fingerprint with the preset recovery parameter strategy library to determine the corresponding recovery parameters.

[0082] Step B30: Based on the recovery parameters and the preset information gain action, generate an environmental data acquisition command and send the environmental data acquisition command to the robot to trigger the robot to collect environmental data and perform repositioning based on the obtained environmental data.

[0083] In this embodiment, the host computer retrieves the corresponding recovery parameters from the policy library through fingerprint matching. The policy library stores a mapping table between failed fingerprints and recovery parameters, including fields such as fingerprint hash value, failure type label, recovery parameters, matching priority, and feature vector of the failed fingerprint.

[0084] The generated failed fingerprints are compared with the fingerprint hash values. If a match is found, the corresponding recovery parameters are read directly. If an exact match fails, a fuzzy match is performed. The cosine similarity between the feature vector of the current failed fingerprint and all vectors in the vector database is calculated. The entry with a similarity greater than or equal to the preset threshold and the highest matching priority is selected, and the corresponding recovery parameters are read. If the fuzzy match still fails, the default recovery parameters are enabled.

[0085] The host computer performs structured parsing of the matched recovery parameters, which include: sensor configuration parameters (LiDAR acquisition frequency, visual sensor exposure, IMU sampling rate); algorithm execution parameters (ICP matching threshold, feature point matching quantity threshold, relocation search range); and data acquisition parameters (acquisition duration, sampling interval, environmental data type filtering rules). The host computer reads a preset information gain action library from the configuration library. This library defines environmental data acquisition optimization actions for different failure types, such as: expanding the acquisition range and improving feature point extraction accuracy for insufficient environmental features; performing sensor calibration and multi-sensor data fusion enhancement actions for abnormal sensor data; and performing peak-shaving and encrypted data transmission actions for communication interference. Based on the matched failure type label, the host computer selects the corresponding information gain action and converts it into specific acquisition rules. The recovery parameters and information gain actions are integrated to generate standardized environmental data acquisition instructions, which are then sent to the robot.

[0086] After receiving the data acquisition command, the robot adjusts its sensor parameters according to the configuration, performs environmental data acquisition, and transmits the acquisition progress back to the host computer in real time. The host computer monitors the acquisition process through the progress data. If the acquisition times out or the amount of acquired data is insufficient, it issues an instruction to adjust the acquisition parameters, such as extending the acquisition duration or increasing the sensor sampling rate, to ensure the validity of the acquired data. After completing the acquisition, the robot encapsulates the environmental data into a compressed data packet and sends it back to the host computer. After confirming the validity of the acquired data, the host computer issues a relocation execution command to the robot, which includes a relocation algorithm configuration optimized based on the recovery parameters. After receiving the command, the robot loads the newly acquired environmental data, executes the optimized relocation algorithm, and encapsulates the positioning result into a receipt, sending it back to the host computer. The host computer performs receipt verification, result confirmation, and updates the relocation result on the robot's user interface.

[0087] In this embodiment, rapid diagnosis of relocation failure causes and adaptive parameter adjustment are achieved by matching failure fingerprints with a policy library. Failure fingerprints generated based on environmental snapshot information accurately reflect the characteristics of the on-site environment and the robot's state, enabling recovery parameters to adapt to specific failure scenarios and improving relocation stability in complex environments.

[0088] In one possible implementation, steps B40 to B80 may be included after step B30: Step B40: If relocation based on the environmental data fails, a return path is generated based on the UWB anchor coordinates, RFID tag location, or visual landmark features.

[0089] In this embodiment, the host computer receives the feedback from the robot after repositioning based on newly acquired environmental data, and parses the positioning status, failure reason, and positioning accuracy data in the feedback. If the feedback is marked as positioning failure, or the positioning accuracy is ≥ a preset accuracy threshold, the host computer determines that the repositioning based on the environmental data has failed and triggers the return path generation process; if the positioning is successful, the pose confirmation is completed according to the normal process.

[0090] The host computer generates the optimal return path to the charging pile by fusing multi-source spatial information based on the preset positioning technology type. It reads the coordinates of UWB anchor points deployed around the charging pile, as well as parameters such as the communication status and signal strength threshold of UWB base stations, from the spatial positioning database; it reads the location coordinates of RFID tags deployed in the charging pile area and main passageways, and the mapping table between tag IDs and locations; it reads the preset visual landmark feature library around the charging pile, and the coordinate data of landmarks in the global coordinate system. It calls the A* algorithm or Dijkstra's algorithm as the core path planning engine, constructing a global grid with the robot's current approximate location as the starting point and the charging pile location as the ending point; it integrates UWB anchor points, RFID tags, and visual landmarks as path node constraints, prioritizing areas with UWB signal coverage ≥ signal coverage threshold, RFID tag density ≥ tag density threshold, and visual landmark visibility ≥ preset visibility threshold as path nodes, avoiding obstacle grids. It generates return path data including path point sequences, driving speed limits, and positioning verification points.

[0091] Step B50: Send the return path to the robot to trigger the robot to travel to the charging pile location based on the return path.

[0092] Step B60: When it is determined that the robot has returned to the charging station location, determine the robot's second on-site confidence level.

[0093] In this embodiment, the host computer encapsulates the return path data into standardized instructions and sends them to the robot. During the robot's journey according to these instructions, it continuously transmits its current position, speed, heading angle, and deviation from the planned path points back to the host computer. The host computer monitors the deviation in real time. If the deviation is greater than or equal to a preset threshold, it issues a path correction instruction to ensure the robot follows the planned path. When the robot reaches a positioning verification point, the host computer triggers precise positioning to obtain the accurate coordinates of the verification point. These coordinates are compared with the preset coordinates on the path. If the deviation is less than or equal to the threshold, the robot continues driving; otherwise, it replans the local path to ensure overall path accuracy.

[0094] When the robot travels to a preset range around the target coordinates of the charging pile, the host computer triggers the robot to perform a charging pile docking detection. After the robot sends back a docking completion confirmation, the host computer determines that the robot has returned to the charging pile position. If docking is not completed, a fine-tuning command is issued until docking is completed. The host computer issues a charging pile confidence acquisition command to the robot, triggering the robot to collect current data, Hall sensor data, and charging pile code identification data between the robot and the charging pile, and calculates the second charging pile confidence using a weighted summation algorithm.

[0095] Step B70: If the second confidence level of being on the stake is greater than or equal to the confidence level threshold of being on the stake, then the preset initial pose is determined as the current pose of the robot.

[0096] Step B80: If the second confidence level of being on the stake is less than the confidence level threshold of being on the stake, then the point of interest is determined based on the preset whitelist, and the initial positioning reference is determined based on the point of interest.

[0097] In this embodiment, a preset on-pile confidence threshold is obtained, and the second on-pile confidence is compared with the threshold. If the second on-pile confidence is greater than or equal to the threshold, the host computer determines that the on-pile state is reliable, retrieves the initial pose corresponding to the charging pile from the preset pose database, determines it as the robot's current pose, and sends it to the robot.

[0098] If the second confidence level at the charging pile is less than a threshold, the host computer triggers the process of determining points of interest (POIs) and generating an initial positioning reference. A pre-defined whitelist of POIs for the charging pile area is read from the spatial database. This whitelist includes: the pre-defined coordinates of the charging pile, UWB anchor points around the charging pile, the visual landmark center point of the charging pile pillar, and RFID tags. The host computer filters the validity of these points according to pre-defined thresholds, such as UWB anchor point signal strength ≥ -65dBm and visual landmark matching degree ≥ 0.9, selecting a pre-defined number of valid points as POIs. A weighted average algorithm is used to calculate the initial positioning reference coordinates for the selected POIs, with weights allocated according to the reliability of the points. This generates an initial positioning reference containing coordinates and attitude angles, which is sent to the robot as a pose reference. Simultaneously, the positioning reference is marked as a temporary fallback value, to be recalibrated after the robot stabilizes.

[0099] In this embodiment, a return path planning system integrating UWB, RFID, and visual landmarks is used to achieve accurate return to the dock after a failed repositioning, preventing the robot from becoming lost or disoriented due to positioning failure. Based on a hierarchical judgment strategy using a second dock confidence level, the initial pose is directly reused when the dock status is reliable; otherwise, a fallback positioning reference is generated based on a whitelist of points of interest, balancing positioning accuracy and system fault tolerance. The fusion of real-time UWB positioning, RFID location identification, and feature matching of visual landmarks overcomes the limitations of single positioning technologies, improving the reliability of return path planning and positioning reference calculation.

[0100] This application provides a relocation device based on pile position sensing, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the relocation method based on pile position sensing in the first embodiment described above.

[0101] The following is for reference. Figure 3The diagram illustrates a structural schematic of a repositioning device suitable for implementing pile location sensing in the embodiments of this application. The repositioning device for pile location sensing in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, personal digital assistants (PDAs), tablet computers (PADs), and vehicle terminals (e.g., vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 3 The pile position sensing relocation device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0102] like Figure 3 As shown, the pile position sensing repositioning device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the pile position sensing repositioning device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the pile position sensing repositioning device to communicate wirelessly or wiredly with other devices to exchange data. Although pile position sensing repositioning devices with various systems are shown in the figures, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented alternatively.

[0103] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application 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 a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0104] The pile position sensing relocation device provided in this application, employing the pile position sensing relocation method in the above embodiments, can solve the technical problem of how to improve the accuracy of robot pile determination and relocation. Compared with the prior art, the beneficial effects of the pile position sensing relocation device provided in this application are the same as those of the pile position sensing relocation method provided in the above embodiments, and other technical features in this pile position sensing relocation device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0105] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0106] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0107] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the pile position sensing relocation method in the above embodiments.

[0108] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the 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 or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0109] The aforementioned computer-readable storage medium may be included in the pile location sensing repositioning device; or it may exist independently and not assembled into the pile location sensing repositioning device. The aforementioned computer-readable storage medium carries one or more programs that, when executed by the pile location sensing repositioning device, cause the pile location sensing repositioning device to: determine a first on-pile confidence level of the robot based on current data, Hall sensor data, and pile code identification data between the robot and the charging pile; compare the first on-pile confidence level with a preset on-pile confidence level threshold; if the first on-pile confidence level is less than the on-pile confidence level threshold, determine that the robot's on-pile status is untrustworthy; generate a first repositioning request based on a repositioning request identifier, timestamp, and valid token; and send the first repositioning request to the robot, the first repositioning request being used to control the robot to execute a preset repositioning algorithm and obtain a positioning result based on the repositioning algorithm.

[0110] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the client computer, partially on the client computer, as a standalone software package, partially on the client 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 client 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).

[0111] 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 application. 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.

[0112] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0113] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described pile position sensing relocation method, which can solve the technical problem of how to improve the accuracy of robot pile determination and relocation. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the pile position sensing relocation method provided in the above embodiments, and will not be repeated here.

[0114] The above descriptions are merely some embodiments of this application and do not limit the patent scope of this application. Any equivalent structural transformations made based on the technical concept of this application and the content of this specification and drawings, or direct / indirect applications in other related technical fields, are included within the patent protection scope of this application. Similarly, applications in other related technical fields are also included within the patent processing scope of this application.

Claims

1. A relocation method based on pile location sensing, characterized in that, The host computer for robots includes the following relocation method based on pile location perception: The robot's first confidence level at the charging pile is determined based on the current data, Hall sensor data, and pile code identification data between the robot and the charging pile. The first confidence level at the stake is compared with the preset confidence threshold at the stake. When the first confidence level of being on the dock is less than the confidence level threshold of being on the dock, the docking status of the robot is determined to be untrusted, and a first relocation request is generated based on the relocation request identifier, timestamp, and valid token. The first relocation request is sent to the robot. The first relocation request is used to control the robot to execute a preset relocation algorithm and obtain a positioning result according to the relocation algorithm.

2. The relocation method based on pile location sensing as described in claim 1, characterized in that, After the step of comparing the first on-pile confidence level with a preset on-pile confidence threshold, the relocation method based on pile location awareness further includes: If the first confidence level of being on the ground is greater than or equal to the confidence level threshold of being on the ground, then the robot's on-the-ground status is determined to be reliable. Once the on-the-stake state is determined to be reliable, the preset initial pose is determined as the robot's current pose, and the current pose is sent to the robot.

3. The relocation method based on pile location sensing as described in claim 2, characterized in that, The step of determining the robot's current pose as a preset initial pose and sending the current pose to the robot when the on-stake state is determined to be reliable includes: Once the on-stake state is determined to be reliable, the firmware version, mobility data, feature coverage data, and posture covariance of the robot are obtained. If the firmware version is within the preset supported version list, the accessibility data is greater than or equal to the preset accessibility threshold, the feature coverage data is greater than or equal to the preset feature coverage threshold, and the attitude covariance is less than or equal to the preset attitude covariance threshold, then the verification is confirmed to be successful. The initial pose is determined as the current pose of the robot, and the current pose is sent to the robot.

4. The relocation method based on pile location sensing as described in claim 1, characterized in that, Before the step of generating the first relocation request based on the relocation request identifier, timestamp, and valid token, the relocation based on stake location awareness further includes: The feature string is obtained by concatenating the map version number, the on-pile confidence level, the charging status indicator, the IMU data, the signal strength of the wireless model, and the light level. The feature string is hashed based on a preset hash algorithm, and the resulting hash value is determined as the current state fingerprint. The current state fingerprint is compared with the historical state fingerprint. If the difference between the current state fingerprint and the historical state fingerprint is greater than or equal to a preset state fingerprint difference threshold, or if the current time is not within a preset cooling window, then the relocation request identifier is generated according to a preset incrementing rule.

5. The relocation method based on pile location sensing as described in claim 1, characterized in that, After the step of generating the first relocation request based on the relocation request identifier, timestamp, and valid token, the relocation method based on pile location awareness further includes: When a relocation receipt from the robot is received within a preset period, the relocation receipt is parsed to obtain the valid token and the relocation request identifier. The valid token is parsed based on a preset key to obtain the token generation time and token validity period; Based on the token generation time and the token validity period, determine whether the current time is within the token validity period, and determine whether the relocation receipt is the latest receipt based on the relocation request identifier; If the token is valid and the receipt is the latest one, then the relocation receipt is confirmed to be valid, and the robot is controlled to update the relocation result on the user interface.

6. The relocation method based on pile location sensing as described in claim 5, characterized in that, After the steps of receiving a relocation receipt from the robot within a preset period, parsing the relocation receipt to obtain the valid token and the relocation request identifier, the relocation method based on pile location awareness further includes: If the relocation receipt is not received within the specified period, or if the relocation receipt is invalid, the relocation request identifier and the valid token are updated. Based on the updated valid token and relocation request identifier, a second relocation request is generated and sent to the robot.

7. The relocation method based on pile location sensing as described in claim 1, characterized in that, After the step of generating the first relocation request based on the relocation request identifier, timestamp, and valid token, the relocation method based on pile location awareness further includes: When the number of relocation failures reaches the preset maximum number of failures, a failure fingerprint is generated based on the environment snapshot information; The failure fingerprint is matched with a preset recovery parameter strategy library to determine the corresponding recovery parameters; Based on the recovery parameters and preset information gain actions, an environmental data acquisition command is generated and sent to the robot to trigger the robot to acquire environmental data and perform relocation based on the obtained environmental data.

8. The relocation method based on pile location sensing as described in claim 7, characterized in that, After the steps of generating an environmental data acquisition command based on the recovery parameters and a preset information gain action, and sending the environmental data acquisition command to the robot, the repositioning method based on pile location perception further includes: If relocation based on the environmental data fails, a return path is generated based on the UWB anchor point coordinates, RFID tag location, or visual landmark features. The return path is sent to the robot to trigger the robot to travel to the charging pile location based on the return path; Once it is determined that the robot has returned to the charging station location, a second confidence level of the robot's presence at the charging station is determined; If the second confidence level of being on the stake is greater than or equal to the confidence level threshold of being on the stake, then the preset initial pose is determined as the current pose of the robot; If the second confidence level of being on the stake is less than the confidence level threshold of being on the stake, then the point of interest is determined based on the preset whitelist, and the initial positioning reference is determined based on the point of interest.

9. A repositioning device based on pile position sensing, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the relocation method based on pile location sensing as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the relocation method based on pile position sensing as described in any one of claims 1 to 8.

Images