A multi-sensor data fusion control method of an intermediate motor

Abstract

This invention discloses a multi-sensor data fusion control method for a mid-drive motor, relating to the field of data processing technology. The method includes acquiring rotor position, phase current, output load, and temperature data streams, and constructing a versioned consistency snapshot based on source sequence number and sampling timescale. A sensor dependency graph is constructed based on the versioned consistency snapshot, and abnormal data is repaired according to node reliability to generate a fusion state record. Data processing tasks are scheduled based on the fusion state record to generate versioned control data records and publish them to a shared storage area. This invention organizes multi-sensor data reception, timescale synchronization, relationship verification, anomaly repair, task scheduling, and shared publication into a continuous versioned digital data processing flow. This enables downstream computing modules of the mid-drive motor and robot joint modules to obtain control data records with traceable sources, clear reliability, and atomic visibility, thereby improving the consistency, reproducibility, and operational stability of asynchronous multi-source data processing.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, specifically to a multi-sensor data fusion control method for a mid-mounted motor. Background Technology

[0002] As humanoid robots, collaborative robots, and other embodied intelligent devices evolve towards higher degrees of freedom, lighter weight, and higher integration, joint modules, dexterous hand drive units, and miniature electric cylinders typically need to perform position sensing, current acquisition, output load detection, temperature monitoring, and control data exchange within limited installation space. Various sensors differ in sampling frequency, interface latency, data format, and processing cycle. Embedded controllers need to perform digital data processing operations such as receiving, buffering, verifying, synchronizing, fusing, and publishing multiple data streams. With the increasing amount of sensor data and the degree of concurrency in processing tasks, the source version, processing sequence, and shared access consistency of control data are gradually becoming key factors affecting the reliability of joint data processing.

[0003] Existing methods for processing multi-sensor data in mid-drive motors typically read the latest values ​​from each sensor in the order they arrive, or filter each data stream separately before directly writing it into a common control variable. Because the source sequence numbers, sampling clocks, and communication delays of each acquisition source are not entirely consistent, data from different actual sampling times may be combined into the same processing input, causing distortion in the sequence of phase current changes, rotor position changes, and output load changes. When identifying anomalies based solely on the range threshold or filtering deviation of a single sensor, it is difficult to distinguish between sudden changes in actual load, missing messages, the mixing of old versions, and cross-source timing misalignments. Meanwhile, tasks such as consistency processing, anomaly repair, status generation, and record publishing have different data timeliness and computational loads; using a fixed execution order can easily lead to a backlog of new version data. When multiple tasks directly overwrite shared variables, problems may arise such as vector elements coming from different input versions, the reader obtaining only partially updated records, or the inability to reliably retain old records after publishing failures. Therefore, it is necessary to improve the processing of multi-sensor data for mid-drive motors from the perspectives of digital data processing, version management, task scheduling, and shared storage consistency. Summary of the Invention

[0004] In view of the above-mentioned problems, the present invention is proposed.

[0005] Therefore, the technical problem solved by this invention is that existing methods for processing multi-sensor data of mid-drive motors have problems such as inconsistent sampling times of heterogeneous data, lack of cross-source relationship verification basis for abnormal data, easy version mixing of asynchronous processing tasks and shared data release, and how to generate control data records with clear source version, credibility and complete release boundaries.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: a multi-sensor data fusion control method for a mid-mounted motor, comprising acquiring rotor position, phase current, output load and temperature data streams, and constructing a versioned consistent snapshot based on the source sequence number and sampling time stamp.

[0007] A sensor dependency graph is constructed based on versioned consistency snapshots, and abnormal data is repaired according to node credibility and a fusion status record is generated.

[0008] Based on the fusion status record, schedule data processing tasks, generate versioned control data records, and publish them to the shared storage area.

[0009] As a preferred embodiment of the multi-sensor data fusion control method for a mid-mounted motor described in this invention, the acquisition of rotor position, phase current, output load, and temperature data streams includes: reading the source identifier, source sequence number, sampling timestamp, receiving timestamp, and data payload of each data stream data packet; aggregating consecutive data packets with consecutive source sequences according to the source identifier to form a sensor data block; and generating a data block version identifier based on the source identifier and the source sequence number range.

[0010] As a preferred embodiment of the multi-sensor data fusion control method for mid-drive motors described in this invention, the step of constructing a versioned consistent snapshot based on the source sequence number and sampling timescale includes: establishing data block queues according to the source identifiers; calculating the timescale offset of each sensor data block based on the difference between the sampling timescale and the receiving timescale; determining cross-source correlated events from the data changes of phase current, rotor position, and output load according to the time sequence of phase current change, rotor position change, and output load change; and correcting the timescale offset of the corresponding data block queue using the cross-source correlated events; dividing logical time periods according to the corrected sampling timescales; selecting sensor data blocks in the same logical time period from each data block queue; and writing the data load, data age, and data block version identifier into the snapshot load matrix, freshness vector, and source version vector, respectively, to obtain a versioned consistent snapshot.

[0011] As a preferred embodiment of the multi-sensor data fusion control method for mid-drive motors described in this invention, the step of constructing a sensor dependency graph based on versioned consistency snapshots includes: establishing data nodes using rotor position data, phase current data, output load data, and temperature data from the snapshot load matrix; establishing temporal dependency edges between source data nodes of adjacent versioned consistency snapshots; establishing change order dependency edges between phase current data nodes, rotor position data nodes, and output load data nodes; and establishing baseline drift dependency edges between temperature data nodes and phase current data nodes. Relationship residuals are generated based on the data changes at both ends of the dependency edges, and the relationship residuals, the data age in the freshness vector, and the version compatibility result in the source version vector are written into the corresponding dependency edges to form the sensor dependency graph.

[0012] As a preferred embodiment of the multi-sensor data fusion control method for mid-mounted motors described in this invention, the step of repairing abnormal data based on node credibility and generating a fusion state record includes: generating node credibility based on the continuous state of the source sequence number of the data node, data age, version compatibility result, and relation residuals of the connected dependency edges. Data nodes with discontinuous source sequence numbers or incompatible versions and whose node credibility is lower than the median value of the credibility of nodes from the same source are identified as abnormal nodes. Same-source repair candidate values ​​are generated along temporal dependency edges, and cross-source repair candidate values ​​are generated along changing order dependency edges or baseline drift dependency edges. The repair candidate values ​​are substituted into the abnormal nodes, and the repair candidate value that makes the relation residual of the connected dependency edge closest to the median value of the corresponding relation residual is selected. A fusion state record containing a fusion state vector, a credibility vector, and a source version vector is generated based on the repaired data payload, node credibility, and source version vector.

[0013] As a preferred embodiment of the multi-sensor data fusion control method for mid-drive motors described in this invention, the step of scheduling data processing tasks based on fusion status records includes: establishing a data processing task graph encompassing consistency snapshot updates, sensor dependency graph updates, abnormal data repair, fusion status record generation, and control data record publication. Task priorities are determined based on the publication deadline of each task, the number of input version changes, the number of abnormal nodes, and the age of the input data. Data processing tasks with higher priority are selected from the data processing tasks completed by preceding tasks, and processor time slices and cache space are allocated accordingly.

[0014] As a preferred embodiment of the multi-sensor data fusion control method for mid-drive motors described in this invention, the step of generating versioned control data records and publishing them to the shared storage area includes encapsulating the fusion state vector, confidence vector, source version vector, and generation time stamp into a versioned control data record. The versioned control data record is written to the inactive buffer of the shared storage area. When the source version vector is consistent with the source version vector of the corresponding versioned consistency snapshot and the integrity check passes, the valid record pointer is switched to the inactive buffer using an atomic operation. When the source version vector is inconsistent or the integrity check fails, the corresponding versioned control data record is revoked, and the control data record publishing task is rescheduled.

[0015] As a preferred embodiment of the multi-sensor data fusion control system for the mid-mounted motor described in this invention, it includes a version snapshot construction module, a dependency graph repair module, and a task scheduling and publishing module.

[0016] The version snapshot construction module is used to acquire rotor position, phase current, output load and temperature data streams, and construct versioned consistent snapshots based on source sequence number and sampling time scale.

[0017] The dependency graph repair module is used to construct a sensor dependency graph based on versioned consistency snapshots, repair abnormal data according to node credibility, and generate fusion status records.

[0018] The task scheduling and publishing module is used to schedule data processing tasks according to the fusion status record, generate versioned control data records, and publish them to the shared storage area.

[0019] A computer device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement a multi-sensor data fusion control method for a mid-mounted motor.

[0020] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of a multi-sensor data fusion control method for a mid-mounted motor.

[0021] The beneficial effects of this invention are:

[0022] By reading the source identifier, source sequence number, and dual timestamp of each data packet, a data block version with a clear source sequence number range is formed. The timestamp offset of the data block queue is corrected by cross-source association events, realizing the versioned organization of heterogeneous sampled data within a unified logical time period. This ensures that the snapshot payload matrix, freshness vector, and source version vector maintain a corresponding relationship, thereby reducing input inconsistencies caused by old version mixing, sampling time sequence reversal, and undeterminable data age.

[0023] By establishing a sensing dependency graph containing temporal dependency edges, change order dependency edges, and baseline drift dependency edges, and by integrating source sequence continuity, data age, version compatibility results, and the credibility of relation residual generation nodes, source constraints and cross-source verification of abnormal nodes are realized. This allows repair candidate values ​​to be selected based on the residuals of associated edges, thereby reducing the impact of missing messages, incorrect versions, or temporal misalignments on the fused status record while preserving the true payload changes.

[0024] By scheduling data processing tasks according to the release deadline, the number of input version changes, the number of abnormal nodes, and the age of the input data, and by using inactive cache writing, integrity verification, and atomic pointer switching to control the versioning of release records, the corresponding allocation of computing task resources and data timeliness is achieved. This ensures that the reader can only observe records with the same source version and complete fields, thereby avoiding the mixing of old and new vectors, partial write visibility, and release failures overwriting valid records during concurrent processing. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 The above is an overall flowchart of a multi-sensor data fusion control method for a mid-mounted motor provided in Embodiment 1 of the present invention. Detailed Implementation

[0027] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0028] Example 1, referring to Figure 1 As an embodiment of the present invention, a multi-sensor data fusion control method for a mid-mounted motor is provided, comprising:

[0029] S1. Acquire rotor position, phase current, output load, and temperature data streams, and construct a versioned, consistent snapshot based on the source sequence number and sampling time scale.

[0030] Read the source identifier, source sequence number, sampling time stamp, reception time stamp, and data payload of data packets from each data stream. Aggregate data packets with consecutive source sequence numbers according to the source identifier to form a sensor data block. Generate a data block version identifier based on the source identifier and the source sequence number range.

[0031] Furthermore, this embodiment is applied to the mid-mounted motor data processing controller in humanoid robot joint modules, dexterous hand drive units, or micro electric cylinders. The rotor position data stream originates from the encoder interface, the phase current data stream from the current sampling interface, the output load data stream from the torque, thrust, or equivalent load sampling interface at the joint output end, and the temperature data stream from the winding, driver, or housing temperature sampling interface. The data collected by each interface is first encapsulated into a unified data packet by the acquisition driver program. This unified data packet includes at least a source identifier field, a source sequence number field, a sampling timestamp field, a receiving timestamp field, a data payload field, and a checksum field. The source identifier distinguishes the data source and remains unchanged within the same controller's operating cycle. The source sequence number is incremented sequentially by the corresponding acquisition driver program according to the data packet generation order, used to identify duplicate, missing, or out-of-order packets. The sampling timestamp indicates the moment the sensor completes sampling. The receiving timestamp indicates the moment the data packet enters the data processing controller's receiving queue.

[0032] Furthermore, each data stream employs a sampling period adapted to its data change rate. In this embodiment, the sampling frequency of the rotor position data stream and the phase current data stream can be set to... to The sampling frequency of the output payload data stream can be set to to The sampling frequency of the temperature data stream can be set to to The aforementioned ranges are derived from the bandwidth of position, current, load, and temperature data changes in the joint module and the available computing resources of the controller. High-rate-of-change data uses shorter sampling periods to preserve the sequence of transient changes. Temperature data uses longer sampling periods to avoid invalid duplicate calculations on data with high thermal inertia. Data loads use a predefined field structure according to the source identifier. For example, rotor position data loads include position count values ​​and encoder status words; phase current data loads include at least one phase current sample value; output load data loads include load sample values ​​and range status words; and temperature data loads include temperature sample values ​​and sensor status words.

[0033] Furthermore, after data packets enter the receive queue, they are processed according to their source identifiers. For data packets with the same source identifier, they are first sorted in ascending order based on their source sequence number, and then duplicate packets with the same source sequence number and the same data payload verification result are deleted. When the difference between the source sequence numbers of two adjacent data packets is 1, they are processed separately. When the source sequence number difference is greater than 1, the two will be grouped into the same sensor data block. When the sampling timescale rolls back or the source sequence number reaches the count limit and restarts, the current sensing data block ends and a new sensing data block is established. To balance data processing latency and block-level processing overhead, a single sensing data block for rotor position data stream and phase current data stream can contain... to A single sensor data block outputting the payload data stream can contain a data message. to A single sensor data block in a temperature data stream can contain a data message. to One data packet. This value range is derived from the aforementioned sampling frequency and... to The block processing time boundary helps to avoid snapshot update delays caused by excessively large single data blocks.

[0034] Furthermore, considering that data packets may be received repeatedly, partially missing, or have their source sequence numbers wrapped around, and that relying solely on the first and last source sequence numbers cannot accurately represent the continuity of data blocks, this embodiment calculates the source sequence number continuity for each sensor data block. This source sequence number continuity is used as input to form the reliability of subsequent nodes, and its calculation formula is as follows:

[0035]

[0036] in, Indicates the source identifier is The The continuity of the source sequence number of each sensor data block, with a value range of [value range missing]. ,in, This indicates that there are no missing data packets within the source sequence number range. The source identifier of the data stream is assigned by the acquisition driver during initialization and corresponds to the rotor position data stream, phase current data stream, output load data stream, or temperature data stream, respectively. This represents the sensor data block number arranged in the order of formation under the same source identifier, and its value is a positive integer. Indicates the source identifier is The The number of data packets that pass the load verification and whose source sequence numbers are unique in each sensor data block is directly obtained from the statistics of the current sensor data block. Indicates the source identifier is The The largest source sequence number within a sensor data block after source sequence number wrap-around expansion processing. Indicates the source identifier is The Within each sensor data block, the smallest source sequence number after source sequence number wrap-around expansion processing.

[0037] When the sensor data block contains only one valid data message, Set as . When the denominator When the length of the corresponding source sequence number interval exceeds the maximum number of messages allowed in the data block, the current sensor data block is truncated and re-divided to avoid source sequence number continuity distortion caused by abnormal source sequence numbers. (Calculated...) It is saved along with the data block version identifier and used in S2 to generate the node credibility of the corresponding data node.

[0038] Furthermore, the data block version identifier consists of a source identifier, the start point of the source sequence number range, the end point of the source sequence number range, and the data block generation batch. The source identifier and the source sequence number range are the essential identifying fields for the version identifier, while the data block generation batch is used to distinguish identical ranges appearing after the source sequence number wraps around. These fields can be serialized into fixed byte sequences to generate the version. Bit index values ​​are used for fast comparisons in the shared memory area, but the pre-serialized field combinations still serve as traceable version identifiers. Data block generation batches are affected by driver reinitialization and sampling time-stamp rollback exceeding [a certain threshold]. Or it increments when the source sequence number wraps around. The preset values ​​in this embodiment are derived from the safety interval between the upper limit of the normal sampling period of each data stream and the controller restart recognition time. This setting can prevent normal communication jitter from being mistaken for a restart of the acquisition source. If two data blocks If the index values ​​are the same but the field combinations are different, a second comparison is performed using the complete field combination to prevent index collisions from causing different data blocks to be incorrectly treated as the same version.

[0039] Data block queues are established according to source identifiers, and the time offset of each sensor data block is calculated based on the difference between the sampling time stamp and the receiving time stamp. Cross-source correlated events are determined from the data changes of phase current, rotor position, and output load, in chronological order of phase current change, rotor position change, and output load change. These cross-source correlated events are then used to correct the time offset of the corresponding data block queues. Logical time periods are divided according to the corrected sampling time stamps. Sensor data blocks within the same logical time period are selected from each data block queue, and their data load, data age, and data block version identifier are written into the snapshot load matrix, freshness vector, and source version vector, respectively, to obtain a versioned consistent snapshot.

[0040] Furthermore, each data block queue is independently established according to the source identifier. Each queue element includes at least the sensor data block, data block version identifier, source sequence number continuity, and queue write time. For all valid data packets within a sensor data block, the difference between the received timestamp and the sampled timestamp is calculated, and the median of these differences is used as the initial timestamp offset for that sensor data block. The median is used instead of the arithmetic mean because receive queue scheduling, interrupt contention, or momentary bus congestion can cause a sudden increase in a small number of receive timestamps; the median reduces the impact of a single abnormal receive delay on the entire data block. If a sensor data block contains only one valid data packet, the timestamp difference of that data packet is directly used. If the number of valid data packets is less than a predetermined lower limit for data blocks, a low-sample flag is written into the offset record, and the weight of the corresponding associated event for that data block is reduced during subsequent correction.

[0041] Furthermore, cross-source correlated events are used to establish reproducible timing references when different data acquisition sources do not use the exact same hardware clock. Phase current change events can be used when the absolute change in phase current exceeds the rated range. to And more than recently to Median absolute deviation of the variation in individual phase current samples Determined by time multiple. Rotor position change events can occur when the equivalent velocity change resulting from the difference between adjacent sampling positions exceeds the most recent... to The median absolute deviation of the equivalent velocity change for each sample The time is determined by multiples. Output load change events can occur when the load change exceeds the rated range. to And more than recently to The median absolute deviation of the load sample variation The time-limited range is determined by the sensor's range resolution, the normal steady-state fluctuations of the joint module, and the requirements for preventing false triggering of boundary samples. This range allows for the distinction between noise changes and data changes with actual temporal significance. Following the order of phase current change first, rotor position change second, and output load change last, the range is determined by the time-limited range. Three change events within the associated window are combined into a single cross-source associated event.

[0042] Furthermore, considering that the transmission delay and physical response delay of different sensor data sources will be simultaneously reflected in the event time difference, this embodiment first obtains the normal physical event time difference of the corresponding data source relative to the reference source through calibration sample statistics, and then separates the timescale offset error from the actual event time difference. When the phase current data stream is used as the reference source, the timescale offset of each sensor data block is corrected according to the following formula:

[0043]

[0044] in, Indicates the source identifier is The The time-stamp offset of each sensor data block after cross-source correlation event correction, in units of . Indicates the source identifier is The The initial time offset of each sensing data block is obtained from the median value of the difference between the received time offset and the sampling time offset of each data packet within the block, in units of 1. . Indicates that the source identifier is The A set of cross-source correlated events where the time ranges of several sensor data blocks intersect, preferably containing the following number of events. to indivual. Represents a set of cross-source related events Event index in the database. Indicates the first The weights of cross-source related events satisfy... The larger value is used when all three types of data changes for an event exceed their respective thresholds and the change order is complete; the smaller value is used when the data block has low-sample labels or the event is close to the boundary of the association window. Indicates the first In a cross-source associated event, the source identifier is The actual sampling time standard deviation between the change event and the reference source change event, in units of . Indicates the source identifier is The normal physical time difference between the change event and the reference source change event is determined by the time the equipment assembly is completed. to The median time difference of the group without abnormal calibration events was determined, in units of . This indicates a positive number used to prevent the denominator from being zero; in this embodiment, it is set to... .

[0045] When set The number of associated events is less than If the current event correction is not performed, the previous valid correction value will be used instead. When the system is running for the first time and there is no previous valid correction value, the initial timescale offset will be used. The magnitude of a single change in the correction amount is limited to the length of one logic time period. The excess portion is truncated to avoid occasional matching errors causing abrupt changes in the queue timescale. Corrected timescale offset. Used to convert the sampling timestamps of each data packet to a unified logical timestamp field.

[0046] Furthermore, the unified logical time stamp domain is based on to The logical time period is divided, and the length of the logical time period is derived from the minimum effective processing cycle of rotor position and phase current data and the available computing resources of the controller. For temperature data with a sampling period longer than the logical time period, the same temperature data block is allowed to be referenced in multiple logical time periods not exceeding its freshness limit, but a new data block version identifier is not generated. For each logical time period, the sensor data block with the largest overlap ratio between the corrected sampling time stamp and the logical time period is selected from each data block queue, and the selected data payload is written into the snapshot payload matrix in a fixed column order according to the source identifier. The data age is calculated by subtracting the corrected sampling time stamp of the last valid data message of the selected data block from the snapshot generation time stamp, and written into the freshness vector. The data block version identifier is written into the source version vector in the same column order. The upper limit of the data age for rotor position data and phase current data can be set to... to The upper limit of the data age for output load data can be set to to The upper limit of the data age for temperature data can be set to to When the corresponding upper limit is exceeded, the data block version identifier is retained, but the payload validity flag is set to invalid, so that subsequent sensor dependency graphs can distinguish between missing data and expired data.

[0047] It should be noted that this step does not simply concatenate multi-sensor data according to the order of reception. Instead, it uses data block versions with consecutive source sequence numbers, block-level timescale offset correction, and version consistency selection within logical time periods to form data objects with clear sources and version boundaries before entering subsequent calculations. This process overcomes the problems of difficulty in identifying old version mixing, cross-source timing inversion, and partial message loss when directly using the latest value, and establishes reusable input boundaries for subsequent sensor dependency graphs.

[0048] S2. Construct a sensor dependency graph based on versioned consistency snapshots, repair abnormal data according to node credibility, and generate fusion status records.

[0049] Data nodes are established using rotor position data, phase current data, output load data, and temperature data from the snapshot load matrix. Temporal dependency edges are established between source data nodes in adjacent versioned consistent snapshots. Change order dependency edges are established between phase current data nodes, rotor position data nodes, and output load data nodes. Baseline drift dependency edges are established between temperature data nodes and phase current data nodes. Relationship residuals are generated based on the data changes at both ends of the dependency edges. The relationship residuals, the data age in the freshness vector, and the version compatibility result in the source version vector are written into the corresponding dependency edges to form a sensing dependency graph.

[0050] Furthermore, each data node uses a "snapshot identifier—source identifier—data block version identifier" as a joint key, and stores the corresponding data load, data age, source sequence number continuity, load validity flag, and data range. To ensure that data changes of different physical quantities can participate in unified relational residual calculations, the data changes of each data node are dimensionless before calculation. Rotor position changes are normalized according to one mechanical cycle or encoder full scale, phase current changes are normalized according to the current sampling range, output load changes are normalized according to the load sensor range, and temperature changes are normalized according to the allowable operating temperature range width. The normalized changes are limited to... Within the specified range, any portion exceeding the range is truncated and an out-of-bounds flag is written to the node. The measurement range is derived from the sensor interface initialization parameters or device configuration records, and unspecified historical indicators are not used, thus ensuring that the relational residuals can be traced back to directly acquired data and engineering configuration parameters.

[0051] Furthermore, time-series dependency edges connect data nodes with the same source identifier in adjacent versioned consistency snapshots, describing the continuity of changes from the same data source over consecutive logical time periods. Change-order dependency edges are established according to the direction from the phase current data node to the rotor position data node, and from the rotor position data node to the output load data node, expressing the sequential relationship between current changes, position changes, and load changes in the data time series. Baseline drift dependency edges connect temperature data nodes and phase current data nodes, expressing the slow shift of the steady-state baseline of the phase current under temperature changes. Each dependency edge stores the joint key of the starting node, the joint key of the ending node, the dependency edge type, the allowed delay, the version compatibility result, and the relationship residual. The version compatibility result is defined as follows: when the version identifiers of the data blocks at both ends of the edge belong to the current snapshot source version vector and there are no revoked versions, the result is considered complete. Otherwise, record as .

[0052] Furthermore, considering that the data connected by different dependent edges have different dimensions and varying magnitudes, direct subtraction would allow large-scale data to dominate anomaly detection. Therefore, this embodiment uses dimensionless residuals based on calibration relationships. For the first... For any dependency edge in a versioned consistent snapshot, the relation residual is calculated according to the following formula:

[0053]

[0054] in, Indicates the first Dependency edges in versioned consistency snapshots The relational residuals are dimensionless non-negative numbers that satisfy... . This represents the index of the dependency edge in the sensor dependency graph. This represents the sequential number of the versioned consistency snapshot, and its value is a positive integer. Indicates dependent edges The starting data node. Indicates dependent edges The endpoint data node. Indicates the starting data node The normalized data change in the snapshot corresponding to the allowed latency of dependent edges satisfies... . Indicates the endpoint data node In the The normalized data change in each versioned consistent snapshot satisfies . Indicates dependent edges The coefficient of change, from to The robust regression slope of the changes at the starting point and the ending point is determined in a normal calibration snapshot. Indicates dependent edges The baseline compensation is determined by the median value of the regression residuals in the normal calibration snapshot. For time-dependent edges, the default setting is... . Indicates dependent edges The number of logical time periods corresponding to the allowed latency. Timing dependency edge selection. The order of change depends on the edge selection. Baseline drift depends on edge taking . Indicates dependent edges The corresponding normal calibration residual scale is the median absolute deviation of the normal calibration residual. Double confirm, and set The lower limit. This indicates a positive number used to prevent the denominator from being zero; in this embodiment, it is set to... .

[0055] When the normal calibration snapshot is less than At this time, the change ratio coefficient will not be updated. and baseline compensation Instead, the initial values ​​in the device configuration are used. When the relational residuals satisfy... At that time, cut it into Furthermore, residual out-of-bounds flags are set to prevent a single abnormal edge from amplifying the impact on node reliability. The closer the relation residuals are... The larger the residual, the more closely the data changes at both ends of the edge conform to the corresponding dependency relationship. A larger residual indicates that at least one data node may have temporal misalignment, abnormal load, or version inconsistency.

[0056] Furthermore, the allowable delay for the change sequence-dependent edge is determined based on the time difference statistics of cross-source associated events in S1. The allowable delay from the phase current data node to the rotor position data node can be set to... to For each logical time period, the allowable delay from the rotor position data node to the output load data node can be set to [value missing]. to A logical time period. The specific value is taken from the most recent time period. to The number of time periods corresponding to the median of the time difference of a complete cross-source associated event, with reserves above and below it. The search range for each logical time period. Baseline drift dependency edges are used. to A sliding window is used to calculate temperature changes and steady-state changes in phase current over several logical time periods. The window range is derived from the low sampling frequency of the temperature data and the slow change in the current baseline, which helps prevent instantaneous phase current changes from being misinterpreted as baseline drift caused by temperature. If the effective temperature nodes within the window are less than [number missing], [the calculation is incomplete]. If there are [number] cases, then the baseline compensation amount update will be suspended. And use the previous valid value.

[0057] Furthermore, when forming the sensor dependency graph, the relation residual, starting data age, ending data age, version compatibility result, allowable latency, and residual out-of-bounds flag for each dependency edge are written into the edge attribute area. The data age is retained in S1. The original value is represented, and then converted according to the upper limit of the data age of the corresponding data source. The freshness ratio within the range. Both the edge attribute area and the node attribute area are accompanied by a snapshot identifier of the current versioning consistency snapshot. It is prohibited to directly combine nodes and edges under different snapshot identifiers into the same graph version. The graph version identifier of the sensing dependency graph is jointly determined by the snapshot identifier and the source version vector. When any data block version is revoked or replaced, a new graph version is generated instead of overwriting the original graph version, so that the anomaly repair process can trace its input data, relation residuals, and version compatibility status.

[0058] Node credibility is generated based on the continuous state of the source sequence number of data nodes, data age, version compatibility results, and relation residuals of the connected dependency edges. Data nodes with discontinuous source sequence numbers or version incompatibility and whose node credibility is lower than the median credibility value of the same-source nodes are identified as anomalous nodes. Same-source repair candidate values ​​are generated along temporal dependency edges, and cross-source repair candidate values ​​are generated along changing order dependency edges or baseline drift dependency edges. The repair candidate values ​​are substituted into the anomalous nodes respectively, and the repair candidate value that makes the relation residual of the connected dependency edge closest to the median value of the corresponding relation residual is selected. A fusion state record containing a fusion state vector, a credibility vector, and a source version vector is generated based on the repaired data payload, node credibility, and source version vector.

[0059] Furthermore, considering that a single data age or a single relation residual can easily lead to misjudgments in boundary samples, this embodiment maps the continuous state of the source sequence number, data freshness, version compatibility results, and relation residuals of multiple dependent edges together as node credibility. Data Node The node credibility is calculated according to the following formula:

[0060]

[0061] in, : Represents a data node The node trustworthiness satisfies . : Indicates the index of the data node in the current sensing dependency graph. : Represents a data node The source sequence continuity of the corresponding sensor data block is obtained from the source sequence continuity calculation result in S1, and satisfies... . : Represents a data node The data age is obtained by subtracting the last valid sampling time of the corresponding data block from the current snapshot generation time, in units of 1. . : Represents a data node The upper limit of the data age of the data source. The rotor position data and phase current data correspond to... Can be set to to The corresponding output load data Can be set to to Temperature data corresponding to Can be set to to . : Represents a data node The corresponding source identifier. : Represents a data node Version compatibility results. When version compatibility is achieved... When versions are incompatible . : Represents a data node The median of the residuals of all valid dependent edges connected. Set to [value] when there are no valid dependent edges. And write a relationship insufficiency flag. : Represents the maximum value function, used to limit the freshness of data to non-negative numbers. : Represents the minimum function, used to limit the upper bound of the relational residuals involved in the exponential mapping to . . : Represents an exponential function with the natural constant as its base, used to map relational residuals to... The credibility of relationships within a given scope.

[0062] The four weights in the formula are as follows: , , and And satisfy: .

[0063] The weights are derived from the allocation of the roles of data source integrity, freshness, version consistency, and cross-source relationship consistency in anomaly identification. Relationship residuals are given higher weights to ensure that changes in relationships across multiple data sources can be considered in the judgment. Simultaneously, the continuity of source sequence numbers and version compatibility results are preserved to prevent data nodes with temporarily normal relationships but missing or incorrect versions from being judged as trustworthy. (Formula results) Used for identifying abnormal nodes, sorting repair candidates, and generating credibility vector elements in fusion status records.

[0064] Furthermore, the median confidence score of nodes with the same source identifier is the most recent one. to In the individual graph version, the calculation of effective homogeneous nodes uses a window length derived from the logical time period length and boundary fluctuation suppression requirements. This ensures that while maintaining response speed, it prevents a single abnormal node from altering the comparison benchmark. When the number of effective homogeneous nodes within the window is less than [a certain value], [the calculation is more complex]. At this time, adopt As a provisional median comparison value. This is the engineering preset value in this embodiment, located in the upper-middle part of the trusted and untrusted intervals, which is beneficial for adopting a conservative repair strategy during the insufficient sample stage. Only when the data node meets the precondition of discontinuous source sequence numbers or version incompatibility, and its node trustworthiness... A node is identified as an anomalous node only when its confidence level is lower than the median confidence level of its source nodes. For data nodes with large relation residuals but consecutive source sequence numbers and version compatibility, they are not directly replaced but are marked with relational attention flags to prevent incorrect repair of abrupt changes in the actual payload.

[0065] Furthermore, when generating repair candidate values ​​for anomalous nodes, same-source candidates are obtained from the previous and next valid nodes of the same source identifier along the temporal dependency edges. When both the previous and next nodes exist, linear interpolation is performed according to the position of the anomalous node's sampling timescale between the previous and next nodes. When only the previous valid node exists, single-step extrapolation is performed using the change trends of the two most recent valid same-source nodes. When only the next valid node exists, the reverse hold value of the next valid node is used. When generating cross-source candidates along the change order dependency edges, the change ratio coefficient of the corresponding dependency edge is used. Baseline compensation amount and allowable delay This involves inversely mapping the normalized changes from adjacent data sources to the data range of the anomalous nodes. When generating candidates along the baseline drift-dependent edges, the anomalous phase current nodes are corrected based on the current baseline compensation amount corresponding to the temperature change. Each anomalous node is generated... to Candidate values ​​that exceed the sensor's range or violate the position cycle boundary are directly eliminated.

[0066] Furthermore, after substituting each repair candidate value into the anomalous node, only the dependency edge relationship residuals connected to the anomalous node are recalculated, and the residuals of each new relationship are compared with the nearest edge of the corresponding edge type. to The sum of the absolute differences of the residuals of the normal graph version relationship. The candidate repair value with the smallest sum of absolute differences is selected. When the difference of the sum of absolute differences corresponding to two candidate values ​​is less than... When selecting candidate values, prioritize those with higher source node credibility, followed by those with younger data ages. If no candidate value can reduce the relation residual to the level of the normal residual for the corresponding edge type, then... If the data is within the percentile, the original data payload is retained, and the upper limit of the corresponding node's credibility is limited to [value missing]. Simultaneously, a repair failure flag is written. The repaired rotor position data, phase current data, output load data, and temperature data are arranged in a fixed source order to form a fusion state vector, and the corresponding node credibility forms a credibility vector. The source version vector of the current snapshot is written into the fusion state record as is, so that subsequent tasks can determine the source version of the fusion result and the reliability of the repair.

[0067] It should be noted that this step does not perform independent filtering on each sensor data. Instead, it unifies the same-source temporal relationships, cross-source change order relationships, and temperature-current baseline relationships into a sensor dependency graph with version attributes, and uses the relationship residuals to participate in node confidence and candidate repair selection. This processing can distinguish between missing source numbers, version incompatibility, and cross-source relationship mismatches while preserving the true load abrupt changes, overcoming the problems of difficulty in determining the source of anomalies based solely on single sensor thresholds and the lack of cross-source verification basis for repair values.

[0068] S3. Schedule data processing tasks based on the fusion status record, generate versioned control data records, and publish them to the shared storage area.

[0069] Establish a data processing task graph that includes consistent snapshot updates, sensor dependency graph updates, abnormal data repair, fusion state record generation, and control data record release. Determine task priorities based on each task's release deadline, number of input version changes, number of abnormal nodes, and input data age. Select the data processing tasks with the highest priority from those completed by preceding tasks and allocate processor time slices and cache space accordingly.

[0070] Furthermore, the task nodes in the data processing task graph correspond to consistency snapshot update, sensor dependency graph update, abnormal data repair, fusion state record generation, and control data record publication, respectively. Each task node stores the task type, task instance identifier, input version set, output version identifier, publication deadline, expected data volume, and execution status. The task instance identifier is generated from the task type and input version set, allowing the same task type to form different task instances for different snapshot versions. Tasks are linked by forward edges based on their input-output relationships. Specifically, the sensor dependency graph update task has the aforementioned consistency snapshot update task as its predecessor, the abnormal data repair task has the sensor dependency graph update task as its predecessor, the fusion state record generation task has the abnormal data repair task as its predecessor, and the control data record publication task has the fusion state record generation task as its predecessor. Subsequent tasks enter the runnable set only after the preceding task is completed and the output version has not been revoked.

[0071] Furthermore, considering that different tasks have varying sensitivities to data timeliness, version changes, and anomaly handling load, and that using a fixed task order could easily cause critical release tasks to miss their deadlines during sudden anomalies or rapid version updates, this embodiment converts the release deadline, the number of input version changes, the number of anomaly nodes, and the age of input data into dimensionless quantities, and generates task priorities according to the following formula:

[0072]

[0073] in, Indicates data processing task Task priority, satisfying The larger the value, the higher the priority the data processing task should be. This represents the task instance index in the data processing task graph. Indicates task The urgency of the deadline is obtained by normalizing the remaining time from the current time to the publication deadline, satisfying the following conditions: The remaining time is less than or equal to At that time, set . Indicates task The normalized result of the number of input version changes is obtained by dividing the number of input version changes by 1 / 2. Later restrictions Within the range. Indicates task The normalized result of the number of abnormal nodes is obtained by dividing the number of abnormal nodes by 1 / 2. Later restrictions Within the range. Indicates task The input data age normalization result is limited by dividing the maximum data age in all input data of the task by the upper limit of the data age of the corresponding data source. Within the range.

[0074] The four weights in the formula are as follows: , , and And satisfy: .

[0075] The weights are derived from the scheduling principles of prioritizing release deadlines, balancing version updates and exception handling, and using data age to assist in sorting. Deadline urgency. Using maximum weights reduces the likelihood of version control data records expiring due to queuing. Input the normalized result of the number of version changes. Normalized result of the number of abnormal nodes Using equal weights maintains a balance between new version processing and anomaly fixing. Input data age-normalized results. This is used to prioritize processing data that is more prone to failure when other conditions are similar.

[0076] Furthermore, the release deadline for each task is determined by adding the logical end time of its input snapshot to the task's allowed processing latency. The allowed processing latency for a consistent snapshot update task can be set to... to The allowable processing latency for the sensor dependency graph update task can be set to [value]. to The allowable processing delay for abnormal data repair tasks can be set to... to The allowable processing latency for the fusion status record generation task and the control data record publishing task can be set to [specific values ​​to be filled in]. to The above range is derived from... to The logical time period length, task computation volume, and control data must be readable before the next processing cycle. The number of input version changes represents the number of different elements in the current task's input version set relative to the input version set of the previous executed task instance. The number of abnormal nodes is directly derived from the abnormal node identification results of S2. The input data age is derived from the fusion state record and its corresponding versioned consistency snapshot; no additional unspecified timeliness indicators are generated.

[0077] Furthermore, at each scheduling point, the scheduler forms a runnable set from tasks whose preceding tasks have all been completed, and then sorts them according to task priority. Select tasks in descending order. When the priority difference between two tasks is less than... When scheduling tasks, prioritize those with earlier deadlines. If deadlines are the same, prioritize the task with the earlier input version identifier to ensure duplicate scheduling results. If a task with higher priority than the current task occurs during task execution... New tasks with a remaining deadline of less than one logical time period may be preempted after the current task has completed processing the indivisible data block. and These are the sorting stability boundary and the preemption trigger boundary, respectively, derived from task priority. Normalization range. The former is used to prevent order jitter caused by small floating-point differences, while the latter is used to avoid cache invalidation and increased context switching overhead caused by frequent task preemption.

[0078] Furthermore, considering that high-priority tasks need more processing resources, but still need to reserve a minimum execution opportunity for other tasks within the same runnable set, processor time slices and cache space are allocated according to the following formula:

[0079]

[0080]

[0081] in, This indicates that the task is assigned to a data processing task. Processor time slice, in units of . This represents the minimum processor time slice for a task, which in this embodiment can be set to... to . This represents the maximum processor time slice that can be allocated to a task within a single scheduling cycle; in this embodiment, it can be set to... to . Indicates data processing task The task priority is obtained from the aforementioned task priority formula. This represents the set of runnable tasks at the current scheduling point. Represents a set of runnable tasks Index of data processing tasks in the database. Represents the set of currently runnable tasks. The sum of the priorities of all tasks in the process. This represents a positive number used to prevent the sum of task priorities from being zero; in this embodiment, it is set to... . This indicates that the task is assigned to a data processing task. Cache space, in units of . This represents the minimum cache space required for a single task; in this embodiment, it can be set to... . This represents the maximum cache space allowed for a single task; in this embodiment, it can be set to... . Indicates data processing task The number of serialized bytes of input data is directly calculated from the data objects corresponding to the task input version set, and the unit is 1. . The baseline for the amount of data allocated to the cache can be set to [data type] in this embodiment. . This indicates that for every additional data volume increment of the input data base... The increased cache space in this embodiment can be set to [specific value]. to . This indicates the rounding up operation. This function represents the minimum value and is used to limit the task cache space to the maximum cache space. Within.

[0082] The aforementioned processor time slice and cache space ranges are derived from the task switching overhead, logical time period length, and data size of the snapshot payload matrix and sensor dependency graph of the embedded multi-core processor. If the sum of the priorities of runnable tasks satisfies... If the total cache demand exceeds the available cache, then the minimum cache space is reserved for each task first. Then according to task priority The remaining cache is allocated in descending order of priority. After the task is completed, the temporary cache is released, retaining only its versioned output object.

[0083] Furthermore, each task execution records its actual start time, actual end time, input version set, output version identifier, allocated time slice, and cache usage. A task not executed within its allocated time slice... Upon completion, the intermediate cursor is saved, and processing continues at the next scheduling point, without reprocessing already generated and validated data blocks. If a task input version is revoked during execution, the current task instance is immediately marked as invalid, its temporary cache is released, and a new task instance is created based on the new input version. The task graph itself is stored in the scheduling area as a computer data processing object, without directly changing the motor's voltage, current, or commutation parameters. Its output is a version-constrained data record, thus ensuring that the core processing of this step remains data task management, storage management, and electrical digital data processing.

[0084] The fusion state vector, credibility vector, source version vector, and generation timestamp are encapsulated into a versioned control data record. This versioned control data record is written to the inactive cache of the shared storage area. When the source version vector matches the source version vector of the corresponding versioned consistency snapshot and the integrity check passes, the valid record pointer is atomically switched to the inactive cache. If the source version vector is inconsistent or the integrity check fails, the corresponding versioned control data record is revoked, and the control data record publication task is rescheduled.

[0085] Furthermore, versioned control data records adopt a fixed header and variable payload structure. The fixed header includes at least the record type, record length, record version identifier, corresponding snapshot identifier, generation timestamp, source version vector length, fusion state vector length, credibility vector length, and integrity check value. The variable payload is serialized in the order of fusion state vector, credibility vector, and source version vector. The record version identifier is generated jointly by the corresponding snapshot identifier, fusion state record version, and release task instance identifier to distinguish records based on the same snapshot but formed through different repair or re-release processes. The generation timestamp uses a scheduler-unified clock recording, with a time resolution not less than the logical time period length. Serialized data according to or Boundary alignment is used to reduce unaligned accesses when the processor reads shared memory.

[0086] Furthermore, the shared storage area is configured with at least two caches of equal capacity. One cache, indicated by a valid record pointer, is the active cache, accessible only to subsequent motor control calculation modules, state monitoring modules, or robot joint coordination modules. The other cache serves as an inactive cache, used by the currently published task to write new versioned control data records. When writing to the inactive cache, the record validity flag is first invalidated, followed by the sequential writing of the fixed header, fused state vector, confidence vector, source version vector, and integrity check value. Finally, a storage barrier is executed to ensure that the data writing order observed by the processor or different processor cores is consistent. Before completing version verification and integrity checks, the valid record pointer is not changed, ensuring that the reader always obtains a complete old version record and avoids reading intermediate states that are currently being written.

[0087] Furthermore, integrity verification can employ CRC32C or equivalent cyclic redundancy check supported by the processor, calculating all bytes in the versioned control data record except for the integrity check value field. Source version vector consistency means that the number of source identifiers, the order of source identifiers, and the corresponding data block version identifiers in the record to be published are all identical to the source version vectors in the corresponding versioned consistency snapshot. Integrity verification passing means that the recalculated check value is the same as the check value saved in the record header, and the record length, the sum of the lengths of each vector, and the buffer boundaries are consistent. After all the above conditions are met, the record validity flag in the inactive buffer is first set to valid, and then the valid record pointer is switched from the original active buffer address to the inactive buffer address through a compare-and-swap atomic operation. A failed compare-and-swap operation indicates that other publishing tasks have already completed the valid record pointer switch; in this case, a new active record must not be overwritten.

[0088] Furthermore, in cases of source version vector inconsistency, integrity verification failure, comparison and swap operation failure, or input version revocation during writing, the valid flag of the record in the inactive buffer is restored to invalid, and the corresponding versioning control data record is marked as revoked. During rescheduling, the original release deadline is retained, but the number of input version changes is set to at least [a certain value]. This allows re-release tasks to be prioritized in accordance with version changes. A single version control data record can be retried continuously. to The number of retries is derived from the recovery requirements of shared storage contention and transient verification failures. After reaching the retry limit, the previous valid record in the current active cache is retained, and a publication failure status is output for processing by the upper-layer task management program. The shared storage area can retain the most recent... to Metadata for published or revoked records is available to facilitate tracing the version switching process, but the reader can only access the current record based on the valid record pointer.

[0089] It should be noted that this step does not directly overwrite common variables after each data processing module completes its work. Instead, it represents the data processing flow as a data processing task graph with version input and deadlines. Through double buffering, integrity verification, storage barriers, and atomic pointer switching, it forms an invisible write phase and a one-time visible publish phase. This process overcomes the problems of mixing old and new vectors during asynchronous task concurrency, some fields being updated while others are not, and the inability to stably retain old records after a publish failure. This ensures that the data records read by downstream modules have a consistent source version and complete serialization boundaries.

[0090] Example 2, an embodiment of the present invention, provides a multi-sensor data fusion control system for a mid-drive motor, including a version snapshot construction module, a dependency graph repair module, and a task scheduling and publishing module.

[0091] The version snapshot building module is used to acquire rotor position, phase current, output load and temperature data streams, and build versioned consistent snapshots based on source sequence number and sampling time scale.

[0092] The dependency graph repair module is used to build a sensor dependency graph based on versioned consistency snapshots, repair abnormal data according to node credibility, and generate fusion status records.

[0093] The task scheduling and publishing module is used to schedule data processing tasks based on the fusion status record, generate versioned control data records, and publish them to the shared storage area.

Claims

1. A multi-sensor data fusion control method for a mid-mounted motor, characterized in that, include: Acquire rotor position, phase current, output load and temperature data streams, and construct a versioned consistent snapshot based on the source sequence number and sampling time scale; A sensor dependency graph is constructed based on versioned consistency snapshots, and abnormal data is repaired according to node credibility and a fusion status record is generated. Based on the fusion status record, schedule data processing tasks, generate versioned control data records, and publish them to the shared storage area.

2. The multi-sensor data fusion control method for a mid-mounted motor as described in claim 1, characterized in that: The acquisition of rotor position, phase current, output load, and temperature data streams includes, Read the source identifier, source sequence number, sampling timestamp, receiving timestamp, and data payload of the data packets in each data stream; Data packets with consecutive source sequence numbers are aggregated according to source identifiers to form sensor data blocks; Data block version identifiers are generated based on the source identifier and the source sequence number range.

3. The multi-sensor data fusion control method for a mid-mounted motor as described in claim 2, characterized in that: The step of constructing a versioned consistency snapshot based on the source sequence number and sampling time stamp includes, Data block queues are established according to the source identifier, and the time offset of each sensor data block is calculated based on the difference between the sampling time stamp and the receiving time stamp. From the data changes of phase current, rotor position and output load, cross-source correlation events are determined according to the time sequence of phase current change, rotor position change and output load change, and the time scale offset of the corresponding data block queue is corrected by cross-source correlation events. Logical time periods are divided according to the corrected sampling time scale. Sensor data blocks in the same logical time period are selected from each data block queue. The data payload, data age, and data block version identifier are written into the snapshot payload matrix, freshness vector, and source version vector, respectively, to obtain a versioned consistent snapshot.

4. The multi-sensor data fusion control method for a mid-mounted motor as described in claim 3, characterized in that: The construction of the sensing dependency graph based on versioned consistent snapshots includes, Data nodes are established using rotor position data, phase current data, output load data, and temperature data from the snapshot load matrix; Establish temporal dependency edges between common source data nodes of adjacent versioned consistent snapshots; Establish change order dependency edges between phase current data nodes, rotor position data nodes, and output load data nodes; Establish a baseline drift dependency edge between the temperature data node and the phase current data node; Generate relation residuals based on the data changes at both ends of the dependency edges, and write the relation residuals, the data age in the freshness vector, and the version compatibility results in the source version vector into the corresponding dependency edges to form a sensing dependency graph.

5. The multi-sensor data fusion control method for a mid-mounted motor as described in claim 4, characterized in that: The step of repairing abnormal data based on node credibility and generating a fusion status record includes, Node credibility is generated based on the continuous state of the source sequence number of the data node, the data age, the version compatibility result, and the relational residual of the connected dependency edges. Data nodes whose source sequence numbers are not consecutive or whose versions are incompatible, and whose node credibility is lower than the median value of the credibility of nodes from the same source, are identified as abnormal nodes. Generate homogeneous repair candidate values ​​along temporal dependency edges, and generate cross-source repair candidate values ​​along changing order dependency edges or baseline drift dependency edges; Substitute the candidate values ​​for repair into the abnormal node and select the candidate value for repair that makes the relation residual of the connected dependent edge closest to the median value of the corresponding relation residual. Based on the repaired data payload, node credibility, and source version vector, a fusion state record is generated, which includes a fusion state vector, credibility vector, and source version vector.

6. The multi-sensor data fusion control method for a mid-mounted motor as described in claim 5, characterized in that: The data processing task scheduling based on the fusion status record includes... Establish a data processing task graph that includes consistent snapshot updates, sensor dependency graph updates, abnormal data repair, fusion state record generation, and control data record publication; Task priorities are determined based on the release deadline, number of input version changes, number of abnormal nodes, and age of input data for each task. Select the data processing task with the highest priority from the data processing tasks completed by the preceding tasks, and allocate processor time slices and cache space accordingly.

7. The multi-sensor data fusion control method for a mid-mounted motor as described in claim 6, characterized in that: The process of generating versioned control data records and publishing them to the shared storage area includes, The fusion state vector, credibility vector, source version vector, and generation time stamp are encapsulated into a versioned control data record. Write version control data records to the inactive cache of the shared storage area; When the source version vector is consistent with the source version vector of the corresponding versioned consistency snapshot and the integrity check passes, the valid record pointer is switched to the inactive cache area in an atomic operation. If the source version vector is inconsistent or the integrity check fails, the corresponding versioned control data record is revoked and the control data record release task is rescheduled.

8. A multi-sensor data fusion control system for a mid-drive motor, employing the multi-sensor data fusion control method for a mid-drive motor as described in any one of claims 1 to 7, characterized in that: Includes a version snapshot build module, a dependency graph repair module, and a task scheduling and publishing module; The version snapshot construction module is used to acquire rotor position, phase current, output load and temperature data streams, and construct a versioned consistent snapshot based on the source sequence number and sampling time scale. The dependency graph repair module is used to construct a sensor dependency graph based on versioned consistency snapshots, repair abnormal data according to node credibility, and generate fusion status records. The task scheduling and publishing module is used to schedule data processing tasks according to the fusion status record, generate versioned control data records, and publish them to the shared storage area.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the multi-sensor data fusion control method for the mid-mounted motor as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the multi-sensor data fusion control method for the mid-mounted motor as described in any one of claims 1 to 7.

Images